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 delete_masked_points, so I changed the latter to make sure that an array of datetime instances would be handled correctly.
Do Collections need something like the recache strategy used by Line2D?
I get very confused as to when and where the convert method needs to be used to change from , e.g., datetime instances to floats. One of the things that happens in scatter is that this conversion is not done somewhere that it is needed, and then a calculation of a pad for the view limits fails.
I get the impression that the conversion is being delayed until the last possible part of the code; it would seem simpler if instead conversion were done very near the front of the code, so that for all subsequent calculations one could rely on having plain numbers to deal with. Of course, that would restrict the use to the higher (user-level) parts of the API, which has some disadvantages.
I know you have thought all this through very carefully, and come up with an implementation that is relatively unobtrusive. Is there a summary anywhere that would make it clear to me how to make scatter, for example, work with dates? Or quiver, or windbarb? (This is motivated not by any immediate personal use case but by a desire to see mpl "just work" with minimal surprises and exceptions.)
Eric
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.98.0). All that is to say that you may want to cross-reference against 0.91.x if things look fishy. But I think you're right, we need some sort of "best practices" guidance for supporting units, and then hopefully just track down all the places where "such-and-such" should be happening and isn't.
Cheers,
Mike
Eric Firing wrote:
···
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 delete_masked_points, so I changed the latter to make sure that an array of datetime instances would be handled correctly.
Do Collections need something like the recache strategy used by Line2D?
I get very confused as to when and where the convert method needs to be used to change from , e.g., datetime instances to floats. One of the things that happens in scatter is that this conversion is not done somewhere that it is needed, and then a calculation of a pad for the view limits fails.
I get the impression that the conversion is being delayed until the last possible part of the code; it would seem simpler if instead conversion were done very near the front of the code, so that for all subsequent calculations one could rely on having plain numbers to deal with. Of course, that would restrict the use to the higher (user-level) parts of the API, which has some disadvantages.
I know you have thought all this through very carefully, and come up with an implementation that is relatively unobtrusive. Is there a summary anywhere that would make it clear to me how to make scatter, for example, work with dates? Or quiver, or windbarb? (This is motivated not by any immediate personal use case but by a desire to see mpl "just work" with minimal surprises and exceptions.)
Eric
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
I'll work on putting together a document for the developer's guide --
how to support units in a plotting function and artist. Supporting
the units interface everywhere would definitely add to the memory
footprint of mpl and would slow it down, in addition to increasing the
coding burden. On the other hand, they are quite useful in some
cases, most notably for me working with native datetimes and hopefully
down the road a numpy datetime extension. Once I get the guide
written and provide some clarity on the interface, we can decide in
which functions it makes the most sense from a performance usability
perspective and clean those first. Perhaps there are additional
abstractions that can ease the coding burden, eg encapsulating all the
mask/unit/what-have-you logic into a single entity such as a location
array which supports a minimum set of operations.
JDH
JDH
···
On Mon, Jul 21, 2008 at 5:25 PM, Michael Droettboom <mdroe@...31...> 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 already, but those
were fixed shortly after things were merged into the trunk around 0.98.0).
All that is to say that you may want to cross-reference against 0.91.x if
things look fishy. But I think you're right, we need some sort of "best
practices" guidance for supporting units, and then hopefully just track down
all the places where "such-and-such" should be happening and isn't.
John,
It seems like a slightly different design and some refactoring of the code
would help with this (of course that's WAY easier to say than it is to do).
I'm thinking of something like this:
Public API layer:
Very thin (i.e. minimum amount of code). The goal of this layer might be to
transform various input types into a fixed set of data. This would include:
- units to floats
- various input data representations to a standard format. Like converting
python lists to numpy arrays.
- various input options to a standard format. Like the various marker,
color, style input options into some standard representation.
Private plotting layer:
Fixed interface - doesn't support all the various options (lists, arrays,
units, color codes, etc). Does the actual work of plotting.
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). Any code written in the private layer could be assured of having
some specific input types and would be much easier to write.
It seems to have happened more than once that when some new chunk of code is
added, there are a number of bugs that appear because that code is written
with a single data type in mind (no units, no numpy arrays, etc). Having a
clear layer where data types can be assured would help w/ that.
Of course this would be a lot work and would require refactoring axis and
maybe some of the collections. In theory it should be possible, but only
you guys can decide if it's actually worthwhile or not.
Ted
···
-----Original Message-----
From: matplotlib-devel-bounces@lists.sourceforge.net
[mailto:matplotlib-devel-bounces@lists.sourceforge.net] On Behalf Of
John Hunter
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 <mdroe@...31...> > 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 already,
but those
> were fixed shortly after things were merged into the trunk around
0.98.0).
> All that is to say that you may want to cross-reference against
0.91.x if
> things look fishy. But I think you're right, we need some sort of
"best
> practices" guidance for supporting units, and then hopefully just
track down
> all the places where "such-and-such" should be happening and isn't.
I'll work on putting together a document for the developer's guide --
how to support units in a plotting function and artist. Supporting
the units interface everywhere would definitely add to the memory
footprint of mpl and would slow it down, in addition to increasing the
coding burden. On the other hand, they are quite useful in some
cases, most notably for me working with native datetimes and hopefully
down the road a numpy datetime extension. Once I get the guide
written and provide some clarity on the interface, we can decide in
which functions it makes the most sense from a performance usability
perspective and clean those first. Perhaps there are additional
abstractions that can ease the coding burden, eg encapsulating all the
mask/unit/what-have-you logic into a single entity such as a location
array which supports a minimum set of operations.
JDH
JDH
-----------------------------------------------------------------------
--
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.5.3/1564 - Release Date:
7/21/2008 6:42 AM