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
>