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

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