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

[John H. <jdh...@ac...>]

>>>>> "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