visualpython-users

[Visualpython-users] Stuff from the past

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

When you execute "from visual import *" the following code in
__init__.py is executed:

if 1:
    # Names defined for backward compatibility with Visual 3:
    import sys, time
    true = True
    false = False
    crayola = color
    from cvisual import vector_array, scalar_array

With the break represented by Python 2 -> 3, I propose deleting
"import sys, time" and "from cvisual import vector_array,
scalar_array".

It seems harmless to retain the definitions of true and false (which
were added to Visual very early, before Python offered True and
False), and the definition of crayola. All of these now unneeded
entities are embedded in very old programs that people expect to
continue working. A real-life example is an instructor using some old
demo program in class, with some old or new version of Python. The
instructor may know little more about VPython than to doubleclick on
an inherited program, and if there are no serious consequences for the
future it makes sense to keep old programs working. (Of course old
print statements will fail on Python 3, and there's no solution for
that.) I don't see any serious consequences: If you use "true" when
you intend "True" it's fine, and if you assign "true = 17" you
override Visual's definition.

Probably very few people were even aware that sys and time were being
imported, and I strongly suspect that no one exploited these imports
after the very early period in the development of Visual (starting in
2000). I searched in various places for "sys." and "time." without
finding any instances other than programs that specifically imported
sys or time themselves.

The case of vector_array and scalar_array is more complex. In August
2003 Jonathan Brandmeyer created these objects with an eye to using
these objects to eliminate dependence of Visual on Numeric
(predecessor of numpy), which is used for some attributes of the array
objects (curve, convex, faces, points), including pos, color, and
normal (for faces). It seemed possible to use vector_array for these
arrays of vectors. However, in December 2003 he reverted to using
Numeric arrays for these attributes when it became apparent that there
were a number of existing interesting programs that needed the
capabilities of Numeric arrays; examples include drape.py, wave.py,
and toroid_drag.py.

In March 2003 he released VPython 2.9 which retained the use of
Numeric for array object attributes but announced this:

"New classes vector_array and scalar_array: these have an interface
similar to that provided by Numeric, but it provides
3D-vector-specific operations that are significantly faster than
Numeric and are more readable than the equivalent Numeric code."

These new classes were never described in the Visual Help and seem
never to have really been used. When I tried some things with
vector_array this week I found for example that subtracting one
vector_array from another yielded their sum, due to a typo in the
code. There is no slicing machinery. You can't take the cosine of such
an array. And so on. It doesn't make sense to try to extend
vector_array to do all the things that numpy does, which is a huge
package.

The example program crystal.py, originally written by me but rewritten
by Jonathan, does use vector_array, but that's the only example I've
run across (and I've succeeded with some effort to rewrite it to use
numpy). It is true that it runs faster with more readable code using
vector_array, but I'm afraid that it just isn't sufficiently general.

Here is the vector_array code from crystal.py, where a.nearpos is a
list of the sphere.pos locations of those atoms that are closest
neighbors to atom a (so a.nearpos is essentially a list of pointers):

        r = vector_array(a.nearpos) - a.pos
        a.p += k_dt *(r.norm()*(r.mag()-L)).sum()

Here is the equivalent numpy array code crystal.py:

        r = array(a.nearpos) - a.pos
        rmag = (sqrt(sum(square(r),-1))).reshape(-1,1)
        a.p += k_dt * sum((1-L/rmag)*r,0)

This whole episode however does raise an interesting question. The
numpy package has major subpackages such as fft and linalg. As far as
I can tell, nowhere in numpy are there functions that are specifically
attuned to the 3D vectors that are central to the tasks for which
VPython is designed; it would be great if there were such a package. A
big advantage of numpy is its generality, handling arrays that are M
by N by .... But for our purposes it is a disadvantage that there
isn't somewhere in numpy tuned specifically to 3D geometry. For
example, there is a function ("norm") in numpy.linalg, but I have been
unable to figure out how to get it to take the magnitudes of an array
of 3D vectors; it seems capable solely of taking the square of the sum
of the squares of ALL the components of ALL the 3D vectors. I think
the main reason why the numpy version of crystal.py is slower than the
vector_array version is the necessity of making several more function
calls.

Comments?

Bruce

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

In this context, we could invent conventions for the "as" name, such
as "import visual.objects as vo", as has been done by the scipy.org
community. Here is what they say at
http://docs.scipy.org/doc/scipy/reference/tutorial/general.html:

For brevity and convenience, we will often assume that the main
packages (numpy, scipy, and matplotlib) have been imported as:

>>> import numpy as np
>>> import scipy as sp
>>> import matplotlib as mpl
>>> import matplotlib.pyplot as plt

These are the import conventions that our community has adopted after
discussion on public mailing lists. You will see these conventions
used throughout NumPy and SciPy source code and documentation. While
we obviously don’t require you to follow these conventions in your own
code, it is highly recommended.

On Wed, Sep 15, 2010 at 10:54 PM, Bruce Sherwood <bas...@nc...> wrote:
> I'll immediately offer an alternative. Suppose there is in the visual
> folder a file vobjects.py containing this:
>
> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>                               frame, pyramid, ellipsoid, curve,
> faces, convex, helix,
>                               points, text, distant_light, local_light)
>
> Then you could do this:
>
> import visual.vobjects as vo
> c = vo.curve(pos=[(0,0,0), (1,0,0), (0,1,0)])
>
> Would this be preferable to the following?
>
> from visual.primitives import curve
> c = curve(pos=[(0,0,0), (1,0,0), (0,1,0)])
>
> Similarly, there could be a visual/vector.py file for the vector stuff
> (vector, mag, etc.). There are already visual.crayola and
> visual.materials files of this kind.
>
> Bruce Sherwood

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

I'll immediately offer an alternative. Suppose there is in the visual
folder a file vobjects.py containing this:

from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                               frame, pyramid, ellipsoid, curve,
faces, convex, helix,
                               points, text, distant_light, local_light)

Then you could do this:

import visual.vobjects as vo
c = vo.curve(pos=[(0,0,0), (1,0,0), (0,1,0)])

Would this be preferable to the following?

from visual.primitives import curve
c = curve(pos=[(0,0,0), (1,0,0), (0,1,0)])

Similarly, there could be a visual/vector.py file for the vector stuff
(vector, mag, etc.). There are already visual.crayola and
visual.materials files of this kind.

Bruce Sherwood

P.S. You might be wondering where numpy comes into this, considering
that for example the pos attribute of curve is a numpy array. The
numpy machinery is imported into the C++ component of Visual by
__init__.py, which is executed when you import (say) visual.primitive.
In the tiny program above, if you print(type(c.pos)) you'll see <class
'numpy.ndarray'>, and if you print(3*c.pos)) you'll see a 3 by 3 array
displayed that is 3 times that of c.pos. But your own namespace
doesn't contain numpy's array object, and trying to set b =
array([1,2,3]) gives an error: array not defined.

[Visualpython-users] Let's hash out the documentation for restrictive imports

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

Here I start a new thread with the proposal that we collectively come
up with documentation for those users who want to be careful about
namespace cleanliness. Below I reproduce a sample of an import
strategy that worked for gas.py as an alternative to "from visual
import *". It isn't fully restrictive, because for purposes of
completeness I've imported all of the vector stuff, all of the
primitives, and materials (which aren't used in gas.py), so it's just
a proof of concept. I'm suggesting that working together we ought to
be able to come up with one or a few recommended schemes for use when
"from visual import *" is not suitable. I want to emphasize that I
believe strongly that the latter scheme has its place, but it is
desirable to provide guidance for an alternative approach that doesn't
import all of math and all of numpy.

You're invited to post what you think would be a useful and
appropriate example of import strategy, with my own example being a
proof of concept but presumably not exactly what we might all agree is
most useful as advice.

Further caveat: Although gas.py is a pretty good test case, since it
uses visual objects, math, and numpy, it may well be that I've missed
something.

Bruce Sherwood

Example:

from visual.cvisual import (vector, mag, mag2, norm, dot, cross, rotate,
                      comp, proj, diff_angle, rate, waitclose)
from visual.primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                              frame, pyramid, ellipsoid, curve,
                              faces, convex, helix,
                              points, text, distant_light, local_light)
from visual.ui import display
import visual.crayola as color
import visual.materials as materials
import visual.site_settings
import atexit as _atexit
_atexit.register(waitclose)
from math import pi, sin, cos, exp
from numpy import (sqrt, array, newaxis, add, less_equal, identity,
                  sort, nonzero, greater_equal, arange)
from visual.graph import (gdisplay, gcurve, ghistogram)
from random import random

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Craig S. <cra...@ma...>]

I like Jim's example of matplotlib: a simple package (pylab) for some users, but more pythonic imports for python experts.

Jim's point of very novice users is important to me. We've used VPython to teach high school teachers from a variety of disciplines. The approach of

from visual import *

to include a wide range of useful classes, functions, etc. is a quick way to get the teachers (and hopefully their students) going. Computationally oriented people (e.g., engineers, computer scientists, mathematicians, etc.) are only a small portion of the audience I target.

It could be argued another tool is more appropriate, but the fact that Python scales well from small scripts for novices to large scientific computing applications for experts is very appealing.

So, with some effort, I think VPython can have it both ways. I believe it should.

    Craig

On Sep 15, 2010, at 7:59 PM, Guy K. Kloss wrote:

> On Thu, 16 Sep 2010 11:42:30 James Mueller wrote:
>>        I have to admit that I am a bit offended by the "physicist make
>> happy" comments.  What is being referred to here are in general NOT
>> physicists. 
> 
> Sorry, no offence intended. But the "physicists" were just the ones commonly 
> used here as a representative group of users that are not Computer Scientists.
> 
> If this is a feature needed for this or similar groups, then that's fine. It 
> would be just a huge shame if the visual package therefore would be spoiled 
> for more users with more ambitious Python/programming knowledge.
> 
>> Bruce's target audience is College Freshmen, (mainly future
>> engineers), who have never taken any programing course.  Bruce wants to
>> allow them to investigate their course material visually, and uses the
>> python environment to do that.  The concept of namespace is lost on
>> them.  I know, as I am teaching some of them right now.  In their
>> "computing for freshman engineers" course, they are currently learning
>> excel.  Next term they plan to teach them Matlab.  They don't know
>> variables; they don't know for or while loops; they don't know physics;
>> THEY DON'T KNOW ANYTHING!  So don't call them physicists.
> 
> Again, sorry for that, it was just the common nomination previously here.
> 
> BTW, I'm an engineer myself (chemical engineer), and the concepts involved are 
> not hard to understand. Python is also being taught to engineers at Auckland 
> University (one of our PUG members teaches them), and they've got no problems 
> to understand. After all, engineers are technical and logically thinking 
> people, so they've got what it takes to think in systematic ways.
> 
>> Other than that,
>> I agree with everything you said.  What I would like to see is something
>> like matplotlib where they cleaned up the code but kept the pylab module
>> to preserve functionality.  People who know what they are doing, might do
>> 
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import scipy
>> 
>> etc.  but one can also just do
>> 
>> import pylab
>> 
>> which ends up importing all sorts of things into the pylab namespace (I am
>> not sure how much).  And again most people continue to use it as 
>> 
>> from pylab import *
>> 
>> We can cringe, and tell them not to do it, but it was important that the
>> option was preserved.  The matplotlib people provide the option but also
>> provide ways to do things properly.  I see the same thing in this
>> case.  If the code could be rearranged to have proper granularity and
>> allow people to use namspaces properly, that would be great!  WE do not
>> need to use the "visual" name for that.  Then "visual" can just be
>> something that imports everything to reproduce the current visual
>> namespace.  We don't need to care as we can use the "correct" imports, as
>> long as they exist and are documented.  From Bruce's mail, it seems like
>> the option is there to separate the namespaces. whether this is the
>> correct separation, I don't know, but seeing all the things visual
>> currently loads into one namespace is great.  I can start to use things
>> properly.  Most of my students will still "from visual import *", but I
>> have something to tell those who do know a little programming.
> 
> My biggest issue with the current way visual handles things is, that it 
> imports all kinds of non-visual related things from the math and numpy 
> packages. And it would get even worse if things imported then are also being 
> renamed ("from spam import eggs as seggs").
> 
> Namespaces back and forth, certain things just shouldn't be pulled in by a 
> base package named visual, that are completely unrelated.
> 
>> As always, the devil is in the details, but I think this thread will
>> continue.
> 
> Yes, indeed. And the issue can only be resolved if it's being discussed.
> 
> Only with positive intentions,
> 
> Guy
> 
> -- 
> Guy K. Kloss
> Institute of Information and Mathematical Sciences
> Te Kura Pūtaiao o Mōhiohio me Pāngarau
> Massey University, Albany (North Shore City, Auckland)
> 473 State Highway 17, Gate 1, Mailroom, Quad B Building
> voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
> G....@ma... http://www.massey.ac.nz/~gkloss
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

--
Craig A. Struble, Ph.D. | Marquette University
Associate Professor of Computer Science | 369 Cudahy Hall
(414)288-3783 | (414)288-5472 (fax)
http://www.mscs.mu.edu/~cstruble | cra...@ma...

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Guy K. K. <g....@ma...>]

On Thu, 16 Sep 2010 11:42:30 James Mueller wrote:
>         I have to admit that I am a bit offended by the "physicist make
> happy" comments.  What is being referred to here are in general NOT
> physicists. 

Sorry, no offence intended. But the "physicists" were just the ones commonly 
used here as a representative group of users that are not Computer Scientists.

If this is a feature needed for this or similar groups, then that's fine. It 
would be just a huge shame if the visual package therefore would be spoiled 
for more users with more ambitious Python/programming knowledge.

> Bruce's target audience is College Freshmen, (mainly future
> engineers), who have never taken any programing course.  Bruce wants to
> allow them to investigate their course material visually, and uses the
> python environment to do that.  The concept of namespace is lost on
> them.  I know, as I am teaching some of them right now.  In their
> "computing for freshman engineers" course, they are currently learning
> excel.  Next term they plan to teach them Matlab.  They don't know
> variables; they don't know for or while loops; they don't know physics;
> THEY DON'T KNOW ANYTHING!  So don't call them physicists.

Again, sorry for that, it was just the common nomination previously here.

BTW, I'm an engineer myself (chemical engineer), and the concepts involved are 
not hard to understand. Python is also being taught to engineers at Auckland 
University (one of our PUG members teaches them), and they've got no problems 
to understand. After all, engineers are technical and logically thinking 
people, so they've got what it takes to think in systematic ways.

> Other than that,
> I agree with everything you said.  What I would like to see is something
> like matplotlib where they cleaned up the code but kept the pylab module
> to preserve functionality.  People who know what they are doing, might do
> 
> import numpy as np
> import matplotlib.pyplot as plt
> import scipy
> 
> etc.  but one can also just do
> 
> import pylab
> 
> which ends up importing all sorts of things into the pylab namespace (I am
> not sure how much).  And again most people continue to use it as 
> 
> from pylab import *
> 
> We can cringe, and tell them not to do it, but it was important that the
> option was preserved.  The matplotlib people provide the option but also
> provide ways to do things properly.  I see the same thing in this
> case.  If the code could be rearranged to have proper granularity and
> allow people to use namspaces properly, that would be great!  WE do not
> need to use the "visual" name for that.  Then "visual" can just be
> something that imports everything to reproduce the current visual
> namespace.  We don't need to care as we can use the "correct" imports, as
> long as they exist and are documented.  From Bruce's mail, it seems like
> the option is there to separate the namespaces. whether this is the
> correct separation, I don't know, but seeing all the things visual
> currently loads into one namespace is great.  I can start to use things
> properly.  Most of my students will still "from visual import *", but I
> have something to tell those who do know a little programming.

My biggest issue with the current way visual handles things is, that it 
imports all kinds of non-visual related things from the math and numpy 
packages. And it would get even worse if things imported then are also being 
renamed ("from spam import eggs as seggs").

Namespaces back and forth, certain things just shouldn't be pulled in by a 
base package named visual, that are completely unrelated.

> As always, the devil is in the details, but I think this thread will
> continue.

Yes, indeed. And the issue can only be resolved if it's being discussed.

Only with positive intentions,

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[James M. <mu...@pi...>]

> * For newbie's convenience, provide a "physicists make happy" package that
>   does the wild card imports all across the board.
>   (Even though I'm of the opinion that this dirty short cut creates more
>   head scratching in the future than it helps up front ...)
Guy,
	I have to admit that I am a bit offended by the "physicist make happy" comments.  What is being referred to here are in general NOT physicists.  Bruce's target audience is College Freshmen, (mainly future engineers), who have never taken any programing course.  Bruce wants to allow them to investigate their course material visually, and uses the python environment to do that.  The concept of namespace is lost on them.  I know, as I am teaching some of them right now.  In their "computing for freshman engineers" course, they are currently learning excel.  Next term they plan to teach them Matlab.  They don't know variables; they don't know for or while loops; they don't know physics; THEY DON'T KNOW ANYTHING!  So don't call them physicists.
	Other than that, I agree with everything you said.  What I would like to see is something like matplotlib where they cleaned up the code but kept the pylab module to preserve functionality.  People who know what they are doing, might do

import numpy as np
import matplotlib.pyplot as plt
import scipy

etc.  but one can also just do

import pylab

which ends up importing all sorts of things into the pylab namespace (I am not sure how much).  And again most people continue to use it as 

from pylab import *

We can cringe, and tell them not to do it, but it was important that the option was preserved.  The matplotlib people provide the option but also provide ways to do things properly.  I see the same thing in this case.  If the code could be rearranged to have proper granularity and allow people to use namspaces properly, that would be great!  WE do not need to use the "visual" name for that.  Then "visual" can just be something that imports everything to reproduce the current visual namespace.  We don't need to care as we can use the "correct" imports, as long as they exist and are documented.  From Bruce's mail, it seems like the option is there to separate the namespaces. whether this is the correct separation, I don't know, but seeing all the things visual currently loads into one namespace is great.  I can start to use things properly.  Most of my students will still "from visual import *", but I have something to tell those who do know a little programming.

As always, the devil is in the details, but I think this thread will continue.

-Jim

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Guy K. K. <g....@ma...>]

Thanks a lot. This code looks *much* more Pythonic already.

On Thu, 16 Sep 2010 06:59:14 Bruce Sherwood wrote:
> Here's another successful test. I replaced the import statements at
> the start of the example program gas.py with the following import
> statements, and deleted the old Numeric code in a try structure:
> 
> from visual.cvisual import (vector, mag, mag2, norm, dot, cross, rotate,
>                        comp, proj, diff_angle, rate, waitclose)
> from visual.primitives import (arrow, cylinder, cone, sphere, box, ring,
> label, frame, pyramid, ellipsoid, curve,
> faces, convex, helix,
>                                points, text, distant_light, local_light)

Another possibility would be to just say

from visual import primitives

And then in the code you could create e. g. a cone using primitives.cone.

Much cleaner than trying to pull in *all* the individual objects into the 
local name space.

> from visual.ui import display
> import visual.crayola as color
> import visual.materials as materials

Do one like this here:

from visual import materials

> import visual.site_settings
> import atexit as _atexit
> _atexit.register(waitclose)
> from math import pi, sin, cos, exp
> from numpy import (sqrt, array, newaxis, add, less_equal, identity,
>                    sort, nonzero, greater_equal, arange)
> from visual.graph import (gdisplay, gcurve, ghistogram)
> from random import random
> 
> This could have been more selective, since gas.py uses only a few of
> the vector and primitive features. Also, gas.py already has a scene =
> display(....) statement.
> 
> A subtle point that one should be aware of: In visual's __init__.py
> there is some complex machinery to deal with the fact that when, for
> example, you're taking the square root of a scalar you want to use the
> math module's sqrt, because it is much faster than using numpy's sqrt.
> On the other hand, you need to use numpy's sqrt if you're taking the
> square roots of all the elements of a numpy array. For functions such
> as sqrt you would want to do something like this:
> 
> from math import sqrt as msqrt
> from numpy import sqrt as nsqrt

Then why "rename" these things? Just import math and numpy directly and use 
numpy.sqrt() or math.sqrt()

This is *much* more clear ("explicit is better than implicit"), as otherwise 
users might be digging through the Python/NumPy docs to look for the 
description of msqrt or nsqrt.

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Guy K. K. <g....@ma...>]

On Thu, 16 Sep 2010 06:49:55 Bruce Sherwood wrote:
> I want to leave "from visual import *" in place,

I strongly disagree.

> a "batteries included" environment (also a pythonic concept).

"Batteries included" is, but not batteries constantly inserted and 
discharging!

As I sais, with Py3k you're facing a change in code and samples anyway. And I 
think that something like C Anthony's suggestion gives the freedom of 
retaining backwards compatibility with only a minor fix, just for convenience 
reason. But the *norm* in Python is to have things split up into places where 
they belong, and to not overshadow things (paradigm "explicit is better than 
implicit"). So if I want to use the cosine function (cos()), then I'm either 
going to import it *myself* from math or numpy, depending on what I want. And 
I do not want to be tripped up by some awkward changes as an unexpected one is 
being called. Besides, things like these mathematical functions don't really 
belong into a package called "visual" anyway.

So, my suggestion:

 * Use the convenience of a Py3k switch to sanitise the API.

 * Remove all the wild card imports, and have the user import what they need.

 * For newbie's convenience, provide a "physicists make happy" package that
   does the wild card imports all across the board.
   (Even though I'm of the opinion that this dirty short cut creates more
   head scratching in the future than it helps up front ...)

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[C A. R. <an...@ex...>]

On Wed, Sep 15, 2010 at 11:51 AM, Bruce Sherwood <bas...@nc...> wrote:
> A colleague points out that visual.basic (Visual Basic) maybe isn't
> the most intelligent nomenclature....
>
> So if this idea has merit, there is at least the question of what the
> file should really be named.

My thought was to create a dedicated namespace/module, for these
"specialized" environments; something like:

visual.framework.physics
visual.framework.<insert here>

this would open the door for other special interest groups, if any, to
create there own modules that import whatever they want to create a
base environment for the novices in their particular field.

additionally...

from visual.framework.physics import *

is still a pretty easy one-liner.  Relating to your "basic.py"
example, my preference would be that everything exist in it's own
module, example:

from visual.vector import mag, mag2, ..., ...

I see that primitives/ui/materials/etc. (from your example) seem to
already be nicely broken up.  I'm not very familiar with visual
internally, having only used it in projects.  In short, I guess I'm
just the kind of developer that likes everything to be explicitly
included, and nothing else, but that's just me :-).

At any rate, visual is a great tool, and I would like to see it become
flexible enough for embedding, and any other use cases; great stuff.

C Anthony

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

Here's another successful test. I replaced the import statements at
the start of the example program gas.py with the following import
statements, and deleted the old Numeric code in a try structure:

from visual.cvisual import (vector, mag, mag2, norm, dot, cross, rotate,
                       comp, proj, diff_angle, rate, waitclose)
from visual.primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                               frame, pyramid, ellipsoid, curve,
faces, convex, helix,
                               points, text, distant_light, local_light)
from visual.ui import display
import visual.crayola as color
import visual.materials as materials
import visual.site_settings
import atexit as _atexit
_atexit.register(waitclose)
from math import pi, sin, cos, exp
from numpy import (sqrt, array, newaxis, add, less_equal, identity,
                   sort, nonzero, greater_equal, arange)
from visual.graph import (gdisplay, gcurve, ghistogram)
from random import random

This could have been more selective, since gas.py uses only a few of
the vector and primitive features. Also, gas.py already has a scene =
display(....) statement.

A subtle point that one should be aware of: In visual's __init__.py
there is some complex machinery to deal with the fact that when, for
example, you're taking the square root of a scalar you want to use the
math module's sqrt, because it is much faster than using numpy's sqrt.
On the other hand, you need to use numpy's sqrt if you're taking the
square roots of all the elements of a numpy array. For functions such
as sqrt you would want to do something like this:

from math import sqrt as msqrt
from numpy import sqrt as nsqrt

Then you would use msqrt or nsqrt depending on the argument. The
machinery in __init__.py takes care of this for you and applies the
faster sqrt when the argument is a scalar.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

Suppose we don't add any new file to site-packages/visual but simply
document something like the following, for the ultimate flexibility
that some people want and need. Here is a little program that
explicitly imports individual components and then uses them:

# Very explicit imports:
from visual.cvisual import (vector, mag, mag2, norm, cross, rotate,
                      comp, proj, diff_angle, rate, waitclose)
from visual.primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                              frame, pyramid, ellipsoid, curve,
faces, convex, helix,
                              points, text, distant_light, local_light)
from visual.ui import display
import visual.crayola as color
import visual.materials as materials
import visual.site_settings
import atexit as _atexit
_atexit.register(waitclose)
scene = display()
# Now use this stuff:
box(pos=(1.5,0,0), color=color.orange, material=materials.wood)
C = curve(pos=[(0,0,0),(1,0,0),(1,1,0),(0,1,0)], color=color.cyan)
print(C.pos)
scene.mouse.getclick()
scene2 = display(x=400)
sphere()

I don't know whether the imports listed above really do span the
space, which requires more testing.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

For lots of reasons (including existing documentation and programs,
not restricted to the documentation and programs that come with
VPython), unless there are extremely strong arguments to justify a
change, I want to leave "from visual import *" in place, a "batteries
included" environment (also a pythonic concept). But I'm happy to
introduce a new way to import visual that is restrictive. I'm
certainly not tied to the little experiment I've just carried out. As
you say, perhaps my little file should be split into separate pieces.

Bruce SherwoodOn Wed, Sep 15, 2010 at 11:22 AM, C Anthony Risinger
<an...@ex...> wrote:
> On Wed, Sep 15, 2010 at 11:51 AM, Bruce Sherwood <bas...@nc...> wrote:
>> A colleague points out that visual.basic (Visual Basic) maybe isn't
>> the most intelligent nomenclature....
>>
>> So if this idea has merit, there is at least the question of what the
>> file should really be named.
>
> My thought was to create a dedicated namespace/module, for these
> "specialized" environments; something like:
>
> visual.framework.physics
> visual.framework.<insert here>
>
> this would open the door for other special interest groups, if any, to
> create there own modules that import whatever they want to create a
> base environment for the novices in their particular field.
>
> additionally...
>
> from visual.framework.physics import *
>
> is still a pretty easy one-liner.  Relating to your "basic.py"
> example, my preference would be that everything exist in it's own
> module, example:
>
> from visual.vector import mag, mag2, ..., ...
>
> I see that primitives/ui/materials/etc. (from your example) seem to
> already be nicely broken up.  I'm not very familiar with visual
> internally, having only used it in projects.  In short, I guess I'm
> just the kind of developer that likes everything to be explicitly
> included, and nothing else, but that's just me :-).
>
> At any rate, visual is a great tool, and I would like to see it become
> flexible enough for embedding, and any other use cases; great stuff.
>
> C Anthony

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

A colleague points out that visual.basic (Visual Basic) maybe isn't
the most intelligent nomenclature....

So if this idea has merit, there is at least the question of what the
file should really be named.

Bruce Sherwood

On Wed, Sep 15, 2010 at 10:24 AM, Bruce Sherwood <bas...@nc...> wrote:
> Maybe the desire for a cleaner import of visual isn't a big deal. I
> put the following code in site-packages/visual/basic.py:
>
> from . cvisual import (vector, mag, mag2, norm, cross, rotate,
>                       comp, proj, diff_angle, rate, waitclose)
> from visual.primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>                               frame, pyramid, ellipsoid, curve,
> faces, convex, helix,
>                               points, text, distant_light, local_light)
> from visual.ui import display
> from . import crayola as color
> from . import materials
> from . import site_settings
> import atexit as _atexit
> _atexit.register(waitclose)
> scene = display()
>
> Next I successfully ran some little programs such as this one:
>
> import visual.basic as vb
> vb.box(pos=(1.5,0,0), color=vb.color.orange, material=vb.materials.wood)
> C = vb.curve(pos=[(0,0,0),(1,0,0),(1,1,0),(0,1,0)], color=vb.color.cyan)
> print(C.pos)
> vb.scene.mouse.getclick()
> scene2 = vb.display(x=400)
> vb.sphere()
>
> I haven't done extensive testing, and I'm interested in suggestions
> for improvement. The key point of course is that this doesn't import
> all of math and numpy, but leaves "from visual import *" still
> available.
>
> Bruce Sherwood
>

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

Maybe the desire for a cleaner import of visual isn't a big deal. I
put the following code in site-packages/visual/basic.py:

from . cvisual import (vector, mag, mag2, norm, cross, rotate,
                       comp, proj, diff_angle, rate, waitclose)
from visual.primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                               frame, pyramid, ellipsoid, curve,
faces, convex, helix,
                               points, text, distant_light, local_light)
from visual.ui import display
from . import crayola as color
from . import materials
from . import site_settings
import atexit as _atexit
_atexit.register(waitclose)
scene = display()

Next I successfully ran some little programs such as this one:

import visual.basic as vb
vb.box(pos=(1.5,0,0), color=vb.color.orange, material=vb.materials.wood)
C = vb.curve(pos=[(0,0,0),(1,0,0),(1,1,0),(0,1,0)], color=vb.color.cyan)
print(C.pos)
vb.scene.mouse.getclick()
scene2 = vb.display(x=400)
vb.sphere()

I haven't done extensive testing, and I'm interested in suggestions
for improvement. The key point of course is that this doesn't import
all of math and numpy, but leaves "from visual import *" still
available.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

My strong preference and need is for the import by novices (not just
physics students, but other novices as well) to remain what it has
been, "from visual import *", and for the expert, clean import to be
more complex if necessary. However, I'm open to some other one-line
statement for novices if that is what's necessary to satisfy expert
needs. Someone needs to take this on as a project and make a specific
proposal to the community.

Bruce Sherwood

On Tue, Sep 14, 2010 at 6:52 PM, C Anthony Risinger <an...@ex...> wrote:
>>On Tue, Sep 14, 2010 at 6:30 PM, Bruce Sherwood <bas...@nc...> wrote:
>>> On Tue, Sep 14, 2010 at 3:27 PM, Guy K. Kloss <g....@ma...> wrote:
>>>
>>> Wouldn't this be a good point of time to clean up a little bit of the mess
>>> with the wild card imports and the polluted name spaces?
>>
>> Yes, that's a good idea. I myself am not currently up to doing this,
>> but if I recall correctly you had looked into this, yes? It should be
>> done in such a way that the novice can still get everything with "from
>> visual import *", but there should be an optional restrictive import
>> for experts.
>
> I know visual had it roots in assisting physics students, but it seems
> to have really grown beyond that; too strict adherence will deter
> others from furthering it's reach.  In my case, I came across visual
> while developing a real-time, distributed, generic data
> visualizer/analyzer, and the namespace thing was a huge... annoyance
> :-).
>
> Personally, I think the "visual" package should provide specific
> modules for the various things it supports, in a clean, pythonic
> manner.  An alternate "visualphysics" package could perform the
> wildcard imports from numpy and friends to create an environment
> targeted at simulations of physical systems.
>
> Visual to me is, and to others I introduce it as, a simple, intuitive,
> and _generic_ way to design and control 3D spaces from python; physics
> is only one use case.  I don't know how hard it would be to retain the
> current functionality _and_ clean up the namespace... which is why i
> suggest 2 packages, or something like:
>
> from visual.physics import *
>
> at the least, the base "visual" package should be the pythonic version.
>
> C Anthony
>

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[C A. R. <an...@ex...>]

>On Tue, Sep 14, 2010 at 6:30 PM, Bruce Sherwood <bas...@nc...> wrote:
>> On Tue, Sep 14, 2010 at 3:27 PM, Guy K. Kloss <g....@ma...> wrote:
>>
>> Wouldn't this be a good point of time to clean up a little bit of the mess
>> with the wild card imports and the polluted name spaces?
>
> Yes, that's a good idea. I myself am not currently up to doing this,
> but if I recall correctly you had looked into this, yes? It should be
> done in such a way that the novice can still get everything with "from
> visual import *", but there should be an optional restrictive import
> for experts.

I know visual had it roots in assisting physics students, but it seems
to have really grown beyond that; too strict adherence will deter
others from furthering it's reach.  In my case, I came across visual
while developing a real-time, distributed, generic data
visualizer/analyzer, and the namespace thing was a huge... annoyance
:-).

Personally, I think the "visual" package should provide specific
modules for the various things it supports, in a clean, pythonic
manner.  An alternate "visualphysics" package could perform the
wildcard imports from numpy and friends to create an environment
targeted at simulations of physical systems.

Visual to me is, and to others I introduce it as, a simple, intuitive,
and _generic_ way to design and control 3D spaces from python; physics
is only one use case.  I don't know how hard it would be to retain the
current functionality _and_ clean up the namespace... which is why i
suggest 2 packages, or something like:

from visual.physics import *

at the least, the base "visual" package should be the pythonic version.

C Anthony

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

Yes, that's a good idea. I myself am not currently up to doing this,
but if I recall correctly you had looked into this, yes? It should be
done in such a way that the novice can still get everything with "from
visual import *", but there should be an optional restrictive import
for experts.

Bruce Sherwood

On Tue, Sep 14, 2010 at 3:27 PM, Guy K. Kloss <g....@ma...> wrote:
> Wouldn't this be a good point of time to clean up a little bit of the mess
> with the wild card imports and the polluted name spaces?
>
> After all, coding for Py3k draws some changes in style after it anyway, so one
> cannot expect their code to work without changes anymore anyway. I guess this
> might be the ideal point in time to sanitise things in the code base that have
> been a bit of an issue in the past.
>
> Guy
>
>
> --
> Guy K. Kloss
> Institute of Information and Mathematical Sciences
> Te Kura Pūtaiao o Mōhiohio me Pāngarau
> Massey University, Albany (North Shore City, Auckland)
> 473 State Highway 17, Gate 1, Mailroom, Quad B Building
> voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
> G....@ma... http://www.massey.ac.nz/~gkloss
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Guy K. K. <g....@ma...>]

Wouldn't this be a good point of time to clean up a little bit of the mess 
with the wild card imports and the polluted name spaces?

After all, coding for Py3k draws some changes in style after it anyway, so one 
cannot expect their code to work without changes anymore anyway. I guess this 
might be the ideal point in time to sanitise things in the code base that have 
been a bit of an issue in the past.

Guy


-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

[Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

At http://vpython.org/contents/history.html (the "Recent developments"
section of vpython.org) you can download an experimental beta version
of VPython for Python 3.1 for Windows. The font modules included in
this VPython installer have been updated to work with Python 3.1, but
tested only to the extent that they work with VPython. It is quite
possible that additional work is needed to make them fully functional
with Python 3.1.

This beta version for Windows seems to work correctly, but it's
labeled "beta" because this represents a pretty big change. If you're
a bit adventurous I encourage you to use the new version and report
any problems to this forum.

I have not been able to produce a version for Python 3.1 for the Mac
because there isn't yet a Mac installer for numpy, and I have been
unsuccessful in trying to build numpy from source on the Mac. I also
have not succeeded in building VPython on Ubuntu.

The Python 2 series ended with Python 2.7. The Python 3 series cleans
up some accumulated infelicities in the Python language, at the cost
of some incompatibilities. The only significant incompatibility that
affects nearly all Python 2 program is a change to the print
statement:

Python 2: print "momentum =", m*v
Python 3: print("momentum =", m*v)

The old form, without the newly required parentheses, gives an error
in Python 3.x. The new form can be used with Python 2.x, but it
displays the parentheses, which may look a bit odd.

With Python 3.x, it is no longer necessary to use from __future__
import division in order to have 1/2 give 0.5 instead of 0. However,
it doesn't matter if the statement is left in the program; it's simply
ignored.

Bruce Sherwood

Re: [Visualpython-users] exporting CSV files

[Guy K. K. <g....@ma...>]

Or: Just use the CSV module in core Python

import csv

http://docs.python.org/library/csv.html#module-csv

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] exporting CSV files

[Alex E. <ale...@gm...>]

Paul,

Python has a lovely module for just this purpose. The documentation
most relevant to your question is probably here
[http://docs.python.org/library/csv.html#csv.writer].

Alex Edelman
Carnegie Mellon University
Physics, Class of 2012
ale...@gm...
ao...@cm...



On Mon, Sep 13, 2010 at 16:49, Paul D. Price <tv...@sb...> wrote:
> Friends,
>
> This is likely more of a Python question, but what is the best way to export data as a CSV file. For example, if I want to print coordinate data to a file, say ball.pos.x, and ball.pos,y, what is the sequence I would go through to open the file, write to it, and then close it?
>
> Thanks,
> Paul
> _______________________
> Paul D. Price
> Science Department Chairman
> Trinity Valley School
> Fort Worth, TX 76132
> tv...@sb...
>
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] exporting CSV files

[Steve S. <st...@sp...>]

Something like:

# before loop..

f = open('filename.dat','w')

#
# setup scene etc..
ball = sphere(....)

while True:
	ball.pos = blah blah...
	f.write("%f, %f, %f\n" % (ball.pos.x, ball.pos.y, ball.pos.z))

# after loop

f.close()

would that do it?
-steve


On Sep 13, 2010, at 4:49 PM, Paul D. Price wrote:

> Friends,
> 
> This is likely more of a Python question, but what is the best way to export data as a CSV file. For example, if I want to print coordinate data to a file, say ball.pos.x, and ball.pos,y, what is the sequence I would go through to open the file, write to it, and then close it?
> 
> Thanks,
> Paul
> _______________________
> Paul D. Price
> Science Department Chairman
> Trinity Valley School
> Fort Worth, TX 76132
> tv...@sb...
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] exporting CSV files

[Paul D. P. <tv...@sb...>]

Friends,

This is likely more of a Python question, but what is the best way to export data as a CSV file. For example, if I want to print coordinate data to a file, say ball.pos.x, and ball.pos,y, what is the sequence I would go through to open the file, write to it, and then close it?

Thanks,
Paul
_______________________
Paul D. Price
Science Department Chairman
Trinity Valley School
Fort Worth, TX 76132
tv...@sb...

[Visualpython-users] points instead of curve for trail

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

When VPython was new, the way to leave a trail behind a moving object
was with a curve object. But as noted in the documentation, "No matter
how many points are in a curve, only 1000 are displayed, selected
evenly over the full set of points, in order that the display of a
very long curve doesn't slow down unacceptably." This can lead to odd
displays when a trail has a very large number of points, since many
points get skipped, and you see straight lines connecting distant
points along the true trail position.

Note that a better choice for a trail may be a points object rather
than a curve object, as all the points will lie on the true trail.

Bruce Sherwood