On 11/2/07, Eric Firing <[EMAIL PROTECTED]> 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.
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 ------------------------------------------------------------------------- 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
