[MATRIX-SIG] namespaces, constructors, and global variables

[Phil Austin]

>>>>> "Konrad" == Konrad Hinsen <hinsen@ibs.ibs.fr> writes:

    Konrad> Great! However, I wonder whether a unification of plotting
    Konrad> packages is the right way to go. I think it would be not
    Konrad> much more effort, but much more useful, to write Python
    Konrad> code that generates low-level graphics elements (lines,
    Konrad> circles, etc.) directly to make up a plot. Then there
    Konrad> could be several low-level drivers that render this
    Konrad> representation via Tk canvases, OpenGL, PostScript, or
    Konrad> whatever.

>>>>> "Aaron" == Aaron Watters <arw@dante.mh.lucent.com> writes:

    Aaron> Seconded.  This is the proper way to design it IMHO.  If
    Aaron> you do it carefully I don't even think you'll see any
    Aaron> particular performance problems. --Aaron Watters


Thirded.  I'm operating under some constraints however: 

1) I think I've provided some evidence that, on a coding project like
   this, I'll be staying in the shallow end of the pool.  

2) I need a single interface that will produce simple plots under
   linux and Windows 95 (student labs start Sept. 3), and camera ready
   publication plots under linux and solaris. For the latter I require
   a superset of the capabilities demonstrated at:
   http://ngwww.ucar.edu/ngdoc/ng4.0.1/ug/ncl/tutor/session3.html (For
   people interested in pricing for this package--an unlimited
   use/unlimited-time University site licence cost us about $Can 900
   (there's no windows port).  A typical commercial alternative with a
   fairly primitive array language (IDL/PV-Wave) is $2500 per seat).

3) I need the camera-ready plots within two weeks.

My guess is that someone might eventually write a portable set of
Java/tk/opengl/etc. classes to do much of what I want, and with luck it
will happen before 1999 and could even be GPL'ed.  Near-term is going
to require some improvisation, however.

Konrad adds:

    Konrad> I would not recommend to use *any* global objects unless
    Konrad> you have a very good reason. If I understand your
    Konrad> intention well, it would be impossible to construct two
    Konrad> plots in parallel. Why that restriction? 

and: 

    Konrad> __main__ will clearly be different in the two
    Konrad> situations. And like global variables, accessing __main__
    Konrad> is something that a well-behaved Python program should not
    Konrad> do.


The plot layout is now encapsulated, so no more globals, thanks.  On
the second issue, I was trying to get default behavior that
produces a plot with very few keystrokes, while maintaining the ability to
customize the axis, labels, ticks, etc. after the plot command is typed.
Specifically, I'm looking for three different user levels:

Novice:
_______

BuildPlot(x,y)  #x-y line plot with default axes
                #also creates leftAxis and botAxis--their set methods
                #can be used to modify defaults if desired as in:

Advanced Novice:  change the default axis parameters following the plot command
_______________

BuildPlot(x,y)
leftAxis.set(label="Temperature",font="urdu",fontSize="5pt")



Intermediate to Advanced:
________________________

Here, we want a plot with two ordinates of different colors on the
rhs, offset horizontally from each other by 0.2 units, one a
logrithmic pressure axis with values increasing downward, one a linear
height axis with values increasing upward:

plot1=BuildPlot(temp,pressure,corner=(0,0),size=(2,2),axes="F",log="y")
                                 #no default axes, but plot size and location
                                 #specified, ordinate is logarithmic
leftAxis=BuildAxis(plot1,axis="bot")
rightAxis=BuildAxis(plot1,axis="right",color="red",type="inverted")

#now build another plot of temperature/height, positioned on top of
#plot1, but draw only a new right axis

plot2=BuildPlot(x,z,corner=(0,0),size=(2,2),type="None",axes="F")
rightAxis=BuildAxis(plot2,axis="right",bottom=(2.2,0),color="green")

______________


If default behavior that creates an unasked for leftAxis and a botAxis
in __main__ is risky, then I can just drop the idea that the default
axes can be modified, and move my novices quickly into the
intermediate stage if necessary.

I'd love to see some other approaches that balance this
terseness/flexibility ratio in different ways.


Regards, Phil




_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________