[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