There seems to be some confusion as to how the mpl unit system works, I hope
the following will help to clarify that and keep this
thread focused on the issue.
Currently mpl provides an API via the 'ConversionInterface' class in
'matplotlb.units' that allows a user to define how to translate
th
On Thu, May 21, 2009 at 2:20 PM, Christopher Barker
wrote:
> John Hunter wrote:
>> wrote:
>>> If it's going to be done, I think it really shouldn't be too MPL
>>> specific -- it should be built on a good (and hopefully eventually
>>> widely used) unit-array system, perhaps like Darren Dale's Quan
On 2009-05-21 14:55, Pierre GM wrote:
> Anyway, the zoom-level dependent ticks we implemented might be a good
> starting point for implementing a "locator/formatter that decides
> whether to display cm or km"...
Well, if we're pushing products, Chaco has a subsystem for doing exactly this
in
a g
Er... Anybody has tried the plotting capacities of scikits.timeseries
(pytseries.sourceforge.net)? In short, the package provides some
extensions to matplotlib to plot timeseries. One of these extensions
changes the ticks depending on the zoom level: start over a few
decades and ticks will
John Hunter wrote:
> wrote:
>> If it's going to be done, I think it really shouldn't be too MPL
>> specific -- it should be built on a good (and hopefully eventually
>> widely used) unit-array system, perhaps like Darren Dale's Quantities
>> package (there are quite a few other that should be look
On Wed, May 20, 2009 at 2:11 PM, Ryan May wrote:
>
>
> On Wed, May 20, 2009 at 1:10 PM, Christopher Barker > wrote:
>
>> > Darren Dale was working on a full-fledged package for adding units to
>> > numpy arrays called quantities
>> > (http://packages.python.org/quantities/user/tutorial.html),
>>
On Wed, May 20, 2009 at 1:01 PM, Ryan May wrote:
> On Wed, May 20, 2009 at 11:54 AM, Christopher Barker <
> chris.bar...@noaa.gov> wrote:
>
>> Ryan May wrote:
>> > use the units in basic_units.py (in the examples/units directory).
>>
>> This looks like pretty cool stuff. However, I can't seem to
On Wed, May 20, 2009 at 4:02 PM, Christopher Barker
wrote:
> John Hunter wrote:
>> The use case (and we can debate whether this is worth the extra overhead)
>>
>> ax.plot(inches)
>> ax.set_xlim(cms)
>
> I'll put my two cents into that debate:
>
> My first thought is: wow! that is putting WAY t
John Hunter wrote:
> The use case (and we can debate whether this is worth the extra overhead)
>
> ax.plot(inches)
> ax.set_xlim(cms)
I'll put my two cents into that debate:
My first thought is: wow! that is putting WAY too much into a plotting
routine!
My second thought is: on the other h
On Wed, May 20, 2009 at 2:36 PM, Eric Firing wrote:
> I'm not sure I understand the use case for unit *changes*, as opposed to
> initial unit specification.
The use case (and we can debate whether this is worth the extra overhead)
ax.plot(inches)
ax.set_xlim(cms)
And the plot will automagi
John Hunter wrote:
> The fundamental problem here is that some artists (Line2D) have
> support for storing original unitized data (_xorig, _yorig) and
> handling the conversion on unit change internally with the callback,
> and some artists (eg Patches) do not . axes._process_plot_var_arg
> sub
On Wed, May 20, 2009 at 1:10 PM, Christopher Barker
wrote:
> > Darren Dale was working on a full-fledged package for adding units to
> > numpy arrays called quantities
> > (http://packages.python.org/quantities/user/tutorial.html),
>
> thanks for the reminder -- that does look like a really nice p
Ryan May wrote:
> It's another one of those modules
> whose docs hasn't been converted to sphinx yet, but it does have doc
> strings.
Couldn't/shouldn't sphinx just use the docs strings so that there is
SOMETHING there? I really love the sphinx docs, but it is frustrating
got have a module sim
On Wed, May 20, 2009 at 11:55 AM, Ryan May wrote:
> On Wed, May 20, 2009 at 11:38 AM, Ryan May wrote:
>>
>> Hi,
>>
>> In looking over a test failure, I'm seeing some behavior that doesn't make
>> sense to me. It looks like data passed to a line object is being improperly
>> converted when units
On Wed, May 20, 2009 at 11:54 AM, Christopher Barker
wrote:
> Ryan May wrote:
> > use the units in basic_units.py (in the examples/units directory).
>
> This looks like pretty cool stuff. However, I can't seem to find
> matplotlib.units or basic_units.py in the online Sphinx docs. Is this a
> doc
On Wed, May 20, 2009 at 11:38 AM, Ryan May wrote:
> Hi,
>
> In looking over a test failure, I'm seeing some behavior that doesn't make
> sense to me. It looks like data passed to a line object is being improperly
> converted when units are involved. Here's a version of the code in the test
> scr
Ryan May wrote:
> use the units in basic_units.py (in the examples/units directory).
This looks like pretty cool stuff. However, I can't seem to find
matplotlib.units or basic_units.py in the online Sphinx docs. Is this a
doc bug, or intentional?
There are units examples in the docs.
-Chris
Hi,
In looking over a test failure, I'm seeing some behavior that doesn't make
sense to me. It looks like data passed to a line object is being improperly
converted when units are involved. Here's a version of the code in the test
script, but modified to use the units in basic_units.py (in the
ex
John Hunter wrote:
[...]
>
> The code is trying to add a non-unitized quantity (eg an errorbar
> width but just guessing) of int type with a unitized quantity
> TaggedValue (this is from the mockup basic_units testing package).
> You'd have to dig a little bit to find out where the non-unitized
>
John Hunter wrote:
> The code is trying to add a non-unitized quantity (eg an errorbar
> width but just guessing) of int type with a unitized quantity
> TaggedValue (this is from the mockup basic_units testing package).
> You'd have to dig a little bit to find out where the non-unitized
> quantity
On Fri, Jan 16, 2009 at 2:02 PM, Ryan May wrote:
> Hi,
>
> In fixing the recursion bug in the units support, I went through the examples
> in
> units/ and found two broken examples (broken before I fixed the recursion
> bug):
>
> 1) artist_tests.py
> Traceback (most recent call last):
> File "a
Hi,
In fixing the recursion bug in the units support, I went through the examples in
units/ and found two broken examples (broken before I fixed the recursion bug):
1) artist_tests.py
Traceback (most recent call last):
File "artist_tests.py", line 30, in
lc = collections.LineCollection(ver
On Mon, Jul 21, 2008 at 04:42:39PM -0700, Ted Drain wrote:
> The public layer would just do conversions and then pass through to the
> private layer. Any code in the public layer would have to concern itself
> with possible different types (numpy vs lists, units vs floats, color names
> vs rgb).
Sent: Monday, July 21, 2008 3:40 PM
> To: Michael Droettboom
> Cc: matplotlib development list; Eric Firing
> Subject: Re: [matplotlib-devel] units support
>
> On Mon, Jul 21, 2008 at 5:25 PM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
> > I'll second be
On Mon, Jul 21, 2008 at 5:25 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I'll second being confused at times. In the transformation conversion, it
> was something I didn't know too much about up front, so it's quite possible
> that I broke some things in that regard. (I know of some alrea
I'll second being confused at times. In the transformation conversion,
it was something I didn't know too much about up front, so it's quite
possible that I broke some things in that regard. (I know of some
already, but those were fixed shortly after things were merged into the
trunk around 0
John,
I am still struggling to understand exactly how units support works, and
what is needed to make it work everywhere that it should. I see that it
works in plot, for example; it is not even necessary to use plot_date.
It does not work in scatter, and at first I thought that was because of
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
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
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 so
On 3/21/07, John Hunter <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
>
> > And yes, properties are actually OK even with 2.2, so there's no
> > reason to avoid them (and they do provide a nicer, claner user API).
> > Decorators are 2.4-only though.
>
> I'm not
On 3/21/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
> And yes, properties are actually OK even with 2.2, so there's no
> reason to avoid them (and they do provide a nicer, claner user API).
> Decorators are 2.4-only though.
I'm not opposed to properties in principle -- I just didn't want to
sta
Fernando Perez wrote:
> On 3/21/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>
>> Properties would be OK for 2.3; I was thinking we might want to use
>> them. When a getter and setter already exist, all it takes is the one
>> extra line of code, plus a suitable (unused) name for the property. I
>>
On 3/21/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> Properties would be OK for 2.3; I was thinking we might want to use
> them. When a getter and setter already exist, all it takes is the one
> extra line of code, plus a suitable (unused) name for the property. I
> decided not to pursue traits
>
> And I've gotten the units.py module down to a digestable 105 lines of
> code!
You must have done more work after writing your message--now wc reports
only 87 lines!
Thanks for all the explanations (I am gradually coming around...) and
additional work.
Minor points from a quick look at axe
On 3/20/07, Norbert Nemec <[EMAIL PROTECTED]> wrote:
> I agree, though, that the units package itself should not be part of
> matplotlib. But this is exactly
> how I understand the idea by John Hunter: describe an interface to allow
> the use of any third-party
> unit package.
That's exactly righ
FYI The unit system John is working on will be a huge improvement for
the way we use MPL. Our users do a ton of plotting that involves
unitized numbers vs time. We have our own unit class and time class
and right now users have to convert the unitized numbers into floats
in the correct units
Actually, I like the idea of unit support quite a bit and could well
imagine that it makes sense
to support it explicitely in matplotlib.
I am using physical units very frequently in my computations. Lacking a
robust units package,
I simply define the units as numerical constants without checks
On Tuesday 20 March 2007 3:50:07 am Eric Firing wrote:
> John Hunter wrote:
> > If you are using mpl svn, please read this as it describes
> > some fairly major changes.
> >
> > Mike Lusignan has been working on adding units support, and as a
> > consequence, partial support for working with arbitr
John Hunter wrote:
> If you are using mpl svn, please read this as it describes
> some fairly major changes.
>
> Mike Lusignan has been working on adding units support, and as a
> consequence, partial support for working with arbitrary types in mpl.
> The support is not complete yet, but it is bas
40 matches
Mail list logo
