visualpython-users

[Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

Now available at sourceforge.net is VPython 4.beta21 for Windows and Linux:

*Default window now 600x600, which includes titlebar, toolbar, and 
borders. For the first time on Linux, you can place a window at a 
specific desired x,y position, as was always possible on Windows.
*Now display max 10000 points of a curve (old Visual did max 1000; see 
below).
*Implement and document curve.retain=N, meaning retain only the N most 
recently appended points.This is a convenient way to leave a tail behind 
a moving object.
*Significantly improved tuning of the balance between the computational 
thread and the render thread.
*Implemented toolbar option to restore to standard values center, 
forward, and up.
*Documentation for new display.get_titlebar_height(), 
display.get_toolbar_height().
*Added rate statements to tictac.py, hanoi.py, and toroid_drag.py as a 
workaround for a problem with quitting a program with a loop that 
contains very little computation. (I haven't yet figured out why it is 
difficult to quit such programs.)
*The statement scene.show_rendertime = True triggers a display in the 
bottom left corner of the screen of the cycle time (milliseconds between 
rendering of the scene) and render time (milliseconds required to render 
the scene). The cycle time minus the render time is the approximate 
number of milliseconds in the cycle devoted to your Python computations.

All of the standard example programs seem to run well on both Windows 
and Ubuntu Linux except for stonehenge.py which is sluggish compared to 
the production version. Rendering of the complex scene is slow on my not 
very powerful Windows/Linux laptop (1 GHz, 500 MB). I hope to study this 
further and try to bring the performance up to expectations.

I would appreciate it if some adventuresome souls would try this 
version, as a significant number of outstanding issues have been addressed.

I should offer some explanation of the need to display a maximum number 
of points in a curve. In Visual 3 a maximum of 1000 points were 
displayed for a curve, no matter how many points it actually contained. 
The points chosen to display were spaced as uniformly as possible over 
the entire curve. The bad thing about this scheme is that a curve with a 
very large number of points may display in a bizarre way. For example, 
if you repeatedly add points to a curve representing the elliptical 
orbit of a planet, eventually you'll see points connected to each other 
by straight-line segments from one side of the ellipse to another, which 
is very confusing. However, if we try to display all of the points, the 
longer the orbit runs the slower the rendering becomes. Some very simple 
standard orbit programs ran unacceptably slowly. So I've reverted to the 
old scheme of displaying only up to a maximum number of points. But 
recognizing the large increase in speed of computers since the 
beginnings of VPython in 2000, I made the limit 10000 instead of 1000, 
which seems to work fine and makes it 10 times less likely you'll see 
strange displays of a many-point curve. The philosophy underlying this 
kind of compromise was articulated very clearly by David Scherer, the 
originator of VPython, as "Go fast, be wrong!" The effect is that one 
gets almost always sensible and good performance, at the penalty of 
sometimes going wrong.

There is a highly technical problem which has been identified but for 
which there is currently no known solution. In the old Numeric module 
used in Visual 3, sqrt(5.5) was a float, but in numpy used in the beta 
version sqrt(5.5) is numpy.float64, with the highly unfortunate result 
that sqrt(5.5)*vector isn't a VPython vector but rather a numpy array. 
I've asked for help on this from both the numpy and Boost discussion 
lists but so far not gotten any assistance. In some existing physics 
programs the effect is to double the time required to update an orbit, 
so this is serious. I'll mention that vector*sqrt(5.5) works fine -- the 
result is a vector.

Bruce

Re: [Visualpython-users] 4.beta21

[Jose A. M. H <jam...@fd...>]

Dear Bruce,=20

What about : Plotting Graphs of Functions or Data

It seems that this thread of development has been left ?

I have tested the beta version on windows xp, but  I get crtical erros, =
not only not displaying the plot, indeed the program crashes, that is, =
this module does not work on this version..

The module for plotting is very usefull, and I think it should not be =
abandoned, istead improving the plotting module will be very usefull, =
for instance, adding the possibility to export the plot to a graphics =
file or to export the plot into a plot for another graphing tool in =
order to improve its functionality.

Why not to add 3D ploting capabilities ? like surfaces ?=20

For instance, matplotlib does a good job, but it is intended not for =
realtime graphics but instead for final graph production.

Best whishes, and happy new year for all.=20

jose.



----- Original Message -----=20
From: "Bruce Sherwood" <Bru...@nc...>
To: "vpusers" <vis...@li...>
Sent: Tuesday, December 25, 2007 7:08 AM
Subject: [Visualpython-users] 4.beta21


> Now available at sourceforge.net is VPython 4.beta21 for Windows and =
Linux:
>=20
> *Default window now 600x600, which includes titlebar, toolbar, and=20
> borders. For the first time on Linux, you can place a window at a=20
> specific desired x,y position, as was always possible on Windows.
> *Now display max 10000 points of a curve (old Visual did max 1000; see =

> below).
> *Implement and document curve.retain=3DN, meaning retain only the N =
most=20
> recently appended points.This is a convenient way to leave a tail =
behind=20
> a moving object.
> *Significantly improved tuning of the balance between the =
computational=20
> thread and the render thread.
> *Implemented toolbar option to restore to standard values center,=20
> forward, and up.
> *Documentation for new display.get_titlebar_height(),=20
> display.get_toolbar_height().
> *Added rate statements to tictac.py, hanoi.py, and toroid_drag.py as a =

> workaround for a problem with quitting a program with a loop that=20
> contains very little computation. (I haven't yet figured out why it is =

> difficult to quit such programs.)
> *The statement scene.show_rendertime =3D True triggers a display in =
the=20
> bottom left corner of the screen of the cycle time (milliseconds =
between=20
> rendering of the scene) and render time (milliseconds required to =
render=20
> the scene). The cycle time minus the render time is the approximate=20
> number of milliseconds in the cycle devoted to your Python =
computations.
>=20
> All of the standard example programs seem to run well on both Windows=20
> and Ubuntu Linux except for stonehenge.py which is sluggish compared =
to=20
> the production version. Rendering of the complex scene is slow on my =
not=20
> very powerful Windows/Linux laptop (1 GHz, 500 MB). I hope to study =
this=20
> further and try to bring the performance up to expectations.
>=20
> I would appreciate it if some adventuresome souls would try this=20
> version, as a significant number of outstanding issues have been =
addressed.
>=20
> I should offer some explanation of the need to display a maximum =
number=20
> of points in a curve. In Visual 3 a maximum of 1000 points were=20
> displayed for a curve, no matter how many points it actually =
contained.=20
> The points chosen to display were spaced as uniformly as possible over =

> the entire curve. The bad thing about this scheme is that a curve with =
a=20
> very large number of points may display in a bizarre way. For example, =

> if you repeatedly add points to a curve representing the elliptical=20
> orbit of a planet, eventually you'll see points connected to each =
other=20
> by straight-line segments from one side of the ellipse to another, =
which=20
> is very confusing. However, if we try to display all of the points, =
the=20
> longer the orbit runs the slower the rendering becomes. Some very =
simple=20
> standard orbit programs ran unacceptably slowly. So I've reverted to =
the=20
> old scheme of displaying only up to a maximum number of points. But=20
> recognizing the large increase in speed of computers since the=20
> beginnings of VPython in 2000, I made the limit 10000 instead of 1000, =

> which seems to work fine and makes it 10 times less likely you'll see=20
> strange displays of a many-point curve. The philosophy underlying this =

> kind of compromise was articulated very clearly by David Scherer, the=20
> originator of VPython, as "Go fast, be wrong!" The effect is that one=20
> gets almost always sensible and good performance, at the penalty of=20
> sometimes going wrong.
>=20
> There is a highly technical problem which has been identified but for=20
> which there is currently no known solution. In the old Numeric module=20
> used in Visual 3, sqrt(5.5) was a float, but in numpy used in the beta =

> version sqrt(5.5) is numpy.float64, with the highly unfortunate result =

> that sqrt(5.5)*vector isn't a VPython vector but rather a numpy array. =

> I've asked for help on this from both the numpy and Boost discussion=20
> lists but so far not gotten any assistance. In some existing physics=20
> programs the effect is to double the time required to update an orbit, =

> so this is serious. I'll mention that vector*sqrt(5.5) works fine -- =
the=20
> result is a vector.
>=20
> Bruce
>=20
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

I don't know why you conclude that graphing has been neglected or even 
abandoned. Significant effort was expended to make graphing as fast on 
Visual 4 as it was on Visual 3. Moreover, the new points object makes 
gdot plots much faster than before.

Graphing does work on Windows and (Ubuntu) Linux. It is possible that 
you need to update your graphics card driver.

Because graphing works as well or better in Visual 4 as it did in Visual 
3, making improvements to this part of Visual necessarily must have much 
lower priority for my own work than actual problem areas (e.g. poor 
performance for some kinds of scenes). However, if you feel strongly 
about implementing for example PostScript output in order to permit 
high-quality printing, please go ahead and do this work. The graphing 
module is written in Python, not C++, and all you need to do is generate 
a PostScript text file based on the objects created for the graph.

Bruce Sherwood

Jose Antonio Martin H wrote:
> Dear Bruce,
>  
> What about : Plotting Graphs of Functions or Data
>  
> It seems that this thread of development has been left ?
>  
> I have tested the beta version on windows xp, but  I get crtical 
> erros, not only not displaying the plot, indeed the program crashes, 
> that is, this module does not work on this version..
>  
> The module for plotting is very usefull, and I think it should not be 
> abandoned, istead improving the plotting module will be very usefull, 
> for instance, adding the possibility to export the plot to a graphics 
> file or to export the plot into a plot for another graphing tool in 
> order to improve its functionality.
>  
> Why not to add 3D ploting capabilities ? like surfaces ?
>  
> For instance, matplotlib does a good job, but it is intended not for 
> realtime graphics but instead for final graph production.
>  
> Best whishes, and happy new year for all.
>  
> jose.
>  
> ** 
> ** 
> ----- Original Message -----
> From: "Bruce Sherwood" <Bru...@nc... 
> <mailto:Bru...@nc...>>
> To: "vpusers" <vis...@li... 
> <mailto:vis...@li...>>
> Sent: Tuesday, December 25, 2007 7:08 AM
> Subject: [Visualpython-users] 4.beta21
>
> > Now available at sourceforge.net is VPython 4.beta21 for Windows and 
> Linux:
> >
> > *Default window now 600x600, which includes titlebar, toolbar, and
> > borders. For the first time on Linux, you can place a window at a
> > specific desired x,y position, as was always possible on Windows.
> > *Now display max 10000 points of a curve (old Visual did max 1000; see
> > below).
> > *Implement and document curve.retain=N, meaning retain only the N most
> > recently appended points.This is a convenient way to leave a tail 
> behind
> > a moving object.
> > *Significantly improved tuning of the balance between the computational
> > thread and the render thread.
> > *Implemented toolbar option to restore to standard values center,
> > forward, and up.
> > *Documentation for new display.get_titlebar_height(),
> > display.get_toolbar_height().
> > *Added rate statements to tictac.py, hanoi.py, and toroid_drag.py as a
> > workaround for a problem with quitting a program with a loop that
> > contains very little computation. (I haven't yet figured out why it is
> > difficult to quit such programs.)
> > *The statement scene.show_rendertime = True triggers a display in the
> > bottom left corner of the screen of the cycle time (milliseconds 
> between
> > rendering of the scene) and render time (milliseconds required to 
> render
> > the scene). The cycle time minus the render time is the approximate
> > number of milliseconds in the cycle devoted to your Python computations.
> >
> > All of the standard example programs seem to run well on both Windows
> > and Ubuntu Linux except for stonehenge.py which is sluggish compared to
> > the production version. Rendering of the complex scene is slow on my 
> not
> > very powerful Windows/Linux laptop (1 GHz, 500 MB). I hope to study 
> this
> > further and try to bring the performance up to expectations.
> >
> > I would appreciate it if some adventuresome souls would try this
> > version, as a significant number of outstanding issues have been 
> addressed.
> >
> > I should offer some explanation of the need to display a maximum number
> > of points in a curve. In Visual 3 a maximum of 1000 points were
> > displayed for a curve, no matter how many points it actually contained.
> > The points chosen to display were spaced as uniformly as possible over
> > the entire curve. The bad thing about this scheme is that a curve 
> with a
> > very large number of points may display in a bizarre way. For example,
> > if you repeatedly add points to a curve representing the elliptical
> > orbit of a planet, eventually you'll see points connected to each other
> > by straight-line segments from one side of the ellipse to another, 
> which
> > is very confusing. However, if we try to display all of the points, the
> > longer the orbit runs the slower the rendering becomes. Some very 
> simple
> > standard orbit programs ran unacceptably slowly. So I've reverted to 
> the
> > old scheme of displaying only up to a maximum number of points. But
> > recognizing the large increase in speed of computers since the
> > beginnings of VPython in 2000, I made the limit 10000 instead of 1000,
> > which seems to work fine and makes it 10 times less likely you'll see
> > strange displays of a many-point curve. The philosophy underlying this
> > kind of compromise was articulated very clearly by David Scherer, the
> > originator of VPython, as "Go fast, be wrong!" The effect is that one
> > gets almost always sensible and good performance, at the penalty of
> > sometimes going wrong.
> >
> > There is a highly technical problem which has been identified but for
> > which there is currently no known solution. In the old Numeric module
> > used in Visual 3, sqrt(5.5) was a float, but in numpy used in the beta
> > version sqrt(5.5) is numpy.float64, with the highly unfortunate result
> > that sqrt(5.5)*vector isn't a VPython vector but rather a numpy array.
> > I've asked for help on this from both the numpy and Boost discussion
> > lists but so far not gotten any assistance. In some existing physics
> > programs the effect is to double the time required to update an orbit,
> > so this is serious. I'll mention that vector*sqrt(5.5) works fine -- 
> the
> > result is a vector.
> >
> > Bruce
> >
> > 
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li... 
> <mailto:Vis...@li...>
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>   

Re: [Visualpython-users] 4.beta21

[Scott D. D. <Sco...@Ac...>]

Bruce Sherwood wrote:
> There is a highly technical problem which has been identified but for 
> which there is currently no known solution. In the old Numeric module 
> used in Visual 3, sqrt(5.5) was a float, but in numpy used in the beta 
> version sqrt(5.5) is numpy.float64, with the highly unfortunate result 
> that sqrt(5.5)*vector isn't a VPython vector but rather a numpy array. 
If you use the simple expedient of using math.sqrt, rather than
numpy.sqrt, you will have the behavior you prefer.  The "ufunc"s in
numpy that have corresponding functions in math are:
     ceil cos cosh exp fabs floor fmod frexp hypot
     ldexp log log10 modf sin sinh sqrt tan tanh

So adding:
     from math import (ceil, cos, cosh, exp, fabs, floor, fmod, frexp,
           hypot, ldexp, log, log10, modf, sin, sinh, sqrt, tan, tanh)
after importing numpy (or the moral equivalent) will give you scalar-
producing and consuming functions, as opposed to the numpy-internal
floating format.

-Scott David Daniels
Sco...@Ac...

Re: [Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

I've already played with essentially this. In 
site-packages/visual/__init__.py we import math, then numpy, which means 
that sqrt goes to numpy. If I reverse the order of these imports it does 
indeed mean that we use math.sqrt, but this then breaks programs such as 
gas.py where the argument of the sqrt is an array of vectors. What I 
need is for sqrt(25) to be treated like 5, but also to be able to use 
the array features of the numpy sqrt when the argument isn't a simple 
scalar.

A related issue is that VPython is deliberately designed to be easily 
usable by novice users, with sensible defaults, and without the 
necessity of special imports or references to differences between math 
and numpy. And maybe even more to the point, the change from Numeric to 
numpy has made many existing programs run much more slowly than before.

But thanks for the suggestion!

Bruce

Scott David Daniels wrote:
> Bruce Sherwood wrote:
>   
>> There is a highly technical problem which has been identified but for 
>> which there is currently no known solution. In the old Numeric module 
>> used in Visual 3, sqrt(5.5) was a float, but in numpy used in the beta 
>> version sqrt(5.5) is numpy.float64, with the highly unfortunate result 
>> that sqrt(5.5)*vector isn't a VPython vector but rather a numpy array. 
>>     
> If you use the simple expedient of using math.sqrt, rather than
> numpy.sqrt, you will have the behavior you prefer.  The "ufunc"s in
> numpy that have corresponding functions in math are:
>      ceil cos cosh exp fabs floor fmod frexp hypot
>      ldexp log log10 modf sin sinh sqrt tan tanh
>
> So adding:
>      from math import (ceil, cos, cosh, exp, fabs, floor, fmod, frexp,
>            hypot, ldexp, log, log10, modf, sin, sinh, sqrt, tan, tanh)
> after importing numpy (or the moral equivalent) will give you scalar-
> producing and consuming functions, as opposed to the numpy-internal
> floating format.
>
> -Scott David Daniels
> Sco...@Ac...
>
>
>   

Re: [Visualpython-users] 4.beta21

[Scott D. D. <Sco...@Ac...>]

Bruce Sherwood wrote:
> I've already played with essentially this. In 
> site-packages/visual/__init__.py we import math, then numpy, which means 
> that sqrt goes to numpy. If I reverse the order of these imports it does 
> indeed mean that we use math.sqrt, but this then breaks programs such as 
> gas.py where the argument of the sqrt is an array of vectors. What I 
> need is for sqrt(25) to be treated like 5, but also to be able to use 
> the array features of the numpy sqrt when the argument isn't a simple 
> scalar.

I'm not sure of the overhead here, but could something like this work?

     def sqrt(x):
         try: return math.sqrt(x)
         except TypeError: return numpy.sqrt(x)

--Scott David Daniels
Sco...@Ac...

Re: [Visualpython-users] 4.beta21

[Scott D. D. <Sco...@Ac...>]

I (Scott David Daniels) wrote:
> I'm not sure of the overhead here, but could something like this work?
> 
>      def sqrt(x):
>          try: return math.sqrt(x)
>          except TypeError: return numpy.sqrt(x)

If it "kinda" works, the following addition to __init__ should work:

     from numpy import (ceil as _n_ceil, cos as _n_cos, cosh as _n_cosh,
                   exp as _n_exp, fabs as _n_fabs, floor as _n_floor,
                   fmod as _n_fmod, frexp as _n_frexp, hypot as _n_hypot,
                   ldexp as _n_ldexp, log as _n_log, log10 as _n_log10,
                   modf as _n_modf, sin as _n_sin, sinh as _n_sinh,
                   sqrt as _n_sqrt, tan as _n_tan, tanh as _n_tanh)
     from math import (ceil as _m_ceil, cos as _m_cos, cosh as _m_cosh,
                   exp as _m_exp, fabs as _m_fabs, floor as _m_floor,
                   fmod as _m_fmod, frexp as _m_frexp, hypot as _m_hypot,
                   ldexp as _m_ldexp, log as _m_log, log10 as _m_log10,
                   modf as _m_modf, sin as _m_sin, sinh as _m_sinh,
                   sqrt as _m_sqrt, tan as _m_tan, tanh as _m_tanh)
     def ceil(x):
         try: return _m_ceil(x)
         except TypeError: return _n_ceil(x)
     def cos(x):
         try: return _m_cos(x)
         except TypeError: return _n_cos(x)
     def cosh(x):
         try: return _m_cosh(x)
         except TypeError: return _n_cosh(x)
     def exp(x):
         try: return _m_exp(x)
         except TypeError: return _n_exp(x)
     def fabs(x):
         try: return _m_fabs(x)
         except TypeError: return _n_fabs(x)
     def floor(x):
         try: return _m_floor(x)
         except TypeError: return _n_floor(x)
     def fmod(x):
         try: return _m_fmod(x)
         except TypeError: return _n_fmod(x)
     def frexp(x):
         try: return _m_frexp(x)
         except TypeError: return _n_frexp(x)
     def hypot(x):
         try: return _m_hypot(x)
         except TypeError: return _n_hypot(x)
     def ldexp(x):
         try: return _m_ldexp(x)
         except TypeError: return _n_ldexp(x)
     def log(x):
         try: return _m_log(x)
         except TypeError: return _n_log(x)
     def log10(x):
         try: return _m_log10(x)
         except TypeError: return _n_log10(x)
     def modf(x):
         try: return _m_modf(x)
         except TypeError: return _n_modf(x)
     def sin(x):
         try: return _m_sin(x)
         except TypeError: return _n_sin(x)
     def sinh(x):
         try: return _m_sinh(x)
         except TypeError: return _n_sinh(x)
     def sqrt(x):
         try: return _m_sqrt(x)
         except TypeError: return _n_sqrt(x)
     def tan(x):
         try: return _m_tan(x)
         except TypeError: return _n_tan(x)
     def tanh(x):
         try: return _m_tanh(x)
         except TypeError: return _n_tanh(x)

--Scott David Daniels
Sco...@Ac...

Re: [Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

Thanks for the suggestion. I'll look into this workaround.

Bruce Sherwood

Scott David Daniels wrote:
> I (Scott David Daniels) wrote:
>   
>> I'm not sure of the overhead here, but could something like this work?
>>
>>      def sqrt(x):
>>          try: return math.sqrt(x)
>>          except TypeError: return numpy.sqrt(x)
>>     
>
> If it "kinda" works, the following addition to __init__ should work:
>
>      from numpy import (ceil as _n_ceil, cos as _n_cos, cosh as _n_cosh,
>                    exp as _n_exp, fabs as _n_fabs, floor as _n_floor,
>                    fmod as _n_fmod, frexp as _n_frexp, hypot as _n_hypot,
>                    ldexp as _n_ldexp, log as _n_log, log10 as _n_log10,
>                    modf as _n_modf, sin as _n_sin, sinh as _n_sinh,
>                    sqrt as _n_sqrt, tan as _n_tan, tanh as _n_tanh)
>      from math import (ceil as _m_ceil, cos as _m_cos, cosh as _m_cosh,
>                    exp as _m_exp, fabs as _m_fabs, floor as _m_floor,
>                    fmod as _m_fmod, frexp as _m_frexp, hypot as _m_hypot,
>                    ldexp as _m_ldexp, log as _m_log, log10 as _m_log10,
>                    modf as _m_modf, sin as _m_sin, sinh as _m_sinh,
>                    sqrt as _m_sqrt, tan as _m_tan, tanh as _m_tanh)
>      def ceil(x):
>          try: return _m_ceil(x)
>          except TypeError: return _n_ceil(x)
>      def cos(x):
>          try: return _m_cos(x)
>          except TypeError: return _n_cos(x)
>      def cosh(x):
>          try: return _m_cosh(x)
>          except TypeError: return _n_cosh(x)
>      def exp(x):
>          try: return _m_exp(x)
>          except TypeError: return _n_exp(x)
>      def fabs(x):
>          try: return _m_fabs(x)
>          except TypeError: return _n_fabs(x)
>      def floor(x):
>          try: return _m_floor(x)
>          except TypeError: return _n_floor(x)
>      def fmod(x):
>          try: return _m_fmod(x)
>          except TypeError: return _n_fmod(x)
>      def frexp(x):
>          try: return _m_frexp(x)
>          except TypeError: return _n_frexp(x)
>      def hypot(x):
>          try: return _m_hypot(x)
>          except TypeError: return _n_hypot(x)
>      def ldexp(x):
>          try: return _m_ldexp(x)
>          except TypeError: return _n_ldexp(x)
>      def log(x):
>          try: return _m_log(x)
>          except TypeError: return _n_log(x)
>      def log10(x):
>          try: return _m_log10(x)
>          except TypeError: return _n_log10(x)
>      def modf(x):
>          try: return _m_modf(x)
>          except TypeError: return _n_modf(x)
>      def sin(x):
>          try: return _m_sin(x)
>          except TypeError: return _n_sin(x)
>      def sinh(x):
>          try: return _m_sinh(x)
>          except TypeError: return _n_sinh(x)
>      def sqrt(x):
>          try: return _m_sqrt(x)
>          except TypeError: return _n_sqrt(x)
>      def tan(x):
>          try: return _m_tan(x)
>          except TypeError: return _n_tan(x)
>      def tanh(x):
>          try: return _m_tanh(x)
>          except TypeError: return _n_tanh(x)
>
> --Scott David Daniels
> Sco...@Ac...
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>   

Re: [Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

In a test version not yet released I've implemented essentially the 
scheme suggested by Scott David Daniels, and it works very well. Thanks!

I found by timing measurements that a faster scheme with less penalty 
for the case of sqrt(array) looks like this:

def sqrt(x):
     if type(x) is float: return mathsqrt(x)
     return numpysqrt(x)

This scheme not only solves the problem but actually yields faster 
square roots of scalar arguments than numpy, by about a factor of 3. So 
what was conceived as a workaround is actually a performance enhancement.

Bruce Sherwood

Scott David Daniels wrote:
> I (Scott David Daniels) wrote:
>   
>> I'm not sure of the overhead here, but could something like this work?
>>
>>      def sqrt(x):
>>          try: return math.sqrt(x)
>>          except TypeError: return numpy.sqrt(x)
>>     
>
> If it "kinda" works, the following addition to __init__ should work:
>
>      from numpy import (ceil as _n_ceil, cos as _n_cos, cosh as _n_cosh,
>                    exp as _n_exp, fabs as _n_fabs, floor as _n_floor,
>                    fmod as _n_fmod, frexp as _n_frexp, hypot as _n_hypot,
>                    ldexp as _n_ldexp, log as _n_log, log10 as _n_log10,
>                    modf as _n_modf, sin as _n_sin, sinh as _n_sinh,
>                    sqrt as _n_sqrt, tan as _n_tan, tanh as _n_tanh)
>      from math import (ceil as _m_ceil, cos as _m_cos, cosh as _m_cosh,
>                    exp as _m_exp, fabs as _m_fabs, floor as _m_floor,
>                    fmod as _m_fmod, frexp as _m_frexp, hypot as _m_hypot,
>                    ldexp as _m_ldexp, log as _m_log, log10 as _m_log10,
>                    modf as _m_modf, sin as _m_sin, sinh as _m_sinh,
>                    sqrt as _m_sqrt, tan as _m_tan, tanh as _m_tanh)
>      def ceil(x):
>          try: return _m_ceil(x)
>          except TypeError: return _n_ceil(x)
>      def cos(x):
>          try: return _m_cos(x)
>          except TypeError: return _n_cos(x)
>      def cosh(x):
>          try: return _m_cosh(x)
>          except TypeError: return _n_cosh(x)
>      def exp(x):
>          try: return _m_exp(x)
>          except TypeError: return _n_exp(x)
>      def fabs(x):
>          try: return _m_fabs(x)
>          except TypeError: return _n_fabs(x)
>      def floor(x):
>          try: return _m_floor(x)
>          except TypeError: return _n_floor(x)
>      def fmod(x):
>          try: return _m_fmod(x)
>          except TypeError: return _n_fmod(x)
>      def frexp(x):
>          try: return _m_frexp(x)
>          except TypeError: return _n_frexp(x)
>      def hypot(x):
>          try: return _m_hypot(x)
>          except TypeError: return _n_hypot(x)
>      def ldexp(x):
>          try: return _m_ldexp(x)
>          except TypeError: return _n_ldexp(x)
>      def log(x):
>          try: return _m_log(x)
>          except TypeError: return _n_log(x)
>      def log10(x):
>          try: return _m_log10(x)
>          except TypeError: return _n_log10(x)
>      def modf(x):
>          try: return _m_modf(x)
>          except TypeError: return _n_modf(x)
>      def sin(x):
>          try: return _m_sin(x)
>          except TypeError: return _n_sin(x)
>      def sinh(x):
>          try: return _m_sinh(x)
>          except TypeError: return _n_sinh(x)
>      def sqrt(x):
>          try: return _m_sqrt(x)
>          except TypeError: return _n_sqrt(x)
>      def tan(x):
>          try: return _m_tan(x)
>          except TypeError: return _n_tan(x)
>      def tanh(x):
>          try: return _m_tanh(x)
>          except TypeError: return _n_tanh(x)
>
> --Scott David Daniels
> Sco...@Ac...
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>   

Re: [Visualpython-users] 4.beta21

[Scott D. D. <Sco...@Ac...>]

Bruce Sherwood wrote:
> In a test version not yet released I've implemented essentially the 
> scheme suggested by Scott David Daniels, and it works very well. Thanks!
> 
> I found by timing measurements that a faster scheme with less penalty 
> for the case of sqrt(array) looks like this:
> 
> def sqrt(x):
>      if type(x) is float: return mathsqrt(x)
>      return numpysqrt(x)
> 
> This scheme not only solves the problem but actually yields faster 
> square roots of scalar arguments than numpy, by about a factor of 3. So 
> what was conceived as a workaround is actually a performance enhancement.

I actually did a bit of timing before I suggested the try/except version.
I use subclasses of ints and floats in some of the code I write.
A simple example (to make values more obvious):
      class Float(float):
          def __repr__(self):
              return '%s(%s)' % (self.__class__.__name__,
                                 float.__repr__(self))
      class Meters(Float): pass
      class Grams(Float): pass
      ...
Then I can make physical constants a little more obvious interactively.

My first version was:
     def sqrt(x):
         if isinstance(x, (int, long, float)):
             return mathsqrt(x)
         else:
             return numpysqrt(x)

I then realized math.sqrt was already doing this check.  Since the check
is already there, I decided not to slow down the more common scalar
case.  That was when I switched to the "try: ... except TypeError: ..."
form (to use math.sqrt's type checks).  I then made sure performance on
a short (ten-element) vector was not too severely impacted.  If you
still want to exact match on types, I'd suggest accepting at least
floats and ints, since you'll otherwise get performance reports about
how much slower sqrt(4) is than sqrt(4.0).

Something more like:
     def sqrt(x):
         t = type(x)
         if t is float or t is int:
             return mathsqrt(x)
         else:
             return numpysqrt(x)

--Scott David Daniels
Sco...@Ac...

Re: [Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

Good points. Thanks.

Bruce Sherwood

Scott David Daniels wrote:
> Bruce Sherwood wrote:
>   
>> In a test version not yet released I've implemented essentially the 
>> scheme suggested by Scott David Daniels, and it works very well. Thanks!
>>
>> I found by timing measurements that a faster scheme with less penalty 
>> for the case of sqrt(array) looks like this:
>>
>> def sqrt(x):
>>      if type(x) is float: return mathsqrt(x)
>>      return numpysqrt(x)
>>
>> This scheme not only solves the problem but actually yields faster 
>> square roots of scalar arguments than numpy, by about a factor of 3. So 
>> what was conceived as a workaround is actually a performance enhancement.
>>     
>
> I actually did a bit of timing before I suggested the try/except version.
> I use subclasses of ints and floats in some of the code I write.
> A simple example (to make values more obvious):
>       class Float(float):
>           def __repr__(self):
>               return '%s(%s)' % (self.__class__.__name__,
>                                  float.__repr__(self))
>       class Meters(Float): pass
>       class Grams(Float): pass
>       ...
> Then I can make physical constants a little more obvious interactively.
>
> My first version was:
>      def sqrt(x):
>          if isinstance(x, (int, long, float)):
>              return mathsqrt(x)
>          else:
>              return numpysqrt(x)
>
> I then realized math.sqrt was already doing this check.  Since the check
> is already there, I decided not to slow down the more common scalar
> case.  That was when I switched to the "try: ... except TypeError: ..."
> form (to use math.sqrt's type checks).  I then made sure performance on
> a short (ten-element) vector was not too severely impacted.  If you
> still want to exact match on types, I'd suggest accepting at least
> floats and ints, since you'll otherwise get performance reports about
> how much slower sqrt(4) is than sqrt(4.0).
>
> Something more like:
>      def sqrt(x):
>          t = type(x)
>          if t is float or t is int:
>              return mathsqrt(x)
>          else:
>              return numpysqrt(x)
>
> --Scott David Daniels
> Sco...@Ac...
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>   

Re: [Visualpython-users] 4.beta21

[Bruce S. <Bru...@nc...>]

I repeated my own timings and then remembered why I didn't use 
try/except. The try/except scheme does give the fastest square root of a 
scalar (1.2 microsec on my 1 GHz laptop) but doubles the time for 
sqrt(array([1,2,3,4,5,6,7,8,9,10])), from about 10 microsec to about 20 
microsec. So I've settled for the following, which gives sqrt(scalar) of 
1.7 microsec and almost no change in sqrt(array):

def sqrt(x):
    t = type(x)
    if t is float or t is int or t is long: return _m_sqrt(x)
    return _n_sqrt(x)

Thanks again for thinking about this issue, and for alerting me to check 
not just for float.

Bruce Sherwood

P.S. What's in the just-released 4.beta22 only checks for float, but the 
correction is now in CVS.

Scott David Daniels wrote:
> Bruce Sherwood wrote:
>   
>> In a test version not yet released I've implemented essentially the 
>> scheme suggested by Scott David Daniels, and it works very well. Thanks!
>>
>> I found by timing measurements that a faster scheme with less penalty 
>> for the case of sqrt(array) looks like this:
>>
>> def sqrt(x):
>>      if type(x) is float: return mathsqrt(x)
>>      return numpysqrt(x)
>>
>> This scheme not only solves the problem but actually yields faster 
>> square roots of scalar arguments than numpy, by about a factor of 3. So 
>> what was conceived as a workaround is actually a performance enhancement.
>>     
>
> I actually did a bit of timing before I suggested the try/except version.
> I use subclasses of ints and floats in some of the code I write.
> A simple example (to make values more obvious):
>       class Float(float):
>           def __repr__(self):
>               return '%s(%s)' % (self.__class__.__name__,
>                                  float.__repr__(self))
>       class Meters(Float): pass
>       class Grams(Float): pass
>       ...
> Then I can make physical constants a little more obvious interactively.
>
> My first version was:
>      def sqrt(x):
>          if isinstance(x, (int, long, float)):
>              return mathsqrt(x)
>          else:
>              return numpysqrt(x)
>
> I then realized math.sqrt was already doing this check.  Since the check
> is already there, I decided not to slow down the more common scalar
> case.  That was when I switched to the "try: ... except TypeError: ..."
> form (to use math.sqrt's type checks).  I then made sure performance on
> a short (ten-element) vector was not too severely impacted.  If you
> still want to exact match on types, I'd suggest accepting at least
> floats and ints, since you'll otherwise get performance reports about
> how much slower sqrt(4) is than sqrt(4.0).
>
> Something more like:
>      def sqrt(x):
>          t = type(x)
>          if t is float or t is int:
>              return mathsqrt(x)
>          else:
>              return numpysqrt(x)
>
> --Scott David Daniels
> Sco...@Ac...
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>