From: Kuzminski, S. R <SKu...@fa...> - 2004-01-21 13:05:38
|
I'm working on a commercial product that produces publication quality plots from data contained in Numeric arrays. I also concluded that Chaco was a bit more involved than I needed. My question is what requirements are not met by the other available plotting packages such as.. http://matplotlib.sourceforge.net/=20 These don't have every bell and whistle ( esp. when it comes to the interactive 'properties' dialog ) but as you point out there is a dark side to those features.=20 There are a number of quite capable plotting packages for Python, diversity is good up to a point, but this space ( Plotting packages ) seems ripe for a shakeout. =20 Stefan -----Original Message----- From: num...@li... [mailto:num...@li...] On Behalf Of Perry Greenfield Sent: Tuesday, January 20, 2004 7:02 PM To: Chris Barker Cc: num...@li... Subject: Re: [Numpy-discussion] Status of Numeric (and plotting in particular) On Tuesday, January 20, 2004, at 06:08 PM, Chris Barker wrote: >> Perry Greenfield writes: > >> > It has been our intention to port scipy to use numarray soon. This >> > work has been delayed somewhat since our current focus is on >> > plotting. > > That is good news. What plotting package are you working on? Last I=20 > heard Chaco had turned into Enthought's (and STSci) in-house Windows=20 > only package. (Not because they want it that way, but because they=20 > don't have funding to make it work on other platforms, and support the > broader community). > > I don't see anything new on the SciPy page after August '03. > > Frankly, weak plotting is a bigger deal to me than array performance. > Yes, I agree completely (and why we are giving plotting higher priority=20 than scipy integration). I really was hoping to raise this issue later, but I might as well=20 address it since the Numeric/numarray issue has raised it indirectly. Chaco had been the focus of our plotting efforts for more than a year.=20 The effort started with our funding Enthought to start the effort. We had a number=20 of requirements for a plotting package that weren't met by any existing package, and it=20 didn't appear that any would be easily modified to our needs. The requirements we had=20 (off the top of my head) included: 1) easy portability to graphics devices *and* different windowing=20 systems. 2) it had to run on all major platforms including Solaris, Linux, Macs,=20 and Windows. 3) the graphics had to be embedable within gui widgets. 4) it had to allow cursor interactions, at least to the point of being=20 able to read cursor positions from python. 5) it had to be open source and preferably not gpl (though the latter=20 was probably not a show stopper for us) 6) It also had to be customizable to the point of being able to produce=20 very high quality hardcopy plots suitable for publication. 7) object oriented plotting framework capable of sensible composition. 8) command line interface akin to that available in matlab or IDL to=20 make producing quick interactive plots very, very easy. Developing something that satisfies these is not at all trivial. In the process Enthought has expended much energy developing chaco,=20 kiva and traits (and lately they are working on yet more extensions); easily much more=20 of the effort has come from sources other than STScI. Kiva is the back end that=20 presents a uniform api for different graphics devices. Traits handles many of the user=20 interface issues for plot parameters, and handling the relationships of these parameters=20 between plot components. Chaco is the higher level plotting software that=20 provides the traditional plotting capabilities for 2-d data. Much has been invested in chaco. It is with some regret that we (STScI) have concluded that chaco is not=20 suitable for our needs and that we need to take a different approach (or at least=20 give it a try). I'll take some space to explain why. The short answer is that in the end we think it was too ambitious. We=20 still aim to achieve the goals I listed above. The problem we think is that chaco=20 was also tasked to try to achieve extra goals with regard interactive=20 capabilities that were in the end, not really important to STScI and it's community, but=20 were important to Enthought (and presumably its clients, and the scipy=20 community). More specifically, a lot of thought and work went into making many=20 aspects of the plots could be interactively modified. That is, by clicking on various=20 aspects of plots, one could bring up editors for the attributes of that plot=20 element, such as color, line style, font, size, etc. Many other interactive=20 aspects have been enhanced as well. Much recent work by Enthought is going into=20 extending the capabilities even further by adding gui kinds of features (e.g.,=20 widgets of all sorts). Unfortunately these capabilities have come at a price, namely=20 complexity. We have found it difficult to track the ongoing changes to chaco to become=20 proficient enough to contribute significantly by adding capabilities we have=20 needed. Perhaps that argues that we aren't competent to do so. To a certain=20 degree, that is probably is true. There is no doubt that Enthought has some=20 very talented software engineers working on chaco and related products. On the other=20 hand, our goal is to have this software be accessible by scientists in=20 general, and particularly astronomers. Chaco is complex enough that we think that is=20 a serious problem. Customizing it's behavior requires a very large=20 investment of time understanding how it works, far beyond what most astronomers are=20 willing to tackle (at least that's my impression). Much of this complexity (and many of its ongoing changes) is to support=20 the interactive capabilities, and to make it responsive enough that plots=20 can update themselves quickly enough not to lead to annoying lags. But=20 frankly, we just want something to render plots on the screen and on hardcopy.=20 Outside of being able to obtain cursor coordinates, we find many of the=20 interactive capabilities as secondary in importance. When most astronomers want to=20 tune a plot (either for publication quality, or for batch processing), they=20 usually want to be able to reproduce the adjustments for new data, for which=20 the interactive attribute editing capability is of little use. Generally they would=20 like to script the the more customized plots so that they can be easily=20 modified and reused. So it seems that it is too difficult to accomplish all these aims=20 within one package. We would like to develop a different plotting package (using=20 many of ideas from chaco, and some code) based on kiva and the traits package. We have started on this over the past month, and hope to have some=20 simple functionality available within a month (though when we make it public=20 may take a bit longer). It will be open source and we hope significantly=20 simpler than chaco. It will not focus on speed (well, we want fairly fast=20 display times for plots of a reasonable number of points, but we don't need video=20 refresh rates). If your interest in plotting matches ours, then this may be for=20 you. We will welcome contributions and comments once we get it off the=20 ground. (We are calling it pyxis by the way). Enthought is continuing to work on chaco and at some point that will be=20 mature, and will be capable of some sophisticated things. That may be more=20 appropriate for some than what we are working on. Perry Greenfield ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Numpy-discussion mailing list Num...@li... https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
From: Jon P. <jw...@ps...> - 2004-01-21 19:09:42
|
> > >We have started on this over the past month, and hope to have some >simple >functionality available within a month (though when we make it public >may >take a bit longer). It will be open source and we hope significantly >simpler >than chaco. It will not focus on speed (well, we want fairly fast >display times >for plots of a reasonable number of points, but we don't need video >refresh >rates). If your interest in plotting matches ours, then this may be for >you. >We will welcome contributions and comments once we get it off the >ground. >(We are calling it pyxis by the way). > I agree with the sentiment that chaco is a very heavy and confusing package for the average scientist (but maybe great for the full-time programmer) but I'm really concerned about the idea that we need *another* solution started from scratch. There are already so many including scipy.gplt, scipy.plt, dislin, biggles, pychart, piddle, pgplot, pyx (new)... In particular MatPlotLib looks promising - check out its examples: http://matplotlib.sourceforge.net/screenshots.html *Many* plotting types already , simple syntax, a few different backends. And already has something of a following. So is it really not possible for STScI to push its resources into aiding the development of something that's already begun? Would be great if we could develop a single package really well rather than everyone making their own. -- Jon Peirce Nottingham University +44 (0)115 8467176 (tel) +44 (0)115 9515324 (fax) http://www.psychology.nottingham.ac.uk/staff/jwp/ |
From: Perry G. <pe...@st...> - 2004-01-21 20:06:25
|
Jon Peirce writes: > > I agree with the sentiment that chaco is a very heavy and confusing > package for the average scientist (but maybe great for the full-time > programmer) but I'm really concerned about the idea that we need > *another* solution started from scratch. There are already so many > including scipy.gplt, scipy.plt, dislin, biggles, pychart, piddle, > pgplot, pyx (new)... > We had looked all of these and each had fallen short in some major way (though I thought piddle had much promise and perhaps could be built on; however it was intended as a back end only.) > In particular MatPlotLib looks promising - check out its examples: > http://matplotlib.sourceforge.net/screenshots.html > *Many* plotting types already , simple syntax, a few different backends. > And already has something of a following. > This we had not seen. A superficial look indicates that it is worth investigating further as a basis for a plotting package. I didn't see any major problem with it that contradicted our requirements, but obviously we will have to look at it in more depth to see if that is the case. It doesn't have to be perfect of course. And it is much more expensive tto start from scratch (though we weren't doing that entirely since a number of components from the chaco effort would have been reused). But this is worth seriously considering. Perry Greenfield > So is it really not possible for STScI to push its resources into aiding > the development of something that's already begun? Would be great if we > could develop a single package really well rather than everyone making > their own. > |
From: Magnus L. H. <ma...@he...> - 2004-01-21 20:52:57
|
Perry Greenfield <pe...@st...>: > > Jon Peirce writes: > > > > I agree with the sentiment that chaco is a very heavy and confusing > > package for the average scientist (but maybe great for the full-time > > programmer) but I'm really concerned about the idea that we need > > *another* solution started from scratch. There are already so many > > including scipy.gplt, scipy.plt, dislin, biggles, pychart, piddle, > > pgplot, pyx (new)... > > > We had looked all of these and each had fallen short in some major > way (though I thought piddle had much promise and perhaps could be > built on; however it was intended as a back end only.) Wohoo! Piddle lives ;) I think I'd be interested in resuming some of my earlier work on Piddle if it is ever used for something useful -- such as a proper plotting tool. (I was actually just thinking about wrapping PyX in the Piddle interface to make TeX typesetting available in Piddle.) [snip about mathplotlib] Hm. Maybe a Piddle back-end could be written for it (which would instantly give it lots of extra back-ends)...? Two birds with one stone and all that... - M -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |