Thread: [matplotlib-devel] Re: Semilogy problem when y range is empty

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> 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
 

> 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...:-(