errorbar *lims kwarg

Development matplotlib-devel
1

The errorbar_limits.py demo is failing on my machine:

Traceback (most recent call last):
  File "errorbar_limits.py", line 13, in <module>
    P.errorbar(x,y,yerr=0.1,capsize=3)
  File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608,
in errorbar
    ret = gca().errorbar(*args, **kwargs)
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3735, in
errorbar
    caplines.extend( self.plot(x, lower, 'k_', **plot_kw) )
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2634, in
plot
    for line in self._get_lines(*args, **kwargs):
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 403, in
_grab_next_args
    for seg in self._plot_3_args(remaining, **kwargs):
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 349, in
_plot_3_args
    x, y, multicol = self._xy_from_xy(x, y)
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 244, in
_xy_from_xy
    assert nrx == nry, 'Dimensions of x and y are incompatible'
AssertionError: Dimensions of x and y are incompatible

It looks like the API has changed and does not allow scalar arguments for the
errors. I tried setting yerr=ones(len(y))*0.1, and got a different error:

Traceback (most recent call last):
  File "errorbar_limits.py", line 18, in <module>
    P.errorbar(x,y,yerr=yerr, uplims=True)
  File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608,
in errorbar
    ret = gca().errorbar(*args, **kwargs)
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3738, in
errorbar
    caplines.extend( self.plot(x[uplims], upper[uplims], ls='None',
marker=mlines.CARETUP, **plot_kw) )
TypeError: only integer arrays with one element can be converted to an index

Maybe the patch commited on September 3 needs to be revisited.

Darren

2

Darren Dale wrote:

The errorbar_limits.py demo is failing on my machine:

Traceback (most recent call last):
  File "errorbar_limits.py", line 13, in <module>
    P.errorbar(x,y,yerr=0.1,capsize=3)
  File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, in errorbar
    ret = gca().errorbar(*args, **kwargs)
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3735, in errorbar
    caplines.extend( self.plot(x, lower, 'k_', **plot_kw) )
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2634, in plot
    for line in self._get_lines(*args, **kwargs):
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 403, in _grab_next_args
    for seg in self._plot_3_args(remaining, **kwargs):
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 349, in _plot_3_args
    x, y, multicol = self._xy_from_xy(x, y)
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 244, in _xy_from_xy
    assert nrx == nry, 'Dimensions of x and y are incompatible'
AssertionError: Dimensions of x and y are incompatible

It looks like the API has changed and does not allow scalar arguments for the errors. I tried setting yerr=ones(len(y))*0.1, and got a different error:

Traceback (most recent call last):
  File "errorbar_limits.py", line 18, in <module>
    P.errorbar(x,y,yerr=yerr, uplims=True)
  File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, in errorbar
    ret = gca().errorbar(*args, **kwargs)
  File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3738, in errorbar
    caplines.extend( self.plot(x[uplims], upper[uplims], ls='None', marker=mlines.CARETUP, **plot_kw) )
TypeError: only integer arrays with one element can be converted to an index

Maybe the patch commited on September 3 needs to be revisited.

I'm not sure that the problem is just in that patch, or in that patch at all--the whole errorbar method needs to be reviewed. (The patch contributes to the extent that it makes the code much more complicated.)

It looks to me like there are several fossils from John's early work with units support--places where list comprehensions are used instead of arrays "to preserve units". I don't think these are directly causing the problem, but if they are indeed fossils they should certainly be corrected.

Eric

···

Darren

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

3

I just fixed this in svn -- the unit support has certainly proven
fragile in the errorbar code, because the inability to assume arrays
is a major handicap, and barring oneself from all the numpyisms like
logical masks and fancy indexing, not to mention the performance that
comes with it, is frustrating.

The unit support code grew out of an attempt to solve a somewhat
important use case: the JPL has unit enabled data structures that are
iterable but do not implement the basic array uses we need.
Apparently, they use these objects with mpl and are unable to wrap
them or modify them because they must also be passed on to other
libraries in their system, which they also do not control, unmodified.
The current mpl implementation, in which users can register their
objects with converter classes, works fine and supports the very nice
ability to pass in datetime objects directly to mpl (this is another
clear use case where you want to work with some object you can't wrap
or modify).

I think it is a bit too onerous inside mpl to not be able to assume we
can do array operations, so I will give this some more thought on how
we can satisfy these use cases w/o writing tedious, fragile code.

JDH

···

On 11/2/07, Eric Firing <efiring@...229...> wrote:

It looks to me like there are several fossils from John's early work
with units support--places where list comprehensions are used instead of
arrays "to preserve units". I don't think these are directly causing
the problem, but if they are indeed fossils they should certainly be
corrected.