Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Eric Firing <efiring@ha...>  20071102 18:33:41

John, 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 nothingthe arguments get converted to arrays with the next method call anyway. I haven't tried to trace things carefully, obviously. Eric 
From: John Hunter <jdh2358@gm...>  20071102 19:13:08

On 11/2/07, Eric Firing <efiring@...> 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 nothingthe 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([20040102, 20040103, 20040104, 20040105], 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? 
From: Ted Drain <ted.drain@jp...>  20071105 20:36:27
Attachments:
Message as HTML

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 <efiring@...> 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 nothingthe 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([20040102, 20040103, 20040104, 20040105], 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/ >_______________________________________________ >Matplotlibdevel mailing list >Matplotlibdevel@... >https://lists.sourceforge.net/lists/listinfo/matplotlibdevel 
Sign up for the SourceForge newsletter:
No, thanks