Re: [Visualpython-users] install glitch and some code

[kirby u. <kir...@gm...>]

On Sat, Nov 13, 2010 at 2:21 PM, Bruce Sherwood <bas...@nc...> wrote:
> Thanks for the links. I happened to notice (in planets.py) these statements:
>
> from visual import *
> from math import pi, sin, cos, radians
>
> The second import is superfluous. I found a similar situation in
> vfun.py. Here is a blurb from the first page of the VPython 5.4
> on-line VPython help (the vis module is new with VPython 5.4):

Yep, good pointer.

>
> ----------------------------------------------------------------------------------------------------------
> For experienced programmers
>
> As a convenience to novice programmers to provide everything needed to
> get started, "from visual import *" imports all of the Visual features
> and executes "from math import *" and "from numpy import *". It also
> arranges that for routines common to both math and numpy such as sqrt,
> the much faster math routine is used when possible (when the argument
> is a scalar rather than an array).
>

I had a baptism by fire re NumPy this spring when I was fielded by
Holden Web to do three intensive days in generic Python for some of
the Hubble people (Space Telescope Science Institute -- I was at
Maryland Science Center on Hubble's 20th birthday, watching the
3D IMAX movie with a few other grays).

http://worldgame.blogspot.com/2010/04/python-gig.html

STScI is a principal driver behind NumPy as you probably know.

> If you want to import the visual objects selectively, import them from
> the vis module. Two simple examples:
>
> import vis
> vis.box(color=vis.color.orange,material=vis.materials.wood)
>
> from vis import (box, color, materials)
> box(color=color.orange, material=materials.wood)
>
> There are clean modules vis.controls, vis.filedialog, and vis.graph
> equivalent to the modules visual.controls, visual.filedialog, and
> visual.graph. The latter versions execute "from visual import *" and
> are retained because some programs expect that behavior when importing
> one of these modules.
>
> The documentation is written assuming that "from visual import *" is used.
> ----------------------------------------------------------------------------------------------------------
>
> Given your teaching involving Pov-ray, I hope you're aware of the
> povexport module available in the Contributed section of vpython.org,
> which makes it easy to export a scene from VPython to Pov-ray, to
> render with higher quality.
>

Yes, though only dimly.  I should be pointing students to that
resource way more than I do.  POV-Ray is fantastic.

I came to Python from Visual FoxPro, where I was doing the
computations and spitting out scene description language.

I even published an article about doing this in FoxPro Advisor,
introducing my mostly business type readers to newfangled
"quadray coordinates" (mucho esoteric).

Memorabilia:

http://www.flickr.com/photos/17157315@N00/5126606082/
http://www.flickr.com/photos/17157315@N00/5126606312/in/photostream/
http://en.wikipedia.org/wiki/Quadray_coordinates



> Bruce
>
> P.S. I find it confusing that the way the mailing list works is that
> Reply goes to the sender rather than to the group. Seems wrong. Dunno
> if there's a way to change that.
>

In Majordomo and others I've administered, yes it's easy.  But I have
never studied the Sourceforge API so perhaps it ain't so easy with
that one.  List admin can be a royal pain.  Only doing like two at
the moment, both on Yahoo! (pretty easy).

> P.P.S. I too have been deeply involved in computational education.
> Ruth Chabay and I have developed an alternative to the university
> intro physics course taken by engineering and science students,
> treating intro physics from a 20th-century perspective (the standard
> course is essentially a 19th-century course, due to enormous inertia
> in physics departments). One of the many 20th-century aspects of the
> course is that we've introduced serious computational modeling by the
> students, who write and/or revise VPython programs to model physical
> systems and/or display in 3D abstract quantities such as fields. You
> can read about this at matterandinteractions.org.
>

I'm still kicking myself for not getting to Ruth Chabay's presentations
at the most recent AAPT conference in Portland, Oregon, where I was
hanging out with Dr. Bob Fuller emeritus, University of Nebraska / Lincoln.

Bob seems to track your work pretty closely, but then he's an expert
tracker where physics education is concerned, as I know from our
collaboration on the First Person Physics project.

Here's my pithy write-up of said conference -- more than one VPython
talk in the catalog as I recall, dang that I missed em:

http://worldgame.blogspot.com/2010/07/physics-conference.html

What I'm attempting to do with movingballs2.py (just posted) right
now is get it wrapped as a "local server" type COM object on
Windows 7using Mark Hammond's Win32 stuff, so I can
dramatically demonstrate Python running as a separate process,
independently of the calling program -- which would be Microsoft
Visual FoxPro 9 again (still using it).

I'm pretty sure I'd need to use threading or the new multi-process
API in Python 2.7.  I have non-threaded COM working in the
ReportLab pilot (PDF generation), but that's InProcess, not
Local Server (different flavors of COM).

My client would be most impressed if I could have those colored
balls moving across the screen and change their color interactively
by entering function calls in the FoxPro shell e.g.

# COM object in Windows
raygun = CREATEOBJECT("MartianMath.movingballs")
raygun.start()   # trigger thread or process

<< control returns, balls moving in VPython window >>

raygun.ballcolor("red")

<< color changes, Vpython keeps running, control back to Fox >>

raygun.ballcolor("green")

etc.

raygun.stop()
release raygun

It'd be visually cool.

However the client's eventual applications are not VPythonic -- a
transportation engineering company doing truck load optimization
(traveling salesman / GIS type stuff), and getting impressive
results (production environment, paying clients -- dang that MSFT
is pulling the plug on the Fox, at one time a proud flagship --
too proud, some say).

Yes, this is all rather esoteric stuff, but maybe the more generic
VPython-in-its-own-process problem has been well worked in
another (similar-enough) example?

And/or I'll just keep plugging away with my little experiments.
Can't be *that* difficult.

Kirby

PS:  I was a debate partner vis-a-vis the late Arthur Siegel whom
I see credited at your web site.  We were actually pretty good
buddies for all that sparring, had some cool meetups in NYC.
Pygeo is a tour de force Vpython application and serious
projective geometry application  http://pygeo.sourceforge.net/