units

Development matplotlib-devel
1

Now I am not so sure that the use of lists in errorbar is a fossil,
but

I certainly don’t understand it. Would you give a summary of
when one

can and cannot use arrays in axes.py, please? The errorbar and
bar

methods seem to be the only victims of this restriction, and it
looks

like some of the instances are accomplishing nothing–the arguments
get

converted to arrays with the next method call anyway. I
haven’t tried

to trace things carefully, obviously.

I just wrote some related stuff in the other thread, but will jump
in

here. I think I may be being overzealous in my avoidance of
arrays. What

we cannot assume is that asarray is creating an array of floats, so
we

cannot do scalar array operations, eg 2*x. But we should be able
to

assume object arrays, with indexing, and element wise opertations

which are well defined, eg for the canonical date example.

In [3]: import datetime

In [4]: date0 = datetime.date(2004,1,1)

In [5]: days = datetime.timedelta(days=1)

In [6]: d = [date0, date0+days, date0+2days, date0+3days]

In [7]: import numpy as n

In [8]: x1 = n.array(d)

In [9]: xerr = n.array([days]*len(x1))

In [10]: x1.dtype

Out[10]: dtype(‘object’)

In [11]: x2.dtype

Traceback (most recent call last):

File “”, line 1, in ?

NameError: name ‘x2’ is not defined

In [12]: xerr.dtype

Out[12]: dtype(‘object’)

In [13]: x1 + xerr

Out[13]: array([2004-01-02, 2004-01-03, 2004-01-04, 2004-01-05],
dtype=object)

The reason we are bumping into so may problems with errorbar is not

only because it is complex, but because it is doing more arithmetic

than other plotting code.

Ted, can you clarify what kinds of operations are permitted with
your

iterable unit objects if they are initialized into numpy object

arrays?

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


https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
John,

Sorry about the late replay - I’ve been out sick.

I don’t mean to turn this around on you but it might be best if we could
define what mathematical operations MPL requires from a type. Our
types support all “reasonable” math ops. The examples of
things that have caused problems in the past are things like
this:

  1. Converting to array and assuming the input is float (this happened in
    the last step patch that was submitted). I.e. something like this
    (from memory):

my_y = npy.asarray( y, npy.float_ )

  1. Assuming numeric properties for dates. For example, if you want
    a midpoint of 2 x values, someone might write this:

xmid = 0.5 * ( x1 + x2 )

But you can’t add 2 dates together so this won’t work when using dates
for x. You could do this:

xmid = x1 + 0.5 * ( x2 - x1 )

Off the top of my head, the operations that our “extended
types” don’t support are:

  1. Mixing units (5km + 4sec). But this throws an exception so I
    don’t think it’s problem that MPL has to deal with.

  2. Passing extended types to other routines that expect floats (like the
    math library trig functions). However, python XXX math ops like
    abs and nonzero are supported where appropriated (numbers with
    units have abs but dates don’t).

  3. Some math operations on times (epoch in our terminology). The
    valid operations for epochs and durations are:

epoch <,>,== epoch (i.e. cmp )

duration <,>,== duration (i.e. cmp )

epoch = duration + epoch

epoch = epoch - duration

duration = epoch - epoch

duration = duration + duration

duration = duration - duration

duration = float * duration

duration = duration / float

float = duration / duration

duration = abs( duration )

duration.nonzero

I would expect these rules to hold true for python date/time objects as
well. The noteworthy operations that are NOT permitted
are:

epoch + epoch

float * epoch

epoch / float

···

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

At 11:13 AM 11/2/2007, John Hunter wrote: