Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

matplotlib-devel

 [matplotlib-devel] Re: Semilogy problem when y range is empty From: John Hunter - 2004-07-12 16:23:35 ```>>>>> "Gregory" == Gregory Lielens writes: Gregory> Hi, I just encounter a problem of robustness when using Gregory> semilogy: when all the y data are the same, I got a Gregory> ZeroDivisionError: SeparableTransformation:eval_scalars Gregory> yin interval is zero; cannot transform Gregory> A classic plot have no problem and draw a flat line with Gregory> conventional y interval (range 0-2 for y=1). Gregory> Minimal example: Gregory> from matplotlib.matlab import all x=arange(10) y=0*x+1 Gregory> plot(x,y) -> ok figure(2) semilogy(x,y) -> error Gregory> I guess the special-casing done for plot was not extended Gregory> to semilog? Hi Gregory, Yes, this is a simple oversight. In the autoscale method of LogLocator, return return self.nonsingular(vmin, vmax) Gregory> On a related matter (and probably far more difficult to Gregory> change), for now if one plot y values having 0 or Gregory> negative elements, one got a math error, while in matlab Gregory> negative values are ignored...would it be possible to Gregory> switch (ideally, optionally with the help of a command or Gregory> option in .matplotlibrc) to matlab behavior? I guess Gregory> doing a max(epsilon, y) on the data which would be Gregory> logarithmically scaled, and not taking into account data Gregory> below a certain value (mindouble?) for computing the y Gregory> range would do it... Yes, this is a much more difficult issue. It used to be more difficult in earlier versions of matplotlib when x and y transforms were handled independently. Now that transforms of x and y happen together in the new transform architecture, it should be possible. A number of users have requested support for plotting arrays with NaN (this might be considered a special case) but this is made a but difficult since python doesn't support nan across platforms and numeric and numarray handle this differently. Not impossible, of course, just difficult. Special casing this for log would be considerably easier. Gregory> Finally, I am planning to submit a new backend (fltkAgg), Gregory> builded on the model of tkagg ang gtkagg but using fltk Gregory> and it's pyfltk bindings...is this of interest? It is Gregory> almost ready, but I had to modify pyfltk so i prefer to Gregory> wait till my modifs are accepted on this side (and also Gregory> want to experiment with a matlab-like interractive zoom, Gregory> is there something similar present in other interractive Gregory> backends?) I plan on redoing the entire navigation scheme in the near future. It will provide * "hand" pan whether than button click. Ie, you select a hand tool and physically move the axis. The axes select menu for multiple axes would probably be replaced by a "apply to all" checkbox. Ie, your navigation would affect one or all of the axes * zoom to rectangle * a view limit stack with forward and back buttons like on a web browser to navigate through previously defined views. When this is done, I plan on making the toolbar an rc param (classic or newfangled or none). So it would be ideal if you implemented a classic toolbar for your backend before a newfangled one, but is not a requirement. As for including new backends in matplotlib. My initial response was definitely! My new response is definitely, with caveats. Maintaining the various backends across operating systems has become a challenge. Eg, 6 backends cross 3 major platforms is 18 combinations, this is compounded by the fact that most of the GUIs we support have different versions in play. That says nothing about developing new features, maintaining the front end, documentation, web page, etc -. Historically, backend developers have implemented the features they want and need and don't expend a lot of effort keeping their backend current with new features, implementing a full feature set, testing across various operating systems, maintaining web documentation for installing and using the backend (in backends.html) and answering mailing list questions specific to your backend. For example, the wx implementer has done very little since the first, admittedly nice, wx implementation. Because I care about distributing a product that works, it usually falls upon me to do it and I don't have any more free time. A more recent example is the submission of the SVG backend, which is also in need of a new maintainer. Todd Miller, who wrote the Tk backend, has been a notable and much welcomed exception. Because you opted to make a *Agg backend, this task is vastly simplified since Agg automatically will implement all the new drawing features for you, ie images, mathtext, fonts and other hard things come for free. But there will still be fltk version, platform and installation issues that arise. If you're willing to make this ongoing commitment, my answer still is definitely! If this looks like too much to you, I'll be happy to include links to it on my site but may not want to make it part of the official distribution. Sound fair? JDH ```
 [matplotlib-devel] RE : Semilogy problem when y range is empty From: Gregory Lielens - 2004-07-13 01:24:07 ```> Hi Gregory, > > Yes, this is a simple oversight. In the autoscale method of > LogLocator, return > > return self.nonsingular(vmin, vmax) Great! I will try this one! Or maybe you have already added it in the CVS? > A number of users have requested > support for plotting arrays with NaN (this might be > considered a special case) but this is made a but difficult > since python doesn't support nan across platforms and numeric > and numarray handle this differently. Not impossible, of > course, just difficult. In fact I though about requesting that also ;-), but it seems indeed related to numarray/Numeric behavior: The utility of this feature in Matplotlib would be highly dependent to the way the array package deal with math errors/NaN: A quick test shows me that numarray warn and put NaN where elements are outside of the math domain when using ufunc on arrays. Numeric produce a ValueError: math domain error, and matlab silently promote real matrices o complex ones when possible, and put NaN when it's not to obtain the result... Well, I personally think the numarray way is the sanest and most usefull...but for now you are right, this will be a nightmare to deal with, at least if there is no way to make Numeric behaves like Numarray.... On the other hand, Numeric should be replaced in the future by numarray, but I guess the problem is: it will probably not be the near future...:-( Regarding NaN python support across platform, do you know across on which platform it is not supported? "Exotic" ones? This is of particular interest to me (and my company), as a platform which does not support NaN within python would probably be very annoying for porting our softs, and our targets are commercial flavor of unix, linux and win32...I hope the problem arise only on non IEEE754 compliant platforms? > Special casing this for log would be > considerably easier. Yes, probably a y->max(DBL_EPSILON,y), and modifying the autoscale method to avoid "extreme" values when computing the bounding box of the figure... > I plan on redoing the entire navigation scheme in the near > future. It will provide > > * "hand" pan whether than button click. Ie, you select a hand tool > and physically move the axis. The axes select menu for multiple > axes would probably be replaced by a "apply to all" checkbox. Ie, > your navigation would affect one or all of the axes > > * zoom to rectangle > > * a view limit stack with forward and back buttons like on a web > browser to navigate through previously defined views. > > When this is done, I plan on making the toolbar an rc param > (classic or newfangled or none). Great ideas, I though about something like these too, but didn't though about the stack with forward and backward button :-) I would keep the axis per axis selection with select all and invert all, though, this offer better flexibility :-) Other possibilities that crossed my mind are a zoom out mirroring the zoom in to rectangle: the zoom out would be so that the current figure would fit in the rectangle selected by the user...this is the exact reverse of zoom to rectangle, but need some test to see if it is intuitive to use... And also a single click zoom in/zoom out (by a factor of 1.5 or tunable for example, centered on the mouse (either click + [+] or [-] to zoom in/ zoom out, or wheelmouse zooming in/out relative to the current position of the pointer)...I'll wait your prototype in a backend before implementing those then, so that I can see which ideas get retained :-) , So it would be ideal if you > implemented a classic toolbar for your backend before a > newfangled one, but is not a requirement. This is done already, I tried to reproduce as well as possible the TkAgg backend...(a nice way to say the FltkAgg is a complete shamefull ripoff of TkAgg...) > Because you opted to make a *Agg backend, this task is vastly > simplified since Agg automatically will implement all the new > drawing features for you, ie images, mathtext, fonts and > other hard things come for free. But there will still be > fltk version, platform and installation issues that arise. > If you're willing to make this ongoing commitment, my answer > still is definitely! If this looks like too much to you, > I'll be happy to include links to it on my site but may not > want to make it part of the official distribution. > > Sound fair? Yes, of course, completely, I agree this is an issue...Maintenance should be limited because fltk/pyfltk is quite a simple toolkit, and not a very fast moving target (for the best and the worst ;-) ), and anyway as you said it is a quite simple stuff cause once the basic method for introducing Agg in-memory image into an Ftlk widget, the rest is quite simple widget programing (I have done that in order to learn about fltk, and because it was fun :-) ) As my backend is quite similar to the TkAgg one, I am quite confident I would be able to mirror the changes of TkAgg quite easily...but it is nonetheless an effort, especially for documentation...I will discuss that with other guys in the company, this will depends if we decide to use matplotlib in some utilities from now on...The platform we use are commercial unixes, linux and windows, and these last 2 are an absolute requirement so porting and test will be done anyway for those. OS X, well, we don't have any for now but it could change... In the meantime, I would like to submit some patches to the Agg backend, something I have done to avoid the string copy and re-allocation of the Agg buffer each time one draw (basically, expose the image buffer as a python buffer object, and reallocate a new Agg renderer only if h,w or dpi change, just erase it on draw when those stay constants...I guess this could improve the TkAgg and GtkAgg backends too, I need to check if I can change those easily to use the buffer...Does these changes/additions to the Agg renderer seems OK to you? If yes, adding the fltk backend will be trivial for any user having fltk/pyfltk installed...How do you prefer patches, as diff? Or complete modified file? Best regards, Greg. PS: Sorry if the message is not send to matplotlib-devel list, it seems my mails are rejected by the sourceforge server...Do you have added some restriction to the devel list? If not, maybe I have beend blacklisted, I should check if I am not relaying spam...:-( ```