visualpython-users

[Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

On Wed, Jun 6, 2012 at 6:40 PM, Bruce Sherwood <Bru...@nc...> wrote:
>
> [...] JavaScript is slower than C++ but
> considerably faster than Python. To my knowledge, there is no
> possibility for something like numpy, which runs at the speed of C.

once numpy and co can run on pypy, will visual?  pypy.org has been
raising money for the numpy port ... ~45k of 60k.

> Another speed issue to consider is that because GlowScript uses WebGL,
> which requires the use of modern GPU-type graphics cards, many kinds
> of graphics can be significantly faster than in VPython, which
> currently uses GPUs only optionally, for textures. I've been dreaming
> of a VPython+ that would also require the use of a modern graphics
> card.

so, as someone who as lurked this list for probably 4+ years now, this
is something i've been wondering since the inception of glowscript and
all the chatter/activity around it compared to vpython ...

how does glowscript and vpython fit together in the "big picture"?
has interest in the python module diminished (none? some? all?) in
favor of JS?

this is not really a criticism, whatever you answer; i'm mostly
curious because i'm doing a short presentation next week on vpython to
my company (~40-60 other developers, JS/Python/.NET/C#), and i'm
writing up a demo program (visualization of message queue data! yay!)
and supporting materials this weekend.  i haven't actually ran
glowscript successfully on my archlinux machines, in any browser, but
i planned on giving it an honorable mention as i know several JS
developers will be interested.  primarily, i just want to give a good
representation of what visual is, and what is to come.

i know it's a pretty open ended question, but it's been on my mind for
awhile.  i wrote JS for many years before learning (and instantly
embracing) python; it goes without saying that IMO ...

Python > JS**10

... alas, i'm almost assuredly biased, as i work on projects like
pyjs.org translating Python-to-JS (for the goodness of all ;-) ... i
was even considering implementing a pyjs wrapper to glowscript,
"theoretically" allowing vpython programs to run unmodified in the
browser.  all-in-all, JS/ECMAscript, as implemented in browsers at
least, is a wonderfully powerful language but offers no supporting
infrastructure whatsoever. with the advent of pypy, any performance
gaps are probably not so large (unconfirmed), should they exist at all
(absolutely unfounded).

what say you!?!? :-) again, while i prefer and champion the python
side of things, i completely understand the
benefit/opportunity/convenience of glowscript -- both are super-cool
and vpython is loads of fun.

thanks,

-- 

C Anthony

aside: at pyjs.org we've tried to bring python to the web via
translation, but also direct bindings to the layout engine
(Trident/XULRunner/WebKit), some of which are very successful.  we are
looking for a more universal way to achieve direct bindings, say via a
plugin toolkit like Firebreath, or similar.  perhaps you can better
merge the two projects by doing the same -- use a browser to render
vpython.  if you drive the browser's WebGL engine directly you can get
all the benefits (hardware accel/etc) in vpython for free.  the
Trident engine (Windows) is the most stable for us, accessed via COM
interface, and the GObject WebKit bindings are the next promising
method for other platforms.  there are also mature ObjC bindings to
WebKit.  not sure how/if WebGL is exposed currently, but it might be
worth pursuing.

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

Very interesting. There is much in your message about which I have no
knowledge and no opinion. However, I can make some comments about the
Big Picture.

For a variety of reasons, I am personally committed to the further
development and maintenance of both VPython and GlowScript.

One of the reasons is more political than technical. With Ruth Chabay
I am the co-author of a textbook and curriculum for intro physics
(matterandinteractions.org) which includes an introduction to
computational modeling, in which students write VPython programs to
model physical systems. This reflects the fact that physics today
isn't just theory and experiment, it's theory and experiment and
computational modeling, but this important change has not been
reflected in physics education, one of the serious problems we are
addressing. Other problems include the fact that the intro physics
course taken by engineering and science students in college stops
around 1860, whereas we take a 20th-century perspective and even admit
that atoms exist.

There are a thousand excuses available to physics faculty for why one
shouldn't bring the intro physics course up to date. One of them is
that the physicist could probably find a card-carrying computer
scientist ready to testify that computer language X rots the brain.
Python however is in good esteem in the CS community, so it would be
difficult to find a computer scientist ready to testify that it's
terrible to use Python in the intro physics course.

Another issue is that (as you point out) there is little
infrastructure at present for the support of computation.in
JavaScript. This may change, but certainly Python has a far richer
computational ecology. VPython is attractive to scientists for
visualization purposes, and many scientists know and use Python. Few
scientists today know or use JavaScript.

I agree that Python as a language is far more attractive than
JavaScript. However, CoffeeScript (which is also supported in
GlowScript) has the good features of Python but compiles instantly to
JavaScript. In particular, CoffeeScript uses white space, thereby
eliminating lots of cluttering of braces. Moreover, CoffeeScript makes
it impossible to do the Bad Things that people regret about
JavaScript.

Recently I've been writing GlowScript examples in CoffeeScript, and I
like it for the same reasons that I like Python. If you go to
glowscript.org and click on "Example programs", you'll find some pairs
of examples, one in JavaScript and one in GlowScript; also the Rug
example is in CoffeeScript. Incidentally, I have no problem running
GlowScript in Ubuntu, using the proprietary NVIDIA driver.

As I've said, I'm dreaming of constructing a VPython+ that would
require a modern graphics card. If possible, I'd like to build it on
top of one of the newer Python frameworks that work cross-platform, in
particular to solve the menacing problem that Carbon on the Mac is not
available for 64-bit Python. I'm not able to tackle this immediately
because I have some major responsibilities to work on a fourth edition
of our physics textbook. I should mention that recently someone tried
to build VPython on a pure Python framework but, as I expected, it ran
about 50 times slower than VPython, so one has to choose the framework
carefully.

A very important simplification is possible. In GlowScript if you
write an infinite loop you MUST include a rate or similar statement to
allow the screen to be updated, as there is no interrupt possbility in
JavaScript. Most VPython animations include a rate statement, so I
judge it wouldn't be terrible to require one, thereby eliminating the
rather complex threading that is currently at the heart of VPython,
and which is the reason that David Scherer and I were unable to
implement VPython in Cocoa on the Mac.

On the first page of the Help at glowscript.org you'll find some
comments addressed at those familiar with VPython, including
side-by-side comparisons of Python and JavaScript elements. There is
even a VPython -> GlowScript converter I wrote in Python which does
much of the grunt work but still requires some manual conversion of
the resulting JS code. This converter is much less sophisticated than
pyjs, as my goal was just to assist, not do the enormous amount of
work required to do the full job.

I wasn't aware of the pypy.org project, and certainly running 5 times
faster than CPython is important. What is "co", which you mention?

Bruce Sherwood

On Fri, Jun 8, 2012 at 10:50 PM, C Anthony Risinger <an...@xt...> wrote:
> On Wed, Jun 6, 2012 at 6:40 PM, Bruce Sherwood <Bru...@nc...> wrote:
>>
>> [...] JavaScript is slower than C++ but
>> considerably faster than Python. To my knowledge, there is no
>> possibility for something like numpy, which runs at the speed of C.
>
> once numpy and co can run on pypy, will visual?  pypy.org has been
> raising money for the numpy port ... ~45k of 60k.
>
>> Another speed issue to consider is that because GlowScript uses WebGL,
>> which requires the use of modern GPU-type graphics cards, many kinds
>> of graphics can be significantly faster than in VPython, which
>> currently uses GPUs only optionally, for textures. I've been dreaming
>> of a VPython+ that would also require the use of a modern graphics
>> card.
>
> so, as someone who as lurked this list for probably 4+ years now, this
> is something i've been wondering since the inception of glowscript and
> all the chatter/activity around it compared to vpython ...
>
> how does glowscript and vpython fit together in the "big picture"?
> has interest in the python module diminished (none? some? all?) in
> favor of JS?
>
> this is not really a criticism, whatever you answer; i'm mostly
> curious because i'm doing a short presentation next week on vpython to
> my company (~40-60 other developers, JS/Python/.NET/C#), and i'm
> writing up a demo program (visualization of message queue data! yay!)
> and supporting materials this weekend.  i haven't actually ran
> glowscript successfully on my archlinux machines, in any browser, but
> i planned on giving it an honorable mention as i know several JS
> developers will be interested.  primarily, i just want to give a good
> representation of what visual is, and what is to come.
>
> i know it's a pretty open ended question, but it's been on my mind for
> awhile.  i wrote JS for many years before learning (and instantly
> embracing) python; it goes without saying that IMO ...
>
> Python > JS**10
>
> ... alas, i'm almost assuredly biased, as i work on projects like
> pyjs.org translating Python-to-JS (for the goodness of all ;-) ... i
> was even considering implementing a pyjs wrapper to glowscript,
> "theoretically" allowing vpython programs to run unmodified in the
> browser.  all-in-all, JS/ECMAscript, as implemented in browsers at
> least, is a wonderfully powerful language but offers no supporting
> infrastructure whatsoever. with the advent of pypy, any performance
> gaps are probably not so large (unconfirmed), should they exist at all
> (absolutely unfounded).
>
> what say you!?!? :-) again, while i prefer and champion the python
> side of things, i completely understand the
> benefit/opportunity/convenience of glowscript -- both are super-cool
> and vpython is loads of fun.
>
> thanks,
>
> --
>
> C Anthony
>
> aside: at pyjs.org we've tried to bring python to the web via
> translation, but also direct bindings to the layout engine
> (Trident/XULRunner/WebKit), some of which are very successful.  we are
> looking for a more universal way to achieve direct bindings, say via a
> plugin toolkit like Firebreath, or similar.  perhaps you can better
> merge the two projects by doing the same -- use a browser to render
> vpython.  if you drive the browser's WebGL engine directly you can get
> all the benefits (hardware accel/etc) in vpython for free.  the
> Trident engine (Windows) is the most stable for us, accessed via COM
> interface, and the GObject WebKit bindings are the next promising
> method for other platforms.  there are also mature ObjC bindings to
> WebKit.  not sure how/if WebGL is exposed currently, but it might be
> worth pursuing.

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

[Kevin K. <ka...@so...>]

I'm glad to see that Vpython has a future, and that you do have plans
to make it work on 64-bit Macs.

I would find requiring "rate" statements a bit annoying, but
tolerable.  I wonder whether it would become a major problem for new
programmers, though, as its necessity is not obvious.

One thing I would like to see is a good integration of units into the
computation.  I tell my students to keep units with their intermediate
results, and I suspect that most real physics teachers do also, so it
is a bit annoying that Vpython encourages (sometimes even requires)
unitless numbers.  I've been using the Unum package, which works
fairly well but is rather slow (I also had to add a sqrt function for
it).  

See the simulation (without animation---just using visual for optional
graphs) in 
http://gasstationwithoutpumps.wordpress.com/2012/06/04/soda-bottle-rocket-simulation-take-2
for an example of using Unum 

The visual package does not play nicely with Unum, since all the
animation and graphing has to be unitless.  I think that a little more
care in "duck typing" could have made the routines work just fine with
numbers that have units.

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

Actually, in my experience with students using VPython in intro
physics, rate statements usually are necessary even for new
programmers, because VPython is so fast that simple animations
typically run too fast to be seen.

At least in intro physics, it's pretty common for physicists to
emphasize that all analyses should be done algebraically, with numbers
put in only at the end, and units are not involved in most of the
analysis. Typically it is only the final result for which the
physicist cares that correct units be given.

Bruce Sherwood

On Sat, Jun 9, 2012 at 9:37 AM, Kevin Karplus <ka...@so...> wrote:
>
> I'm glad to see that Vpython has a future, and that you do have plans
> to make it work on 64-bit Macs.
>
> I would find requiring "rate" statements a bit annoying, but
> tolerable.  I wonder whether it would become a major problem for new
> programmers, though, as its necessity is not obvious.
>
> One thing I would like to see is a good integration of units into the
> computation.  I tell my students to keep units with their intermediate
> results, and I suspect that most real physics teachers do also, so it
> is a bit annoying that Vpython encourages (sometimes even requires)
> unitless numbers.  I've been using the Unum package, which works
> fairly well but is rather slow (I also had to add a sqrt function for
> it).
>
> See the simulation (without animation---just using visual for optional
> graphs) in
> http://gasstationwithoutpumps.wordpress.com/2012/06/04/soda-bottle-rocket-simulation-take-2
> for an example of using Unum
>
> The visual package does not play nicely with Unum, since all the
> animation and graphing has to be unitless.  I think that a little more
> care in "duck typing" could have made the routines work just fine with
> numbers that have units.
>
>
>

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

I agree that using units can be a good thing, especially if one gets
an error message when trying to add 5 kilograms to 3 meters. However,
among the very many academics I know who use VPython for research or
educational purposes, no one else has ever asked for VPython to
support physical units. (This may be a lack of imagination on their
part, of course.)

I judge that implementing units in VPython would be a very major
undertaking, and it would have to be done very carefully so as not to
affect the execution speed of programs that don't use units. In fact,
Kevin Karplus commented that Python with units is rather slow. There
are hundreds of details that would have to be addressed in the C++
code, not to mention that numpy and the Boost libraries don't handle
units.

Unfortunately, very few people have ever contributed to the
development and maintenance of the central C++ component of VPython,
possibly because it is multithreaded C++ with connections to Boost
libraries, numpy, and OpenGL, which means that it can be daunting. I
personally see far more to do than I can accomplish within the domain
of wants and needs that are important to all VPython users. That means
that someone(s) would have to step forward and take on what is
probably a very big task if units are to be supported in VPython.

Bruce Sherwood

[Visualpython-users] Units. [Was: Future = (Vpython + Glowscript) | Glowscript |]

[Jerzy K. <jer...@un...>]

Bruce Sherwood:
> I agree that using units can be a good thing, especially if one gets
> an error message when trying to add 5 kilograms to 3 meters. However,
> among the very many academics I know who use VPython for research or
> educational purposes, no one else has ever asked for VPython to
> support physical units. (This may be a lack of imagination on their
> part, of course.)

There is a Python package "Magnitude" written by Juan Reyero. Did 
anybody try it?

Physical units in a computational context is not a simple issue. For 
simple mechanical systems, OK, but when people have more "universal" 
ambitions, there are some natural conversions, e.g. meters ARE seconds 
if the speed of light is considered to be an universal constant. Many 
physicists use for years the unit system where c = h_slash = 1.
So, I do not think that the reluctance to use explicit SI (or other) 
units has anything to do with the lack of imagination.
Of course, typical VPython users are usually far from such dilemmas, 
but, despite a long history, a coherent introduction of units into a 
computational framework needs more work (in my opinion).

Jerzy Karczmarczuk

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

On Sat, Jun 9, 2012 at 10:14 AM, Bruce Sherwood <Bru...@nc...> wrote:
> Very interesting. There is much in your message about which I have no
> knowledge and no opinion. However, I can make some comments about the
> Big Picture.
>
> For a variety of reasons, I am personally committed to the further
> development and maintenance of both VPython and GlowScript.

ok, good news :-)

> [...]
>
> As I've said, I'm dreaming of constructing a VPython+ that would
> require a modern graphics card. If possible, I'd like to build it on
> top of one of the newer Python frameworks that work cross-platform, in
> particular to solve the menacing problem that Carbon on the Mac is not
> available for 64-bit Python.

out of curiosity, which frameworks are you considering/referencing?

> [...]
>
> I wasn't aware of the pypy.org project, and certainly running 5 times
> faster than CPython is important. What is "co", which you mention?

oh sorry, i just meant "and company", ie. pypy and all it's
dependencies, along with whatever other considerations are needed.
pypy is pretty incredible, and IMO, is the future of Python, and
possible other dynamic langs like Ruby et al.

thanks for your comments Bruce; i will note the vitality of both
projects during my demonstration.

-- 

C Anthony

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

[John Z. <joh...@wa...>]

Let me just second that pypy is definitely worth looking at. For programs that have one main loop with many independent (random?) calculations, pypy can provide much more speedup. I've gotten over 100 fold speedup in some cases (yes that's 100 fold, not 100%). Pypy makes it possible to do things like real-time image manipulation or ray-tracing in pure Python code. At least on Linux (see below).

Since pypy is compatible with ctypes, it would be possible to combine it with something like pyglet for a cross-platform, pure Python, VPython+ that relies on a modern graphics card for the heavy lifting on the graphics side. However, pypy does have a couple downsides:

1) it's Python 2.7, not 3.x
2) I'm not sure what the status of the JIT compiler is for non-linux platforms. I think they are working on this. 
3) Numpy support is experimental/in-development at this point.

If I had the time, which I don't, I would definitely be interested in working on a pure Python reimplementation of VPython along these lines.

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: C Anthony Risinger [an...@xt...]
Sent: Tuesday, June 12, 2012 12:56 PM
To: Bru...@nc...
Cc: vis...@li...
Subject: Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

On Sat, Jun 9, 2012 at 10:14 AM, Bruce Sherwood <Bru...@nc...> wrote:
> Very interesting. There is much in your message about which I have no
> knowledge and no opinion. However, I can make some comments about the
> Big Picture.
>
> For a variety of reasons, I am personally committed to the further
> development and maintenance of both VPython and GlowScript.

ok, good news :-)

> [...]
>
> As I've said, I'm dreaming of constructing a VPython+ that would
> require a modern graphics card. If possible, I'd like to build it on
> top of one of the newer Python frameworks that work cross-platform, in
> particular to solve the menacing problem that Carbon on the Mac is not
> available for 64-bit Python.

out of curiosity, which frameworks are you considering/referencing?

> [...]
>
> I wasn't aware of the pypy.org project, and certainly running 5 times
> faster than CPython is important. What is "co", which you mention?

oh sorry, i just meant "and company", ie. pypy and all it's
dependencies, along with whatever other considerations are needed.
pypy is pretty incredible, and IMO, is the future of Python, and
possible other dynamic langs like Ruby et al.

thanks for your comments Bruce; i will note the vitality of both
projects during my demonstration.

--

C Anthony

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Visualpython-users mailing list
Vis...@li...
https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

I certainly welcome any and all suggestions for the appropriate
framework for VPython+. As attractive as the promise of pypy is, it
sounds to me like it's not a sufficiently mature platform on which to
base a first try at VPython+.

Bruce

On Tue, Jun 12, 2012 at 4:20 PM, John Zelle <joh...@wa...> wrote:
> Let me just second that pypy is definitely worth looking at. For programs that have one main loop with many independent (random?) calculations, pypy can provide much more speedup. I've gotten over 100 fold speedup in some cases (yes that's 100 fold, not 100%). Pypy makes it possible to do things like real-time image manipulation or ray-tracing in pure Python code. At least on Linux (see below).
>
> Since pypy is compatible with ctypes, it would be possible to combine it with something like pyglet for a cross-platform, pure Python, VPython+ that relies on a modern graphics card for the heavy lifting on the graphics side. However, pypy does have a couple downsides:
>
> 1) it's Python 2.7, not 3.x
> 2) I'm not sure what the status of the JIT compiler is for non-linux platforms. I think they are working on this.
> 3) Numpy support is experimental/in-development at this point.
>
> If I had the time, which I don't, I would definitely be interested in working on a pure Python reimplementation of VPython along these lines.
>
> John Zelle, PhD
> Professor of Computer Science
> Wartburg College
>
>
> ________________________________________
> From: C Anthony Risinger [an...@xt...]
> Sent: Tuesday, June 12, 2012 12:56 PM
> To: Bru...@nc...
> Cc: vis...@li...
> Subject: Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???
>
> On Sat, Jun 9, 2012 at 10:14 AM, Bruce Sherwood <Bru...@nc...> wrote:
>> Very interesting. There is much in your message about which I have no
>> knowledge and no opinion. However, I can make some comments about the
>> Big Picture.
>>
>> For a variety of reasons, I am personally committed to the further
>> development and maintenance of both VPython and GlowScript.
>
> ok, good news :-)
>
>> [...]
>>
>> As I've said, I'm dreaming of constructing a VPython+ that would
>> require a modern graphics card. If possible, I'd like to build it on
>> top of one of the newer Python frameworks that work cross-platform, in
>> particular to solve the menacing problem that Carbon on the Mac is not
>> available for 64-bit Python.
>
> out of curiosity, which frameworks are you considering/referencing?
>
>> [...]
>>
>> I wasn't aware of the pypy.org project, and certainly running 5 times
>> faster than CPython is important. What is "co", which you mention?
>
> oh sorry, i just meant "and company", ie. pypy and all it's
> dependencies, along with whatever other considerations are needed.
> pypy is pretty incredible, and IMO, is the future of Python, and
> possible other dynamic langs like Ruby et al.
>
> thanks for your comments Bruce; i will note the vitality of both
> projects during my demonstration.
>
> --
>
> C Anthony