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_ )
2) 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 (5*km + 4*sec). 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
At 11:13 AM 11/2/2007, John Hunter wrote:
On 11/2/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> 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+2*days, date0+3*days]
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 "<ipython console>", 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
-------------------------------------------------------------------------
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
