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
>