visualpython-users

[Visualpython-users] New Windows VPython

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

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

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

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...>]

> 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...>]

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...>]

>  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