[MATRIX-SIG] [long] A NO-Proposal for a plot-package

[Geoffrey Furnish]

David Ascher writes:
 > On Mon, 21 Jul 1997, Geoffrey Furnish wrote:
 > 
 > > 1) What is the name of the proposed new sig.  Is it plot-sig, or
 > >    sci-sig.  This obviously impacts the sig charter and expected usage
 > >    significantly.
 > 
 > Ok, let's play it safe.  As per the SIG creation guidelines, we need a SIG
 > name, short description, and longer blurb.  Here's a first draft, please
 > critique it.

I basically like this proposal.

 > PLOT-SIG: Investigating and Developing Scientific and Business Plotting
 >           Solutions for Python
 > 
 > Short blurb:
 > 
 >    The purpose of this list is to develop, coddle together, adopt or
 >    otherwise make available a package for plotting of scientific and
 >    business plots of data.
                               ^
I would just voice some concern about a charter which specifies a
singular solution.  I say this because I think it is clear that there
are going to be multiple plotting solutions in Python whether they get
the blessing of the plot-sig or not.  I would suggest preserving the
basic idea, but eliminating a proscription for a single solution.
Perhaps wording like:

   The purpose of this list is to develop, coddle together, adopt or
   otherwise make available Python support for plotting of scientific 
   and business data.

 >    Principles guiding the development of the software will include:
 >      * Portability to the relevant platforms
 >      * Ease of use
 >      * Integration with other Python packages (e.g. NumPy)
 >      * Quality of the software
 >      * Quality of the output
 > 
 > ----
 > This is meant to be pretty much independent of existing solutions,
 > although clearly some existing packages will fit more or less well.  I'm
 > concerned that plot-sig will suffer the fate of gui-sig, which was to die
 > of starvation because the job at hand is just too big to start from
 > scratch, so people just keep using what they've been using, and no 'ideal'
 > solution comes to fruition.

I haven't followed gui-sig, so I can't comment on the phenomenology
there.  But I do think it would be useful to avoid a proscriptive
attempt to produce the "One True Python Plotting Package".  Plotting
is clearly going to be an extension, not a language intrinsic.
Multiple solutions are going to be a fact of life.  There are many
reasons for this, not the least of which is that many python users
also use other languages (heresy, I know), and consequently many will
seek multi-language solutions.  A proscriptive attempt to generate a
single, Python-centric plotting package will obviously win many users,
and alienate other potential users.  Conversely, a pluralist solution
will woo many, and disincline others.  There is no "one size fits all,
right answer" to plotting.  Rather, the more realistic expectation is
to develop high quality Python interfaces to the plotting facilities
which are available and of interest.  And it is entirely conceivable
that such efforts can have an influential effect on the targets.

 > I also wanted to add the principle of "object oriented design" to
 > the list above, but didn't know if that would get a consensus.

I dont' think a consensus is necessary.  In my view, a good sig for
something other than a core language extension, should have a
pluralistic charter.  If you want to break programming interfaces down
into two categories, API's and OO interfaces, then Python needs access
to plotting support in both categories.  The need for OO plotting
support is clear--but it will not be used by everyone--some will want
API oriented services too.  The charter for the plot-sig should
accomodate both needs.

 > Regardless, I think it might be a good thing to come up with a list of
 > features each of us need, and rank them in terms of 'must have', 'want',
 > 'would be nice'.  Maybe this should wait until the sig is created, I don't
 > know.
 > 
 > Here's mine (off the top of my head):
 > 
 > MUST HAVE:
 > 	Line Plots
 > 	Point Plots (scatter plots)
 > 	Bar Plots
 > 	Error Bars
 > 	Fills (grey levels)
 > 	Symbols
 > 	Log scales
 > 	Bitmap preview (tk, gif, whatever)
 > 	Text
 > 	Production-quality PostScript output
 > 	Very Customizable
 > 	Works on Unix & NT
 > 
 > WOULD BE NICE:
 > 	Complete Python control over graph generation, graph objects, etc.
 > 	Ability to design new graph formats (e.g. Tufte's work)
 > 	Interactivity
 > 	Ability to do Batch work

It's a good list, but I don't think this kind of stuff needs to be
explicitly enumerated in the sig charter.

 > Here's what I've used in the past (or use now):
 > 	Gnuplot
 > 	GLE
 > 	MetaPost
 > 	[mac GUI tools]
 > 
 > > 2) Who is the owner going to be?  Its not a particularly big job, but
 > >    it should be someone who cares enough to keep things in order if
 > >    need be.  
 > 
 > I guess I just volunteered.

Thanks much.  You should join meta-sig, then post a note proposing the
creation of the new sig, explaining that you have the broad based
support of people in matrix-sig, and providing your charter
statement.  Some discussion will ensue, and eventually they'll make
the new sig, setting you up as the owner.

-- 
Geoffrey Furnish                email: furnish@lanl.gov
LANL CIC-19 POOMA/RadTran       phone: 505-665-4529     fax: 505-665-7880

"Software complexity is an artifact of implementation."    -Dan Quinlan

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

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