visualpython-users

Re: [Visualpython-users] Re: compile problem (graphing in python) -- BLT

[Gary P. <pa...@in...>]

>
> See instead:  http://sourceforge.net/projects/blt/
>
> The binaries can be downloaded from there.
>
> -gary pajer

Futhermore, the installation of BLT on a Win98/Python/Tcl/Tk/Pmw system
requires a couple of manual tweaks.
Here's what I found in a google groups search.  This procedure worked for
me.

-gary

---------------------------------------------------------------
From: Peter Brown (ph...@ac...)
Subject: Re: BLT installation woes under W98 (Python 2.1)
Newsgroups: comp.lang.python
Date: 2001-04-24 19:17:07 PST


I got it!  (At least, it looks like I got it--the BLT-dependent demos
of Pmw now run.  I have not started using the setup for real work.)

What I did:
- Stock Python install.  I dropped back to 2.0 (Pmw 0.8.5 passes its
  tests in 2.0 and doesn't in 2.1), so my Python went into
  C:/Python20.  (Note: I know of no reason why this wouldn't work with
  2.1.  I just haven't tested it there.)
- Install BLT 2.4u into C:/Python20/tcl, using BLT's installer (the
  one for Tcl/Tk 8.3).  This gives you bin, include, and lib subdirs
  of C:/Python/tcl, with all the BLT stuff in them.
- Copy C:/Python20/tcl/lib/blt2.4 into C:/Python20/tcl/tcl8.3.
- Put the BLT DLLs in a directory on your PATH (not necessarily a
  system directory, just has to be on your PATH).

And it works.  (For me--usual disclaimers apply.)  I did not move any
of the other BLT files.

[Visualpython-users] Re: compile problem (graphing in python) -- BLT

[Gary P. <pa...@in...>]

> See:
>
> Python Mega-Widgets:              http://pmw.sourceforge.net/
> BLT in Python (lots of examples): http://heim.ifi.uio.no/~hpl/Pmw.Blt/doc/
> The official BLT:                 http://incrtcl.sourceforge.net/blt/


Thanks, Chris.
I want to point out that the link to the Windows BLT executable given on the
official BLT site seems to be broken.

See instead:  http://sourceforge.net/projects/blt/

The binaries can be downloaded from there.

-gary pajer

[Visualpython-users] Re: compile problem (graphing in python)

[Chris B. <bu...@hv...>]

Hi all.

Just thought I'd mention that the kind of graphing Arnd is looking for
is available through BLT, a widget set for Tcl/Tk.  Luckily, BLT is
available through the Python Mega Widgets (Pmw).  It's a bit of a pain
to setup (need to install BLT, then Pmw) and since BLT is a Tcl/Tk
add-on, it uses it's own vectors (not Numeric arrays).  However, the
interface is rather nice:  you make a vector and tell BLT to graph it.
Then, when you change the vector, BLT automagically updates the graph
widget (line, markers, scaling, etc).  It's by no means as slick as Visual
(e.g., you need to use Tkinter to dress up the widget), but works well for 
some purposes.

See:

Python Mega-Widgets:              http://pmw.sourceforge.net/
BLT in Python (lots of examples): http://heim.ifi.uio.no/~hpl/Pmw.Blt/doc/
The official BLT:                 http://incrtcl.sourceforge.net/blt/

I used it to build an interactive ODE integrator (for watching choatic
systems evolve while they are being integrated).  If you're interested, have
a look:  
http://pathfinder.scar.utoronto.ca/~csca57/RKFgraph.html

Chris

--
Chris Burns
Visiting Assistant Professor
Dept. of physics and astronomy, Swarthmore College
cb...@sw...      http://astro.swarthmore.edu/~burns

[Visualpython-users] Re: plotting many dots

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

Thanks to the issues raised about plotting lots of dots in visual.graph, I
can see more clearly why we need (at the least) a "points" object, very
similar to the curve object (maybe even an option for the curve object). In
plotting large amounts of data as points, currently each point must be a
separate object, which uses up lots of memory. It is also presumably
expensive to run through all those objects in each Visual window update.
(Visual paints the picture from scratch each time -- there is no attempt to
figure out which part of the scene has changed.)

The points object would be very similar to the curve object, but it wouldn't
draw lines between the points of the curve. There is an issue that with the
curve object, when there get to be too many points, intermediate points are
dropped for performance reasons. That's not tenable with data points (and
for that matter causes display problems with curve in some cases, too).
Probably there needs to be some programmer control over this, if the
plotting of lots of data is to be made feasible.

Comments? Suggestions?

Bruce Sherwood

[Visualpython-users] A better mousetrap

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

Having thought about it overnight, here's a significantly better mouse
routine for graphing. It displays crosshairs as you drag the mouse. And just
in case the mailer doesn't preserve tabs correctly, I also attach a copy of
the file.

Bruce Sherwood

--------------------------------------------------

from visual.graph import *

oscillation = gdisplay(title='Test Plotting', xtitle='Time',
ytitle='Response')

funct1 = gcurve(color=color.cyan)
funct2 = gvbars(color=color.red, delta=0.8)
funct3 = gdots(color=color.yellow)

for t in arange(-30, 76, 1):
    funct1.plot(pos=(t, 5.0+5.0*cos(-0.2*t)*exp(0.015*t)) )
    funct2.plot(pos=(t, 2.0+5.0*cos(-0.1*t)*exp(0.015*t)) )
    funct3.plot(pos=(t, 5.0*cos(-0.03*t)*exp(0.015*t)) )

showxy = label(display=oscillation.display, yoffset=10, line=0, opacity=1,
visible=0)
gray = (0.5,0.5,0.5)
hor = curve(display=oscillation.display, color=gray, visible=0)
vert = curve(display=oscillation.display, color=gray, visible=0)
pos = None
while 1:
    status = oscillation.display.mouse
    if status.events:
        m = status.getevent()
        if m.press == 'left':
            pos = status.pos
            showxy.visible = 1
            disp = oscillation.display
            xmax = disp.range.x
            ymax = disp.range.y
            xcenter = disp.center.x
            ycenter = disp.center.y
            hor.visible = 1
            vert.visible = 1
        elif m.release == 'left':
            pos = None
            showxy.visible = 0
            hor.visible = 0
            vert.visible = 0
    if pos and (pos is not status.pos):
        showxy.pos = pos = status.pos
        hor.pos = [(xcenter-xmax,pos.y),(xcenter+xmax,pos.y)]
        vert.pos = [(pos.x,ycenter-ymax),(pos.x,ycenter+ymax)]
        showxy.text = '%0.3g,%0.3g' % (status.pos.x,status.pos.y)

[Visualpython-users] Mouse (x,y) in a graph

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

Here is a little program that plots a graph and displays (x,y) whenever the
left mouse button is down.

from visual.graph import *

oscillation = gdisplay(title='Test Plotting', xtitle='Time',
ytitle='Response')
funct1 = gcurve(color=color.cyan)
funct2 = gvbars(color=color.red, delta=0.8)
funct3 = gdots(color=color.yellow)

for t in arange(-30, 76, 1):
    funct1.plot(pos=(t, 5.0+5.0*cos(-0.2*t)*exp(0.015*t)) )
    funct2.plot(pos=(t, 2.0+5.0*cos(-0.1*t)*exp(0.015*t)) )
    funct3.plot(pos=(t, 5.0*cos(-0.03*t)*exp(0.015*t)) )

showxy = label(display=oscillation.display, yoffset=10, line=0, opacity=1,
visible=0)
while 1:
    rate(300)
    m = oscillation.display.mouse
    if m.button == 'left':
        showxy.pos = (m.pos.x,m.pos.y)
        showxy.text = '%d,%d' % (m.pos.x,m.pos.y)
        showxy.visible = 1
    else:
        showxy.visible = 0

[Visualpython-users] better graphing

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

I tried the experiment of using faces instead of label for plotting dots in
visual.graph. It works fine with fixed axes but with variable axes
(automatic rescaling) it is way too slow, due to the need for readjustment
of the faces to keep (for example) a square dot square, whenever there is a
change of scale. The right scheme would be to add a pixel-oriented object to
Visual, to be used for such things as plotting of dots. Note that there is a
precedent: some attributes of the label object are pixel-oriented.

Bruce Sherwood

Re: [Visualpython-users] compile problem

[Andrew W. <an...@ph...>]

>From: <ba...@ph...>

>> Clearly, Visual is more aimed at 3D than 2D, but
>> I haven't found a good 2D graphics display
>> which allows for dynamic display from within python
>> + mouse interaction/events.
>> In particular, I really like the compactness in Visual,
>> just three short commands do the job (gdisplay, dots=gdots, dots.plot)
>> to get a plot.
>> Are there any plans to realize 1.)-3.), or are they already
>> there and I just overlooked it ??

You could always use graphing tools outside Visual - for example, if
you're on a windows box, here's a short chunk of code that will start
Excel (if it isn't running) and get it to display a graph of data you
pass in a list:

www.aifb.uni-karlsruhe.de/.../Artikel/
March%202000%20Feature%20Fast,%20Free%20Prototyping%20in%20Python.htm

The other solution is one of the modules for graphing/plotting in
Python. I assume Visual's main loop would mess with other Python GUI's
in the same process, but you could write a 'graph server' program that
runs seperately, and have your main Visual code communicate with it -
sending the data to graph and getting commands back from the user.

There's an interactive graphing interface, gracePlot, letting you
fiddle with scales, axes, etc on the graph using either GUI buttons or
an interactive python prompt, at:

http://www.idyll.org/~n8gray/code/

(and check out the other alternatives at http://www.vex.net/parnassus/
under 'Graphics')

I haven't played with either of these, I just thought I'd point out
(admittedly non-ideal) alternatives to the built-in Visual graphing if
you need some set of features right away...

Andrew

Re: [Visualpython-users] compile problem

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

It would not be difficult to add mouse interactivity to the visual.graph
module, since that module was written completely in Python (by me), and
anyone (including you) could easily add the mouse functionality you usefully
suggest. See the file "graph" in the visual directory.

Points 2 and 3 are more difficult. I've never been happy with the only way I
could plot dots in visual.graph using the existing Visual module. I'm
plotting the letter "o" using a label object. This is presumably expensive
in time, and I'm not terribly surprised to learn that there is some limit on
the number of dots to display, although I wasn't aware of it. (I'd be
interested to have a test routine that illustrates this problem, though.) I
couldn't plot a circle or a disk for a data point, because the graph axes
are not uniform (different in x and y), and a circle or disk object comes
out elliptical. There's also the problem of positioning the "o" with its
center correctly placed. Not a satisfactory situation, and you're right to
point out the failings.

Perhaps what is needed is to introduce into Visual some object such as "dot"
that has a fixed circular form independent of scaling. It is also
conceivable that one might make creative use of the faces object (which I
think was introduced by Dave Scherer long after I'd originally written the
graph module). It would be necessary every time the graph scaling changes to
run through the list of dots and re-do the faces specifications. But getting
away from using a font-based label would be good. This would also permit
different shapes (e.g. squares and triangles).

Bruce Sherwood

----- Original Message -----
From: <ba...@ph...>
> Unfortunately, it seems that Visual does not have
> all the capabilities I am looking for.
> Namely, I have the following issues
>   1.) There seems to be no possibility to use the mouse in 2D plots
>       (visual.graph), namely to get its current position.
>   2.) When plotting many individual points with
>          dots.plot(gdisplay=graph,pos=(x,y))
>       it seems that somehow
>       after too many have been plotted, no further ones will be shown,
>       Also I am a bit unsure about the speed (well, at home
>       I have an old PII, 350MHz ... ;-)
>   3.) I did not figure out how to change the style and size
>       of the plot points (but that's only a minor point
>       to the above).
>
> Clearly, Visual is more aimed at 3D than 2D, but
> I haven't found a good 2D graphics display
> which allows for dynamic display from within python
> + mouse interaction/events.
> In particular, I really like the compactness in Visual,
> just three short commands do the job (gdisplay, dots=gdots, dots.plot)
> to get a plot.
> Are there any plans to realize 1.)-3.), or are they already
> there and I just overlooked it ??
>
>
> ((Background Info: we are presently considering
> to use Python+Numeric together with some good graphics
> add-on for a course on computational physics next summer term.
> One crucial aspect for the choice of programming language/system
> is dynamic display of data + interactive aspects via mouse ...
> Any pointers are appreciated...
> ))

Re: [Visualpython-users] compile problem

[<ba...@ph...>]

Hi,

thank you very much for your rapid response.

I redid the compilation on my home machine (with
  Python 2.2.1c2 (#1, Apr  4 2002, 18:54:47)
  [GCC 2.95.4 20011006 (Debian prerelease)] on linux2
)
and had no problems. Everything seems to work fine.

Unfortunately, it seems that Visual does not have
all the capabilities I am looking for.
Namely, I have the following issues
  1.) There seems to be no possibility to use the mouse in 2D plots
      (visual.graph), namely to get its current position.
  2.) When plotting many individual points with
         dots.plot(gdisplay=graph,pos=(x,y))
      it seems that somehow
      after too many have been plotted, no further ones will be shown,
      Also I am a bit unsure about the speed (well, at home
      I have an old PII, 350MHz ... ;-)
  3.) I did not figure out how to change the style and size
      of the plot points (but that's only a minor point
      to the above).

Clearly, Visual is more aimed at 3D than 2D, but
I haven't found a good 2D graphics display
which allows for dynamic display from within python
+ mouse interaction/events.
In particular, I really like the compactness in Visual,
just three short commands do the job (gdisplay, dots=gdots, dots.plot)
to get a plot.
Are there any plans to realize 1.)-3.), or are they already
there and I just overlooked it ??


((Background Info: we are presently considering
to use Python+Numeric together with some good graphics
add-on for a course on computational physics next summer term.
One crucial aspect for the choice of programming language/system
is dynamic display of data + interactive aspects via mouse ...
Any pointers are appreciated...
))

Many thanks,

Arnd


On Fri, 17 Jan 2003, Andy Dougherty wrote:

> On Fri, 17 Jan 2003 ba...@ph... wrote:
>
> > I tried to install VPython-2002-07-22.tar.gz on a
> > debian woody machine, and ran into the following error message:
> >
> > g++ -I. -I./CXX/Include -I/home/abaecker/PYTHON/include/python2.3
> > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
> > -D_REENTRANT -I/usr/X11R6/include -w   -c -o platlinux.o platlinux.cpp
> > platlinux.cpp:71: `ANY' was not declared in this scope
> > platlinux.cpp:71: parse error before `)'
> > make: *** [platlinux.o] Error 1
>
> I compiled it just fine on a Debian woody machine.  One difference is that
> I used python 2.2.2, not python 2.3.  I suspect the 2.3 version of python
> is what's causing your problem.  Go back and install 2.2.2 (or
> something similar to that) and you should be fine.
>
> >   gcc version 2.95.4 20011002 (Debian prerelease)
>
> I'm using the same one.
>
> > P.S.: g++3.2 even fails earlier:
> >
> > g++-3.2 -I. -I./CXX/Include -I/home/abaecker/PYTHON/include/python2.3
> > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
> > -D_REENTRANT -I/usr/X11R6/include -w   -c -o arrow.o arrow.cpp
> > In file included from pvector.h:6,
> >                  from cvisual.h:6,
> >                  from display.h:5,
> >                  from prim.h:5,
> >                  from axial.h:5,
> >                  from arrow.cpp:1:
> > CXX/Include/CXX_Objects.h:967: no class template named
> > `random_access_iterator'
> >    in `std'
>
> Yes, that's been reported before, and I think there's an #ifdef somewhere
> in the visual sources.  [poking around...]
>
> If, for some reason, you don't want to take my advice above and use
> python-2.2.2, then you can try getting around this particular problem
> by changing the line in cvisual/CXX/Include/CXX_Config.h that says
>
> 	#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
> to
> 	#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0
>
> and see what happens.
> If that doesn't work, try searching the archives of this group -- I
> know this problem has been reported before.
>
> More generally, this should ultimately probably be fixed in the cvisual
> sources, but I'm not sufficiently familiar with C++ myself to suggest
> a fix.  Checking out the stl_iterator documentation, I find this about
> random_access_iterator:
>
>    Defined in the standard header iterator, and in the nonstandard
>    backward-compatibility header iterator.h. This class is no longer part
>    of the C++ standard, although it was present in early drafts of the
>    standard. It is retained in this implementation for backward
>    compatibility.
>
> And the header file stl_iterator.h has these lines (at least in my version):
>
>     // The base classes input_iterator, output_iterator, forward_iterator,
>     // bidirectional_iterator, and random_access_iterator are not part of
>     // the C++ standard.  (they have been replaced by struct iterator.)
>     // They are included for backward compatibility with the HP STL.
>
> So it looks like cvisual has run into the problem of shifting
> standards :-(.
>
> Anyway, using gcc-2.95 and python-2.2.2 should just work.  Unless
> you've got a sense of adventure, I'd try that combination first :-).
>
> Hope this helps,
>
>     Andy Dougherty		dou...@la...
>     Dept. of Physics
>     Lafayette College, Easton PA 18042
>
>
>

Re: [Visualpython-users] compile problem

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

On Fri, 17 Jan 2003 ba...@ph... wrote:

> I tried to install VPython-2002-07-22.tar.gz on a
> debian woody machine, and ran into the following error message:
> 
> g++ -I. -I./CXX/Include -I/home/abaecker/PYTHON/include/python2.3
> -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
> -D_REENTRANT -I/usr/X11R6/include -w   -c -o platlinux.o platlinux.cpp
> platlinux.cpp:71: `ANY' was not declared in this scope
> platlinux.cpp:71: parse error before `)'
> make: *** [platlinux.o] Error 1

I compiled it just fine on a Debian woody machine.  One difference is that
I used python 2.2.2, not python 2.3.  I suspect the 2.3 version of python
is what's causing your problem.  Go back and install 2.2.2 (or
something similar to that) and you should be fine.

>   gcc version 2.95.4 20011002 (Debian prerelease)

I'm using the same one.

> P.S.: g++3.2 even fails earlier:
> 
> g++-3.2 -I. -I./CXX/Include -I/home/abaecker/PYTHON/include/python2.3
> -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
> -D_REENTRANT -I/usr/X11R6/include -w   -c -o arrow.o arrow.cpp
> In file included from pvector.h:6,
>                  from cvisual.h:6,
>                  from display.h:5,
>                  from prim.h:5,
>                  from axial.h:5,
>                  from arrow.cpp:1:
> CXX/Include/CXX_Objects.h:967: no class template named
> `random_access_iterator'
>    in `std'

Yes, that's been reported before, and I think there's an #ifdef somewhere
in the visual sources.  [poking around...]  

If, for some reason, you don't want to take my advice above and use
python-2.2.2, then you can try getting around this particular problem
by changing the line in cvisual/CXX/Include/CXX_Config.h that says

	#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
to
	#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0

and see what happens.
If that doesn't work, try searching the archives of this group -- I
know this problem has been reported before.

More generally, this should ultimately probably be fixed in the cvisual 
sources, but I'm not sufficiently familiar with C++ myself to suggest
a fix.  Checking out the stl_iterator documentation, I find this about
random_access_iterator:
   
   Defined in the standard header iterator, and in the nonstandard
   backward-compatibility header iterator.h. This class is no longer part
   of the C++ standard, although it was present in early drafts of the
   standard. It is retained in this implementation for backward
   compatibility.

And the header file stl_iterator.h has these lines (at least in my version):

    // The base classes input_iterator, output_iterator, forward_iterator,
    // bidirectional_iterator, and random_access_iterator are not part of
    // the C++ standard.  (they have been replaced by struct iterator.)
    // They are included for backward compatibility with the HP STL.

So it looks like cvisual has run into the problem of shifting
standards :-(.

Anyway, using gcc-2.95 and python-2.2.2 should just work.  Unless
you've got a sense of adventure, I'd try that combination first :-).

Hope this helps,

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

[Visualpython-users] compile problem

[<ba...@ph...>]

Hi,

I tried to install VPython-2002-07-22.tar.gz on a
debian woody machine, and ran into the following error message:

g++ -I. -I./CXX/Include -I/home/abaecker/PYTHON/include/python2.3
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-D_REENTRANT -I/usr/X11R6/include -w   -c -o platlinux.o platlinux.cpp
platlinux.cpp:71: `ANY' was not declared in this scope
platlinux.cpp:71: parse error before `)'
make: *** [platlinux.o] Error 1
cp: cannot stat `cvisualmodule.so': No such file or directory

The compiler I am using is
  gcc version 2.95.4 20011002 (Debian prerelease)

ANY ;-) help is appreciated.

Arnd Baecker

P.S.: g++3.2 even fails earlier:

g++-3.2 -I. -I./CXX/Include -I/home/abaecker/PYTHON/include/python2.3
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-D_REENTRANT -I/usr/X11R6/include -w   -c -o arrow.o arrow.cpp
In file included from pvector.h:6,
                 from cvisual.h:6,
                 from display.h:5,
                 from prim.h:5,
                 from axial.h:5,
                 from arrow.cpp:1:
CXX/Include/CXX_Objects.h:967: no class template named
`random_access_iterator'
   in `std'
CXX/Include/CXX_Objects.h:1077: no class template named
`random_access_iterator
   ' in `std'
make: *** [arrow.o] Error 1
cp: cannot stat `cvisualmodule.so': No such file or directory

Re: [Visualpython-users] threebody.py

[Andrew M. <mor...@ph...>]

On Thu, 2003-01-16 at 21:21, Bruce Sherwood wrote:
> You might enjoy the attached program that lets you play with three-body
> orbits. The first time you run the program it creates data files for some
> interesting orbits. You can make your own simply by dragging the green st=
ar
> to set its initial position and initial velocity. The nonplanar orbit was
> constructed by Matt Kohlmyer by initially rotating the field of view befo=
re
> dragging.
>=20
> Bruce Sherwood

What version of Tkinter is used with python2.2?   Can it be installed via r=
pm?

--=20
Andrew Morrison <mor...@ph...>

[Visualpython-users] threebody.py

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

You might enjoy the attached program that lets you play with three-body
orbits. The first time you run the program it creates data files for some
interesting orbits. You can make your own simply by dragging the green star
to set its initial position and initial velocity. The nonplanar orbit was
constructed by Matt Kohlmyer by initially rotating the field of view before
dragging.

Bruce Sherwood

[Visualpython-users] Compile issue

[Zach H. <za...@fi...>]

I'm trying to compile vPython, I have changed all the relavent prifixes, and 
have installed all the dependencies.

I'm using gcc v3.2.1.  After changins some various things I finally get the 
compile started, and it compiles until I get this error:

g++ -I. -I./CXX/Include -I/usr/include/python2.2  -I/usr/include/gtk-1.2 
-I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT 
-I/usr/X11R6/include -w   -c -o platlinux.o platlinux.cpp
platlinux.cpp: In function `std::string format(std::basic_string<char,
   std::char_traits<char>, std::allocator<char> >, ...)':
platlinux.cpp:25: cannot pass objects of non-POD type `struct std::string'
   through `...'
make: *** [platlinux.o] Error 1

Does anyone have any ideas on what the problem might be?

Thanks,
Zach Hobbs

[Visualpython-users] ANN: PyGeo version .8a released

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

ANN: PyGeo version .8a released
----------------------------------------------------------
see http://home.netcom.com/~ajs

Something quite young can grow up a quite some in a year.
I believe PyGeo has.

And what is PyGeo? :
====================

PyGeo is a dynamic geometry laboratory and toolkit requiring Python2.2 and
VPython (and Numeric as distributed with VPython). PyGeo may be used to
explore the most  basic concepts of Euclidean geometry at an introductory
level, including by elementary schools students and their teachers.

But is particularly suitable for exploring more advanced geometric topics -
such as projective geometry and the geometry of complex numbers.

The intent is to bring a rich visual experience to the study of both
synthetic and analytic geometry

The inspiration:
================
PyGeo is inspired by other dynamic geometry applications - Cabri, Geometers
Sketchpad, cinderella  and, in particular, David Joyce's wonderful open
source java code which is used to create his inspiring site of Euclids
Elements   with the classic constructions in web-enabled dynamic form.

What distinguishes PyGeo
========================

   The 3rd dimension
    ------------------
PyGeo was built from inception to take advantage of the current generation
of 3d graphic capabilities (applied geometry, in itself, of course). While
this has a certain appeal just on motivational grounds, the importance of
this aspect of PyGeo is, it is contended, of a significantly higher order.
The study even of the 2 dimensional geometries beyond the simplest Euclidean
concepts *requires* 3 dimensions for thorough investigation, or where the
enhancement of intuition is a goal.

The visualization of the projective geometry of the plane requires the
facility for the visualization of the projection from plane to plane. Well
accomplished in 3d space.

In the exploration of the geometry of the complex plane, the visualization
of the projection to the unit sphere adds an important dimension. The 3rd
dimension.

   The Python Programming Language
   ---------------------------------------

The choice of Python as the implementation language for PyGeo goes well
beyond the fact of my own comfort with it as a development language. The
choice is in fact quite integral to PyGeo's educational purpose and design.
Python code is often referred to as "executable pseudo-code". This helps
bring some unique characteristics to PyGeo as tool for the study of
geometric concepts.

Because of the level of programming abstraction provided by Python and the
accessibility to its code as readable text, the analytics driving the
rendering of the synthetic, visual geometry is highly exposed. One can
explore the analytics at work. The abstract becomes much less abstract, and
the two classical approaches to the study of geometry can and should become,
much more coherently, one.

PyGeo, as open source Python, should be readily extensibleby by anyone
inclined
toward the effort. Extend the functionality, create new primitives and
interfaces for study of specialized geometric areas. In this sense PyGeo is
not an application, as such. It hopes to be a laboratory and a framework,
the beginning of a structure for imaginative
exploration.

And play.

And, hopefully, some worthwhile fun.

Site for download
=================

http://home.netcom.com/~ajs

License:
========
GPL

Documentation:
==============
The release includes source code (of course) and numerous demos, but the
user documentation is still in progress - thank you reStructuredText.


Feedback
========
mailto:aj...@ix...

Re: [Visualpython-users] controlling zooming

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

I don't really understand what you're trying to achieve, and the display is
very far away after autoscaling and therefore requires huge zooming to see
anything, so I may miss the mark in trying to respond to your questions. I'm
guessing though that what you're looking for is scene.fov. From the Visual
reference manual:

Field of view of the camera in radians. This is defined as the maximum of
the horizontal and vertical fields of view. You can think of it as the
angular size of an object of size range, or as the angular size of the
longer axis of the window as seen by the user. Default pi/3.0 radians (60
degrees).

Bruce Sherwood

----- Original Message -----
From: "jon schull" <js...@so...>
To: <vis...@li...>
Sent: Thursday, January 02, 2003 8:43 PM
Subject: RE: [Visualpython-users] controlling zooming


> Thanks for your help!
>
> Attached is the kind of image I'm working on (its the decimal system
> visualized).
>
> Is there a way of adjusting the foreshortening?  When I zoom closer to the
> nearest point (the 0) it disappears (perhaps I'm too close to the camera).
> I'd like to see more of the single-digit integers and be able to see
detail
> a few orders of magnitude further.
>
> I think if I could have the camera "way back"  but telescope in to the
> object of interest, the foreshortening would be reduced..?

RE: [Visualpython-users] controlling zooming

[jon s. <js...@so...>]

Thanks for your help!

Attached is the kind of image I'm working on (its the decimal system
visualized).

Is there a way of adjusting the foreshortening?  When I zoom closer to the
nearest point (the 0) it disappears (perhaps I'm too close to the camera).
I'd like to see more of the single-digit integers and be able to see detail
a few orders of magnitude further.

I think if I could have the camera "way back"  but telescope in to the
object of interest, the foreshortening would be reduced..?


------------------------------------------
Jonathan Schull, Ph.D.
Sc...@Di... <mailto:Sc...@Di...>
http://radio.weblogs.com/0104369/stories/2002/09/24/JonathanSchullOnOnePage.
html
<http://radio.weblogs.com/0104369/stories/2002/09/24/JonathanSchullOnOnePage
.html>
36 Brunswick St., Rochester NY 14607
585-738-6696 cell and v-mail
585-242-9497 landline
978-246-0487 fax
------------------------------------------



> -----Original Message-----
> From: vis...@li...
> [mailto:vis...@li...]On Behalf Of
> Bruce Sherwood
> Sent: Wednesday, January 01, 2003 8:20 PM
> To: vis...@li...
> Subject: Re: [Visualpython-users] controlling zooming
>
>
> Jon Schull is correct; there is something wrong with autoscaling when
> scene.forward is not along z. Thanks for reporting this. The autoscaling
> seems to be based on the view seen with the default scene.forward rather
> than the actual scene.forward.
>
> The other problem he reported, "When I fiddle with scene.range, the image
> gets dim as if the lights have been turned down," was basically due to the
> fact that the blocks lie along the z axis and so only the single
> front face
> is directly illuminated. The color problem was compounded by setting RGB
> values to a maximum of 255 rather than 1, which gives strange results. The
> version of the program below resets the RGB values to be within the valid
> parameter range. One might also change the direction of the
> lighting so that
> the side faces of the blocks are directly illuminated. (When running the
> program, click to advance.)
>
> from visual import *
>
> ##"jon schull" <js...@so...>
> ##This program builds blocks out into space correctly, but it
> automatically
> ##"zooms" way out (too far out) about midway through.
>
> c=[]
> def init():
>     for i in range(10):
>         c.append((0,0,0))
>
>     c[0]=[255,255,255]
>     c[1]=[255,153,51]
>     c[2]=[102,102,153]
>     c[3]=[255,0,102]
>     c[4]=[102,102,153]
>     c[5]=[255,102,0]
>     c[6]=[128,0,128]
>     c[7]=[255,255,0]
>     c[8]=[51,51,153]
>     c[9]=[255,0,102]
>
>     for i in range(10):
>         for j in range(3):
>             c[i][j] = c[i][j]/255.0
>
> for each in c:
>     for i in (0,1,2):
>         each[i]=each[i]/255.
> scene.forward=[0.5,-0.5,-1]
> scene.range=10 ## added to avoid the autoscaling problem
>
> init()
>
> def tenblocks(firstblock=0):
>     for i in range(10):
>         b = box(color=c[i],pos=(0,0,-firstblock + 10 -i))
>     scene.mouse.getclick()
>
> def ShowUpTo(Number=50):
>     Tens=Number/10
>     for i in range(Tens):
>         tenblocks(firstblock=i*10)
>
> ShowUpTo(Number=100)
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] controlling zooming

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

Jon Schull is correct; there is something wrong with autoscaling when
scene.forward is not along z. Thanks for reporting this. The autoscaling
seems to be based on the view seen with the default scene.forward rather
than the actual scene.forward.

The other problem he reported, "When I fiddle with scene.range, the image
gets dim as if the lights have been turned down," was basically due to the
fact that the blocks lie along the z axis and so only the single front face
is directly illuminated. The color problem was compounded by setting RGB
values to a maximum of 255 rather than 1, which gives strange results. The
version of the program below resets the RGB values to be within the valid
parameter range. One might also change the direction of the lighting so that
the side faces of the blocks are directly illuminated. (When running the
program, click to advance.)

from visual import *

##"jon schull" <js...@so...>
##This program builds blocks out into space correctly, but it automatically
##"zooms" way out (too far out) about midway through.

c=[]
def init():
    for i in range(10):
        c.append((0,0,0))

    c[0]=[255,255,255]
    c[1]=[255,153,51]
    c[2]=[102,102,153]
    c[3]=[255,0,102]
    c[4]=[102,102,153]
    c[5]=[255,102,0]
    c[6]=[128,0,128]
    c[7]=[255,255,0]
    c[8]=[51,51,153]
    c[9]=[255,0,102]

    for i in range(10):
        for j in range(3):
            c[i][j] = c[i][j]/255.0

for each in c:
    for i in (0,1,2):
        each[i]=each[i]/255.
scene.forward=[0.5,-0.5,-1]
scene.range=10 ## added to avoid the autoscaling problem

init()

def tenblocks(firstblock=0):
    for i in range(10):
        b = box(color=c[i],pos=(0,0,-firstblock + 10 -i))
    scene.mouse.getclick()

def ShowUpTo(Number=50):
    Tens=Number/10
    for i in range(Tens):
        tenblocks(firstblock=i*10)

ShowUpTo(Number=100)

[Visualpython-users] controlling zooming

[jon s. <js...@so...>]

(Happy New Year!)

This program builds blocks out into space correctly, but it automatically
"zooms" way out (too far out) about midway through.

I can't figure out how to control this.

When I fiddle with scene.range, the image gets dim as if the lights have
been turned down.

I'd appreciate any ideas.


from visual import *
from time import sleep

pause=.2

c=[]
def init():
	for i in range(10):
		c.append((0,0,0))

	c[0]=[255,255,255]
	c[1]=[255,153,51]
	c[2]=[102,102,153]
	c[3]=[255,0,102]
	c[4]=[102,102,153]
	c[5]=[255,102,0]
	c[6]=[128,0,128]
	c[7]=[255,255,0]
	c[8]=[51,51,153]
	c[9]=[255,0,102]
	for each in c:
		for i in (0,1,2):
			each[i]=each[i]/255.
	scene.forward=[0.5,-0.5,-1]

init()

def tenblocks(firstblock=0):
	global pause
	for i in range(10):
		box(color=c[i],pos=(0,0,-firstblock + 10 -i))
		print scene.forward
		if pause>0.1:
			pause= pause * 0.99
			sleep(pause)

def ShowUpTo(Number=50):
	Tens=Number/10
	for i in range(Tens):
		tenblocks(firstblock=i*10)

ShowUpTo(Number=100)

[Visualpython-users] Re: Do Vpython have good future? (Bruce Sherwood)

[Bruce P. <bap...@te...>]

At 12:05 PM 12/29/02, you wrote:
>From: "Bruce Sherwood" <bas...@un...>
>To: <vis...@li...>
>Subject: Re: [Visualpython-users] Do Vpython have good future?
>Date: Sun, 29 Dec 2002 10:52:45 -0500
>
>Some context and history may be helpful. The creator of Visual, David
>Scherer, left college early to take advantage of an unusual business
>opportunity. That left Ruth Chabay and me as custodians of the project, but
 >>>> snip <<<<<

Thanks for the history, Bruce. I, for one, think Vpython is great -- I see 
it as an ideal intermediate level graphics language -- not as low level as 
openGL but not so high level as to be useful for only one task. There is, 
of course, a wish list (alpha blending for objects, built-in capability to 
import objects from  3D design packages, ability to record to an mpeg file, 
etc) but overall I find it to be a very useful language -able to accomplish 
a great deal in not much code.

Re: [Visualpython-users] Do Vpython have good future?

[Gary P. <pa...@in...>]

> Some context and history may be helpful. The creator of Visual, David
> Scherer, left college early to take advantage of an unusual business

Thanks for the note, Bruce.

I'm a VPython newbie, and a physicist, not a programmer, and I'm finding
VPython intriguing.  My interest is primarily for demos and simulations.
What programing I do I do in Python, so VPython is potentially perfect.  I
check for submission to this list daily, and I'm sure I'll contribute as I
get to know it better.   I for one appreciate the effort being done.  I've
had a vague understanding that resouce issues have slowed maintenance and
development.  I think think visual fills an important need in python, and I
look forward to its healthy future.

-gary

Re: [Visualpython-users] Do Vpython have good future?

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

Some context and history may be helpful. The creator of Visual, David
Scherer, left college early to take advantage of an unusual business
opportunity. That left Ruth Chabay and me as custodians of the project, but
during the last year and a half or so we were pretty consumed with a major
move from Carnegie Mellon University to North Carolina State University and
were unable to exploit a grant from the National Science Foundation to push
VPython in new and broader directions. Also, our major responsibilities are
not VPython, so any enhancements or maintenance we were able to undertake
were necessarily aimed for the most part at supporting our physics education
work, though much of this work has been of wider benefit. We finally have
our feet on the ground at our new institution and plan to use the NSF grant
resoursces to hire a strong full-time programmer to begin to address wider
interests and needs of current and potential research and educational users.

Also, Scherer has some interesting ideas on a longer-range restructuring of
the Visual module to make it an open-source project in fact as well as in
principle. Scherer's original implementation in C++ got VPython running
amazingly quickly, with excellent capabilities, execution speed, and
stability. However, the code is rather complex, which has meant in practice
that no one other than Scherer has felt competent to make major changes to
the core of Visual. Mind you, no one is preventing anyone from changing
Visual to suit their own needs, since Visual is an open source project
housed at sourceforge.net. But the benefits of open source may not be fully
realizable if the source looks too difficult for newcomers to modify.

Scherer believes that it could be possible to rewrite Visual with a
radically different architecture which would have the goal of making it
feasible for many people to be able to contribute to its further
development, once the new architecture is in place. A related goal is to
make the basic graphics capabilities sufficiently "professional" to attract
the interest and inputs of those people who are very knowledgeable in
computer graphics. No one is currently working on such a new architecture,
but Scherer's vision is important, because if the project were truly
modifable by many people it could more easily and quickly grow or be
customized to address diverse needs and interests. And if it were made
interesting to graphics experts that too would stimulate interesting further
development.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <aj...@ix...>
To: <vis...@li...>
Sent: Sunday, December 29, 2002 8:54 AM
Subject: Re: [Visualpython-users] Do Vpython have good future?


> Good question.
>
> I think VPython is wonderful.  And could have a great future.
>
> If its potential  beyond physics currciulum visualization were actively
> pursued and better considered and promoted.
>
> Unfortunately its seems to have found itself cornered in a situation were
> those who have undertaken responsibility for it have only that one narrow
> interest in it.
>
> Art

----- Original Message -----
From: "zhang xianying" <th...@ya...>
To: <vis...@li...>
Sent: Sunday, December 29, 2002 7:23 AM
Subject: [Visualpython-users] Do Vpython have good future?


> Hello!
>
> I find out this list is very dull.Do Vpython have future?
>
> I hope get your response.
>
> Thanks!
>
> Zhang xianying

Re: [Visualpython-users] Do Vpython have good future?

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

Good question.

I think VPython is wonderful.  And could have a great future.

If its potential  beyond physics currciulum visualization were actively
pursued and better considered and promoted.

Unfortunately its seems to have found itself cornered in a situation were
those who have undertaken responsibility for it have only that one narrow
interest in it.

Art

[Visualpython-users] Do Vpython have good future?

[zhang x. <th...@ya...>]

Hello!

I find out this list is very dull.Do Vpython have future?

I hope get your response.

Thanks!

Zhang xianying



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now