visualpython-users

[Visualpython-users] ghistogram

[<Do...@ao...>]

I have been running into some problems with the ghistogram routine.  I have 
some data, which includes negative and positive values.  When I set the bins 
and xmin, xmax to allow for this, the distribution ends up piled up on the 
xmax side of the plot.  If I offset the data to be just positive, it works, 
but the plot is not as clear.  Did I miss something and this feature only 
allows for positive values?

Wayne Keen

[Visualpython-users] [Q] from VPython thread example

[Young-Jin L. <yl...@ui...>]

I have a question from VPython thread example.
Tk-Visual.py example has two threads, one for Tk even thread and the other
one for visual animation thread.
At first, the visual animation thread starts by setting its flag,
ProgClass.run, to "run". Then Tk event thread starts by "tkr.mainloop()".

What I cannot understand comes now. Right after starting the Tk event
thread, the run flag of ProgClass set to "stop".
I think it should result in stopping the visual thread, box_anim() method
because the condition of while loop couldn't be satisfied. Upon exiting the
visual thread, box_anim(), the run flag of ProgClass set to "stopped". I
thought the visual animation should stop now because the run flag is no
longer "run". But the visual thread kept going even though I couldn't find
any source where the run flag of ProgClass set back to "run".

Can anybody explain how this works?

Thanks in advance.

YJ

[Visualpython-users] graph legends

[Bruce S. <ba...@an...>]

I misinterpreted the question about legends on graphs. Here is an example 
(which incidentally also illustrates a feature, new in VPython for Python 
2.2, that permits multiline labels):

from visual.graph import *

gd = gdisplay(xmax=10, ymax=5)
legend = label(display=gd.display, pos=(5,4), text='This is a\nlegend')

The point is that a gdisplay has a "display" attribute (here, gd.display), 
so you can display any Visual object you like.

Bruce

Re: [Visualpython-users] [Q] Plotting module

[Bruce S. <ba...@an...>]

Yes. See the documentation on graphing. What you want are the xtitle and 
ytitle options on the gdisplay object.

Bruce Sherwood

--On Wednesday, January 09, 2002 15:50 -0600 Young-Jin Lee 
<yl...@ui...> wrote:

> I'd like to know if there a way to use legends in the plotting window.
> Thanks in advance.

[Visualpython-users] [Q] Plotting module

[Young-Jin L. <yl...@ui...>]

Hi,
I'd like to know if there a way to use legends in the plotting window.
Thanks in advance.

YJ

RE: [Visualpython-users] [Q] Need help on extending VPython

[David S. <dsc...@vi...>]

>     def clickOn( self ):
>         print self.name
...
>             print "1"
>             print b.clickOn()
>             print "2"

> When I ran this test script, I expected to get 
> "1\nBall 1\n2", but I got "1\nBall 1\nNone\n2". I have no 
> idea where "None" came from.

When you call b.clickOn(), that function prints its name ("Ball 1"), but
doesn't return anything.  The print statement below then prints "None"
which is what clickOn() returned.  Change clickOn to be

     def clickOn( self ):
         return self.name

and you will see what you expected.

> Is there anybody who can help me with this problem? Is this 
> the right way of extending VPython? Any comment on any of 
> above questions will be greatly appreciated.

The delegation approach you are using isn't a bad one for doing
complicated things, but it isn't necessary merely to give objects names.
VPython objects will accept any attributes you want, including name.
The following complete program works fine:

from visual import *
A = sphere(name = "Ball A")
print A.name

Dave

[Visualpython-users] [Q] Need help on extending VPython

[Young-Jin L. <yl...@ui...>]

Hi, I was looking for some help for the problem I got while I was trying to
extend VPython little bit.
I wanted to assign some properties on the VPython object. For instance, I
want to give a VPython sphere object a particular name. By assigning a
unique name on the VPython object, I will be able to do bookkeeping them
using a dictionary. Here is what I tried.

from visual import *

class Ball:
    def __init__( self, name, color ):
        self.sphere = sphere( color = color )
        self.name = name;

    def clickOn( self ):
        print self.name

scene.range = 4
components = {}
ball1 = Ball( "Ball 1", (0, 1, 0) )
components[ ball1.sphere ] = ball1

while 1:
    if scene.mouse.clicked:
        m = scene.mouse.getclick()

        #scene.mouse.pick.color = (0, 0, 1)
        global components
        b = components.get( scene.mouse.pick )
        if b:
            print "1"
            print b.clickOn()
            print "2"

        loc = m.pos
        #print loc
        sphere( pos = loc, radius = 0.1, color = (1,0,0) )

I created one sphere object and assigned the only property, the name, and
put it into the global dictionary. Then when I get a mouse click, I examined
the clicked object, checked the global dictionary, and if it is the case,
print out the name of it.
When I ran this test script, I expected to get "1\nBall 1\n2", but I got
"1\nBall 1\nNone\n2". I have no idea where "None" came from.

Is there anybody who can help me with this problem? Is this the right way of
extending VPython?
Any comment on any of above questions will be greatly appreciated.

TIA.

YJ

RE: [Visualpython-users] Speeding up a wave propagation simulation

[David S. <dsc...@vi...>]

> (Even looking back, I still don't see in the NumPy 
> documentation just why this works.  It looks to me from the 
> documentation that only "ufuncs" operate on arrays 
> element-by-element, not arbitrary user-defined functions.  
> Yet the actual behavior is exactly what I want in this case.)

Python will of course allow you to call a function with parameters of
any type, including arrays.  So the call

    pulse.gcurve.pos[:,1] = yt(x, t)

to the function

    def yt(x,t):
        ytotal = 0.0
        for k in arange(1.0, 4.0, 0.05):
            ytotal = ytotal + sin(k * x - w(k) * t)
        return ytotal

is just like writing

    ytotal = 0.0
    for k in arange(1.0, 4.0, 0.05):
        ytotal = ytotal + sin(k * x - w(k) * t)
    pulse.gcurve.pos[:,1] = ytotal

The only operations that operate on the array x in this code are
arithmetic operators and sin, which is a ufunc.  So it works fine.  If
yt() attempted to do something with x that isn't supported for arrays,
you would get a TypeError at that point.

Incidentally, if you wanted to eliminate the "for k" loop as well, you
can do it with more Numeric code:

def yt(x,t):
    k = arange(1.0, 4.0, 0.05)[:,NewAxis]
    return sum( sin(k * x - w(k) * t) )

and, of course, you could calculate k and w(k) just once.  But since
readability was one of your goals, I didn't recommend it.  (If you want
to use this code, you will have to change the first call yt(x,t) in the
plotting loop to yt(x,t)[0], since ytotal comes back a rank-1 array
instead of a scalar)

Dave

RE: [Visualpython-users] Speeding up a wave propagation simulation

[Andy D. <dou...@la...>]

On Mon, 7 Jan 2002, David Scherer wrote:

> This happens to be an easy one.
>=20
> Change the for loop in the na=EFve version from:
>=20
>     for n in range(npts):
>         x =3D pulse.gcurve.pos[n][0]
>         pulse.gcurve.pos[n][1] =3D yt(x, t)
>=20
> to:
>=20
>     x =3D pulse.gcurve.pos[:,0]
>     pulse.gcurve.pos[:,1] =3D yt(x, t)

Ah, wonderful.  Thanks, that indeed does it and was the sort of insight I
was looking for.

(Even looking back, I still don't see in the NumPy documentation just why
this works.  It looks to me from the documentation that only "ufuncs"
operate on arrays element-by-element, not arbitrary user-defined
functions.  Yet the actual behavior is exactly what I want in this case.)

Thanks again,

    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

RE: [Visualpython-users] Speeding up a wave propagation simulation

[David S. <dsc...@vi...>]

This happens to be an easy one.

Change the for loop in the na=EFve version from:

while 1:
    t =3D t + 0.5
    for n in range(npts):
        x =3D pulse.gcurve.pos[n][0]
        pulse.gcurve.pos[n][1] =3D yt(x, t)

to:

while 1:
    t =3D t + 0.5
    x =3D pulse.gcurve.pos[:,0]
    pulse.gcurve.pos[:,1] =3D yt(x, t)

and you're done!

Dave

> -----Original Message-----
> From: vis...@li...=20
> [mailto:vis...@li...] On=20
> Behalf Of Andy Dougherty
> Sent: Monday, January 07, 2002 4:13 PM
> To: Vis...@li...
> Subject: [Visualpython-users] Speeding up a wave propagation=20
> simulation
>=20
>=20
> I've been considering using Vpython in a course to illustrate=20
> the propagation of wave packets with dispersion.  The problem=20
> is it's just too slow.  I'm hoping someone on this list with=20
> experience with the Numeric module might be able to help me=20
> speed it up.  I think I'm spending way too much time=20
> explicitly looping over arrays.
>=20
> Sorry for the length of what follows, but it might be helpful to be
> specific:
>=20
> Here's my original naive attempt:
>=20
>     #!/usr/bin/python
>     # Show propagation of a wave pulse with dispersion.
>     from visual.graph import *
>=20
>     def w(k):
> 	"Dispersion relation w(k), gives v ~ 1/sqrt(k)."
> 	return sqrt(k)
>=20
>     def yt(x,t):
> 	"Total wave obtained by superimposing sinusoids with k=20
> from 1 to 4."
> 	ytotal =3D 0.0
> 	for k in arange(1.0, 4.0, 0.05):
> 	    ytotal =3D ytotal + sin(k * x - w(k) * t)
> 	return ytotal
>=20
>     gdisplay(xtitle=3D'x', ytitle=3D'ytotal', title=3D'Wave',
> 	    xmin =3D -10.0, ymin =3D -60.0, xmax =3D100.0, ymax =3D 60.0)
>     pulse =3D gcurve()
>=20
>     t =3D 0.0
>     # Make initial plot
>     for x in arange(-10.0, 100.0, 0.2):
> 	pulse.plot(pos=3D(x, yt(x,t)))
>     npts =3D len(pulse.gcurve.pos)
>    =20
>     while 1:
> 	t =3D t + 0.5
> 	for n in range(npts):
> 	    x =3D pulse.gcurve.pos[n][0]
> 	    pulse.gcurve.pos[n][1] =3D yt(x, t)
>=20
> This would be rather simple for my students to follow (I=20
> hope!), but it is painfully slow.  I was able to speed it up=20
> considerably by doing some obvious things:
>     1.  Precomputing the dispersion relationship w(k) once=20
> and storing it
>     2.  storing each set of points in a temporary array and=20
> updating the=20
>     display only once per time step (instead of every x value)
>     3.  Calling math.sin() directly instead of the overloaded=20
> Numeric sin() but it's still too slow.  (Obviously, I can=20
> reduce the spatial and temporal resolution, but that's beside=20
> the point here.)
>=20
> To be specific, here's what I ended up with.
>=20
>     #!/usr/bin/python
>     # Show propagation of a wave pulse with dispersion.
>     from visual.graph import *
>=20
>     def w(k):
> 	"Dispersion relation w(k), gives v ~ 1/sqrt(k)."
> 	return sqrt(k)
>=20
>     # Range of wavenumbers 'k' to include.
>     ka =3D arange(1.0, 4.0, 0.05)
>     wk =3D w(ka)
>     nkmax =3D len(ka)
>     def yt(x,t):
> 	"Total wave obtained by superimposing sinusoids with k=20
> from 1 to 4."
> 	ytotal =3D 0.0
> 	for nk in range(nkmax):
> 	    ytotal =3D ytotal + math.sin(ka[nk] * x - wk[nk] * t)
> 	return ytotal
>=20
>     gdisplay(xtitle=3D'x', ytitle=3D'ytotal', title=3D'Wave',
> 	    xmin =3D -10.0, ymin =3D -60.0, xmax =3D100.0, ymax =3D 60.0)
>     pulse =3D gcurve()
>=20
>     t =3D 0.0
>     for x in arange(-10.0, 100.0, 0.2):
> 	pulse.plot(pos=3D(x, yt(x,t)))
>=20
>     # Make a temporary copy -- see below
>     temp =3D array(pulse.gcurve.pos)
>     npts =3D len(pulse.gcurve.pos)
>=20
>     while 1:
> 	t =3D t + 0.5
> 	# Compute the new values in a temp array that isn't=20
> displayed, then
> 	# copy to the pulse.gcurve.pos array to update the=20
> display all at once.
> 	for n in arange(npts):
> 	    temp[n][1] =3D yt(temp[n][0], t)
> 	pulse.gcurve.pos =3D temp
>=20
> Does anyone have any suggestions for how to significantly=20
> speed this up? All the looping over arrays seems to me to be=20
> the sort of thing that I ought to be able to get the Numeric=20
> extension to do for me efficiently, but I confess I'm new to=20
> it and haven't seen how to do it yet.
>=20
> Thanks for any advice,
>=20
>     Andrew Dougherty		dou...@la...
>     Dept. of Physics
>     Lafayette College, Easton PA 18042
>=20
>=20
> _______________________________________________
> Visualpython-users mailing list=20
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>=20

[Visualpython-users] Speeding up a wave propagation simulation

[Andy D. <dou...@la...>]

I've been considering using Vpython in a course to illustrate the
propagation of wave packets with dispersion.  The problem is it's just too
slow.  I'm hoping someone on this list with experience with the Numeric
module might be able to help me speed it up.  I think I'm spending way
too much time explicitly looping over arrays.

Sorry for the length of what follows, but it might be helpful to be
specific:

Here's my original naive attempt:

    #!/usr/bin/python
    # Show propagation of a wave pulse with dispersion.
    from visual.graph import *

    def w(k):
	"Dispersion relation w(k), gives v ~ 1/sqrt(k)."
	return sqrt(k)

    def yt(x,t):
	"Total wave obtained by superimposing sinusoids with k from 1 to 4."
	ytotal = 0.0
	for k in arange(1.0, 4.0, 0.05):
	    ytotal = ytotal + sin(k * x - w(k) * t)
	return ytotal

    gdisplay(xtitle='x', ytitle='ytotal', title='Wave',
	    xmin = -10.0, ymin = -60.0, xmax =100.0, ymax = 60.0)
    pulse = gcurve()

    t = 0.0
    # Make initial plot
    for x in arange(-10.0, 100.0, 0.2):
	pulse.plot(pos=(x, yt(x,t)))
    npts = len(pulse.gcurve.pos)
    
    while 1:
	t = t + 0.5
	for n in range(npts):
	    x = pulse.gcurve.pos[n][0]
	    pulse.gcurve.pos[n][1] = yt(x, t)

This would be rather simple for my students to follow (I hope!), but it
is painfully slow.  I was able to speed it up considerably by doing
some obvious things:
    1.  Precomputing the dispersion relationship w(k) once and storing it
    2.  storing each set of points in a temporary array and updating the 
    display only once per time step (instead of every x value)
    3.  Calling math.sin() directly instead of the overloaded Numeric sin()
but it's still too slow.  (Obviously, I can reduce the spatial and
temporal resolution, but that's beside the point here.)

To be specific, here's what I ended up with.

    #!/usr/bin/python
    # Show propagation of a wave pulse with dispersion.
    from visual.graph import *

    def w(k):
	"Dispersion relation w(k), gives v ~ 1/sqrt(k)."
	return sqrt(k)

    # Range of wavenumbers 'k' to include.
    ka = arange(1.0, 4.0, 0.05)
    wk = w(ka)
    nkmax = len(ka)
    def yt(x,t):
	"Total wave obtained by superimposing sinusoids with k from 1 to 4."
	ytotal = 0.0
	for nk in range(nkmax):
	    ytotal = ytotal + math.sin(ka[nk] * x - wk[nk] * t)
	return ytotal

    gdisplay(xtitle='x', ytitle='ytotal', title='Wave',
	    xmin = -10.0, ymin = -60.0, xmax =100.0, ymax = 60.0)
    pulse = gcurve()

    t = 0.0
    for x in arange(-10.0, 100.0, 0.2):
	pulse.plot(pos=(x, yt(x,t)))

    # Make a temporary copy -- see below
    temp = array(pulse.gcurve.pos)
    npts = len(pulse.gcurve.pos)

    while 1:
	t = t + 0.5
	# Compute the new values in a temp array that isn't displayed, then
	# copy to the pulse.gcurve.pos array to update the display all at once.
	for n in arange(npts):
	    temp[n][1] = yt(temp[n][0], t)
	pulse.gcurve.pos = temp

Does anyone have any suggestions for how to significantly speed this up?
All the looping over arrays seems to me to be the sort of thing that I
ought to be able to get the Numeric extension to do for me efficiently,
but I confess I'm new to it and haven't seen how to do it yet.

Thanks for any advice,

    Andrew Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

Re: [Visualpython-users] VPython -- compiling latest version (fwd)

[dman <ds...@ri...>]

On Mon, Jan 07, 2002 at 10:47:43AM -0500, David Andersen wrote:
| I've removed getMousePixelDelta and updated the CVS tree.

Ok, I'll update that.

| Could you be missing the files in the "visual" directory?

I have the 'visual' directory, but I thought the easiest way to see if
I compiled the module correctly would be to import it directly.

Apparently not.  I updated my cvs tree, removed the getMousePixelDelta
prototype, recompiled from scratch, and (with proper PYTHONPATH)
imported 'visual'.  It complained that there was no init function
"initcvisual".  That is quite interesting to me (previously it wanted
"initcvisualmodule", time for me to RTFM on python's C API).  I
renamed that function (undid my earlier change) and it works now.

Thanks for your time!

-D

-- 

A man of many companions may come to ruin,
but there is a friend that sticks closer than a brother.
        Proverbs 18:24

Re: [Visualpython-users] VPython -- compiling latest version (fwd)

[David A. <dm...@an...>]

I've removed getMousePixelDelta and updated the CVS tree.

Could you be missing the files in the "visual" directory?

[Visualpython-users] label.text = None?

[Bruce S. <ba...@an...>]

This prints and displays 'hello':

	lab = label()
	s = 'hello'
	print s
	lab.text = s

This on the other hand prints 'None' but gives an error on the last line:

	lab = label()
	s = None
	print s
	lab.text = s

I propose changing the label machinery so that in this case you would see 
'None' rather than getting an error. What do you think?

One of the places where this comes up is in displaying the state of the 
mouse buttons, where mouse.button is None if no buttons are pressed.

Bruce Sherwood

[Visualpython-users] VPython -- compiling latest version (fwd)

[Bruce S. <ba...@an...>]

Can someone knowledgeable with Debian Linux respond to this question? 
Please cc the person, since I don't know whether this user has subscribed 
to the VPython user list. Thanks.

Bruce Sherwood

---------- Forwarded Message ----------
Date: Saturday, January 05, 2002 21:09 -0500
From: dman <ds...@ri...>
To: bru...@cm...
Subject: VPython -- compiling latest version

>
> I downloaded the VPython cvs sources and am trying to compile
> cvisualmodule.so but am having some problems.  I managed to correct
> one problem (missing prototype for xglContext::getMousePixelDelta).
> The next problem I had was when I tried to import the module (using
> python2.2 at this point).  I was told there was no init function in
> the module.  I renamed "initcvisual" (at the bottom of cvisual.cpp) to
> "initcvisualmodule" and that error message went away.  (is this the
> right fix?)  Now I'm getting
>
> Traceback (most recent call last):
>   File "<string>", line 1, in ?
> SystemError: _PyImport_FixupExtension: module cvisualmodule not loaded
>
> The documentation on the C API only says that that function is for
> internal use.
>
> I tried recompiling it with the python 2.1 headers instead, but I get
> an API version mismatch warning, then the same stack trace above.
>
> What might I be doing wrong?
>
> (btw, I'm using Debian on an x86 system)
>
> -D
>
> --
>
> Trust in the Lord with all your heart and lean not on your own
> understanding; in all your ways acknowledge Him, and He will make your
> paths straight.
>         Proverbs 3:5-6
>

---------- End Forwarded Message ----------

[Visualpython-users] VPython for Linux Python 2.2

[David A. <dm...@an...>]

I've ported cvisual to Python 2.2 on Linux: unfortunately, the mouse 
doesn't work at all.

Looking into this.

Re: [Visualpython-users] [Q] Fatal error with new zoom function

[Bruce S. <ba...@an...>]

I have no idea what could cause zooming to crash on one kind of Windows 
machine. Here is a little program to run on Windows and report whether its 
output makes sense. Note that zoom and spin are disabled in order to see 
all possible mouse events.

from visual import *
scene.userzoom = 0
scene.userspin = 0
box()
lab = label()
while 1:
    m = scene.mouse
    if m.button:
        lab.text = m.button
    else:
        lab.text = 'None'
    if scene.mouse.events:
        m = scene.mouse.getevent()
        if m.press: print 'press', m.press
        if m.release: print 'release', m.release
        if m.click: print 'click', m.click
        if m.drag: print 'drag', m.drag
        if m.drop: print 'drop', m.drop
        if m.shift: print 'shift'
        if m.alt: print 'alt'
        if m.ctrl: print 'ctrl'
        print '--------------'

[Visualpython-users] [Q] Fatal error with new zoom function

[Young-Jin L. <yl...@ui...>]

I'm experiencing a fatal error with the new zoom function.
I tested the new zoom function on my IBM ThinkPad T22 (Windows2000
professional, 128 MB memory).
Every time I tried to zoom in/out, I got "blue screen of death". I tried to
read the screen dump, but I couldn't because it was too fast. I tested it
both with a external mouse and with a IBM PS/2 TrackPoint.
New zoom function seems to be working fine with my desktop (Windows2000 pro
Dell machine).

Is this a known problem? Is there any way to solve it?
Thanks in advance.

Young-Jin Lee

[Visualpython-users] Another fix

[Bruce S. <ba...@an...>]

Another fix (2001-12-31) to the Windows version for Python 2.2 is posted at 
vpython.org. Occasionally a mouse click would identify the wrong "picked" 
object.

Again, if you have previously installed VPython for Python 2.2 on Windows, 
you only need the DLL to get the fix.

Bruce Sherwood

[Visualpython-users] Correction

[Bruce S. <ba...@an...>]

At vpython.org is a new version for Windows which fixes a problem with 
losing "press" and "click" mouse events. If you have already installed 
VPython for Python 2.2 on Windows, you need only download the DLL file and 
unzip it into the Python directory.

Bruce Sherwood

Re: [Visualpython-users] New Windows VPython

[Arthur S. <aj...@ix...>]

>  Bruce writes - 
 
> I will attempt to say nothing more about any of this.

Which I guess gives me the last word.

No I don't have any *proof* that the issue in the classroom
is not as you analyze.  It does seem that you somehow *knew* 
it was going to be *the* issue, and that the classroom experience
you report is only confirming your own foresight.

I was a Python and programming  beginner not very 
long ago, so *I* know  perhaps better than
you what were the significant issues and what
were the minor issues in getting up to speed.

Do you have a basis to tell me that my own real lived 
experience was not lived, not accurately reported,
or that besides being the crankiest of bastards, I 
am somehow outside the norm.

You refuse to address, among other things, the fact that VPython
is distributed with Numeric, and that you *cannot* expect your
students to use it without disaster if they are not introduced
to its typing and numerical coercian rules -  a discussion in
which the old div operator behavior is given context. From there
on - one would think - its their *job* to keep it straight, and 
simply a few of the many of the things I expect you would 
expect them to keep straight in the course of a course.

For the record:

From my perspective the issue here is not the div operator 
change, and , never has been.  It is about science, about evidence 
and the reporting of evidence, and  about common sense.

Art

Re: [Visualpython-users] New Windows VPython

[Bruce S. <ba...@an...>]

I'm not sure how to say it any more plainly than I've already said it, but 
I'll try once more.

NOTHING has changed in VPython that forces you to use the new division 
operators!

What has changed is that you MAY if you wish use the new division 
operators, even if you use Numeric arrays. The problem was that Numeric 
didn't recognize and process the new "true division" and "floor division" 
operators present in Python 2.2. There is no "fork" of Numeric. I've 
submitted the additions for inclusion in the next release of Numeric and 
been thanked for doing the work and told that many people were asking for 
this.

But if you don't want to use the new division operators, DON'T put "from 
__future__ import division" in your programs! Including when you're using 
VPython!

As to the student issue: There is no theorizing nor condescension in this. 
The actual data are that very smart college freshmen with very high SAT's 
etc., but who often have never written a computer program before, 
frequently make the "mistake" of writing such things as 1/2 thinking that 
this means the same as 0.5, because that's what it means in all other 
environments, including their pocket calculator. And they and their 
instructors find it difficult to track down why the program fails, because 
the difference between 1/2 and 1./2 is awfully subtle and hard to pick up 
in proofreading. I have a Ph.D. in physics,  done a lot of system software 
work including creating a respectable programming language (cT), and I make 
this "mistake" too when doing scientific programming. I repeat that this is 
about the only significant problem our students have had with Python. Can 
you present data that our students don't have a serious problem with this 
issue? Remember too that this is in the context of a physics class, not a 
computer science class, and we can't afford to spend time on teaching picky 
details of syntax.

Until now there was nothing we could do about this. We did not want to do 
what the Alice project did, which was hack Python to fix the problem, 
because this would be a "fork" and make our Python different from the world 
Python. Now with Python 2.2 we can teach our students to insert "from 
__future__ import division". And we can try to teach students that when a 
program fails, they should check to make sure that they've inserted this 
line.

It is at least a reasonable question whether to drive Python or VPython 
with the "-Qnew" command-line option which has the same effect as the 
import statement. On balance, we think we shouldn't make this the default 
run mode in our local classroom VPython environment, because our students 
may well run Python and/or VPython in environments other than our classroom.

I will attempt to say nothing more about any of this.

Bruce Sherwood

--On Monday, December 24, 2001 21:14 -0500 Arthur Siegel 
<aj...@ix...> wrote:

>> You've jumped the gun, but your input is useful nevertheless.
>
> I'm not sure how.  I am reading your message to say that the copy
> of Numeric that is downloaded with VPython has been patched.
> And since I am directing users of PyGeo to VPython, I am directing
> them to a forked version of Numeric. Which is somehow horrid to me.
>
> What am I missing.
>
> As to the rest -  I should probably keep my peace.
>
> I've pissed off enough people and caused myself enough
> grief in the course of it.
>
> But is all quite, quite incredible to me.
>
> I think the importance you attach to this issue is monumentally
> overstated, and overwhelmingly condescending.
>
> Now you are further saying that your students can't even be
> trusted to be able to handle the from __future__ statement
> all my their little bitty selves.
>
> Suffice it to say that am I sure the hell glad I'm not in
> school anymore.
>
> Art

Re: [Visualpython-users] New Windows VPython

[Arthur S. <aj...@ix...>]

> You've jumped the gun, but your input is useful nevertheless.

I'm not sure how.  I am reading your message to say that the copy 
of Numeric that is downloaded with VPython has been patched. 
And since I am directing users of PyGeo to VPython, I am directing 
them to a forked version of Numeric. Which is somehow horrid to me. 

What am I missing.

As to the rest -  I should probably keep my peace.  

I've pissed off enough people and caused myself enough
grief in the course of it.  

But is all quite, quite incredible to me.

I think the importance you attach to this issue is monumentally
overstated, and overwhelmingly condescending.

Now you are further saying that your students can't even be 
trusted to be able to handle the from __future__ statement 
all my their little bitty selves.

Suffice it to say that am I sure the hell glad I'm not in 
school anymore.

Art

Re: [Visualpython-users] New Windows VPython

[Bruce S. <ba...@an...>]

You've jumped the gun, but your input is useful nevertheless.

The new Windows version of VPyhon available at vpython.org does NOT 
automatically invoke the new division operators. What it does is PERMIT but 
not require users of VPython to put "from __future__ import division" in 
their programs and have things work correctly, even if they use explicit 
Numeric arrays (as for example is the case in some VPython demo programs). 
So there still is no "VPython fork".

It is true however that I have been thinking quite seriously of making just 
such a version of VPython, possibly only a local version just for our 
physics students. In the absence of "true division" they make "mistakes" 
that are very hard to find and fix. If we do make such a version, we'll 
offer it to others along with a version that doesn't invoke this 
automatically. Alternatively, we'll just teach our students to insert the 
import __future__ statement to avoid the problems they have been 
encountering. This problem stands out in high relief for us because it is 
very nearly the only significant problem they have with Python. (For 
example, our students don't have any problems whatsoever with case 
sensitivity, the other problem that was reported for some novice programmer 
populations.)

I hope this clarifies for you the VPython situation. What I fixed makes it 
possible to use true division with Numeric, not force you to do so.

This said, I should also however point out that while the serious 
difficulties students had with classic division in both the Alice and 
VPython projects got Guido and others thinking about the issue, it is my 
understanding that these projects were NOT ultimately the basis for 
implementing a path toward a different approach to division. Rather, Guido 
and colleagues came to a new vision of the status of numeric values in 
Python, and a way to unify different kinds of integer in such a way that it 
shouldn't matter whether a quantity happens to be an integer or a float.

Bruce Sherwood

--On Monday, December 24, 2001 18:17 -0500 Arthur Siegel 
<aj...@ix...> wrote:

> ----- Original Message -----
> From: "Bruce Sherwood" <ba...@an...>
> To: <vis...@li...>
> Sent: Monday, December 24, 2001 5:11 PM
> Subject: [Visualpython-users] New Windows VPython
>
>
>> At vpython.org is a new VPython for Windows that patches gaps in the
>> Numeric module used in some VPython demo programs (and automatically
>> imported by Visual). The update makes division of Numeric arrays work
>> properly in the presence of "from __future__ import division". The
>> patches to Numeric have been submitted to the keepers of the Numeric
>> project.
>>
>> Bruce Sherwood
>>
>
>
> Bruce -
>
> I am in the strange position of being a vocal advocate of
> VPython, and a vocal critic of the decision on the division
> operator, at least to the extent it was made to accommodate
> VPython and similar projects.  And precisely, as I stated at
> the time of the wars,  because Numeric is the dog and VPython
> the tail when it comes to handling numerics, and as I stated at
> the time, the change is inconsistent, or at least inelegantly consistent,
> with Numeric typing, and, as I stated at the time of the wars, the
> change could be expected to lead to a deeper level of confusion
> and more insidious bugs if folks try to use VPython without being
> aware of the Numeric typing and coercian rules - to which the
> divison change is, almost by intent, an open invitation.
>
> And I inflamed an already difficult relationship with Guido and others
> in the community as a result of my position, or at least its vehemence,
> and my method of communciating my position.
>
> There was no VPython fork of Python as Guido had apparently thought,
> but as of today, apparently there *is* a VPython fork of Numeric.
>
> That a project of mine, that is dear to me, is dependent on VPython and
>  so -
> at least temporarily, a fork of Numeric, is - I think you might be able
> to understand - quite upsetting.
>
> Art
>
>
>
>
>
>

Re: [Visualpython-users] New Windows VPython

[Arthur S. <aj...@ix...>]

----- Original Message -----
From: "Bruce Sherwood" <ba...@an...>
To: <vis...@li...>
Sent: Monday, December 24, 2001 5:11 PM
Subject: [Visualpython-users] New Windows VPython


> At vpython.org is a new VPython for Windows that patches gaps in the
> Numeric module used in some VPython demo programs (and automatically
> imported by Visual). The update makes division of Numeric arrays work
> properly in the presence of "from __future__ import division". The patches
> to Numeric have been submitted to the keepers of the Numeric project.
>
> Bruce Sherwood
>


Bruce -

I am in the strange position of being a vocal advocate of
VPython, and a vocal critic of the decision on the division
operator, at least to the extent it was made to accommodate
VPython and similar projects.  And precisely, as I stated at
the time of the wars,  because Numeric is the dog and VPython
the tail when it comes to handling numerics, and as I stated at
the time, the change is inconsistent, or at least inelegantly consistent,
with Numeric typing, and, as I stated at the time of the wars, the
change could be expected to lead to a deeper level of confusion
and more insidious bugs if folks try to use VPython without being
aware of the Numeric typing and coercian rules - to which the
divison change is, almost by intent, an open invitation.

And I inflamed an already difficult relationship with Guido and others
in the community as a result of my position, or at least its vehemence,
and my method of communciating my position.

There was no VPython fork of Python as Guido had apparently thought,
but as of today, apparently there *is* a VPython fork of Numeric.

That a project of mine, that is dear to me, is dependent on VPython and
 so -
at least temporarily, a fork of Numeric, is - I think you might be able
to understand - quite upsetting.

Art