[Matplotlib-devel] Units discussion...

Hannah story645 at gmail.com
Wed Feb 7 10:14:54 EST 2018


I think what's also being proposed, and I think Ted also suggested, is an
API audit to figure out how units are/are not being implemented in each
function. Potentially we could even try to smooth out inconsistencies (like
between plot and scatter).

On Feb 7, 2018 6:43 AM, "David Stansby" <dstansby at gmail.com> wrote:

> Practically, I think what we are proposing is that for unit support the
> user must supply two functions for each axis:
>
>    - A mapping from your unit objects to floating point numbers
>    - A mapping from those floats back to your unit objects
>
> As far as I know function 2 is new, and doesn't need to be supplied at the
> moment. Doing this would mean we can convert units as soon as they enter
> Matplotlib, only ever have to deal with floating point numbers internally,
> and then use the second function as late as possible when the user requests
> stuff like e.g. the axis limits.
>
> Also worth noting that any major change like this will go in to Matplotlib
> 3.0 at the earliest, so will be python 3 only.
>
> David
>
> On 7 February 2018 at 06:06, Jody Klymak <jklymak at uvic.ca> wrote:
>
>> Dear Ted,
>>
>> Thanks so much for engaging on this.
>>
>> Don’t worry, nothing at all is changing w/o substantial back and forth,
>> and OK from downstream users.   I actually don’t think it’ll be a huge
>> change, probably just some clean up and better documentation.
>>
>> FWIW, I’ve not personally done much programming w/ units, just been a bit
>> perplexed by their inconsistent and (to my simple mind) convoluted
>> application in the codebase.  Having experience from people who try to use
>> them everyday will be absolutely key.
>>
>> Cheers,   Jody
>>
>> > On Feb 6, 2018, at  14:17 PM, Drain, Theodore R (392P) <
>> theodore.r.drain at jpl.nasa.gov> wrote:
>> >
>> > We use units for everything in our system (in fact, we funded John
>> Hunter originally to add in a unit system so we could use MPL) so it's a
>> crucial system for us.  In our system, we have our own time classes (which
>> handle relativistic time frames as well as much higher precision
>> representations) and a custom unit system for floating point values.
>> >
>> > I think it's important to talk about these changes in concrete terms.
>> I understand the words you're using,  but I'm not really clear on what the
>> real proposed changes are.  For example, the current unit API returns a
>> units.AxisInfo object so the converter can set the formatter and locators
>> to use.  Is that what you mean in the 2nd paragraph about ticks and
>> labels?  Or is that changing?
>> >
>> > The current unit api is pretty simple and in
>> units.ConversionInterface.  Are any of these changes going to change the
>> conversion API?  (note - I'm not against changing it - I'm just not sure if
>> there are any changes or not).
>> >
>> > Another thing to consider:  many of the examples people use are scripts
>> which make a plot and stop.  But there are other use cases which are more
>> complicated and stress the system in different ways.  We write several GUI
>> applications (in PyQt) that use MPL for plotting.  In these cases, the user
>> is interacting with the plot to add and remove artists, change styles,
>> modify data, etc etc.  So having a good object oriented API for modifying
>> things after construction is important for this to work.  So when units are
>> involved, it can't be a "convert once at construction" and never touch
>> units again.   We are constantly adjusting limits, moving artists, etc in
>> unitized space after the plot is created.
>> >
>> > So in addition to the ConversionInterface API, I think there are other
>> items that would be useful to explicitly spelled out.  Things like which
>> API's in MPL should accept units and which won't and which methods return
>> unitized data and which don't.   It would be nice if there was a clear
>> policy on this.  Maybe one exists and I'm not aware of it - it would be
>> helpful to repeat it in a discussion on changing the unit system.
>> Obviously I would love to have every method accept and return unitized data
>> :-).
>> >
>> > I bring this up because I was just working on a hover/annotation class
>> that needed to move a single annotation artist with the mouse.  To move the
>> annotation box the way I needed to, I had to set to one private member
>> variable, call two set methods, use attribute assignment for one value, and
>> set one semi-public member variable - some of which work with units and
>> some of which didn't.  I think having a clear "this kind of method
>> accepts/returns units" policy would help when people are adding new
>> accessors/methods/variables to make it more clear what kind of data is
>> acceptable in each.
>> >
>> > Ted
>> > ps: I may be able to help with some resources to work on any unit
>> upgrades, but to make that happen I need to get a clear statement of what
>> problem is being solved and the scope of the work so I can explain to our
>> management why it's important.
>> >
>> > ________________________________________
>> > From: Matplotlib-devel <matplotlib-devel-bounces+ted.drain=
>> jpl.nasa.gov at python.org> on behalf of Jody Klymak <jklymak at uvic.ca>
>> > Sent: Saturday, February 3, 2018 9:25 PM
>> > To: matplotlib development list
>> > Subject: [Matplotlib-devel] Units discussion...
>> >
>> > Hi all,
>> >
>> > To carry on the gitter discussion about unit handling, hopefully to
>> lead to a more stringent documentation and implimentation….
>> >
>> > In response to @anntzer I thought about the units support a bit - it
>> seems that rather than a transform, a more straightforward approach is to
>> have the converter map to float arrays in a unique way.  This float mapping
>> would be completely analogous to `date2num` in `dates`, in that it doesn’t
>> change and is perfectly invertible without matplotlib ever knowing about
>> the unit information, though the axis could store it for the the tick
>> locators and formatters.  It would also have an inverse that would supply
>> data back to the user in unit-aware data (though not necessarily in the
>> unit that the user supplied.  e.g. if they supply 8*in, the and the
>> converter converts everything to meter floats, then the returned unitized
>> inverse would be 0.203*m, or whatever convention the converter wants to
>> supply.).
>> >
>> > User “unit” control, i.e. making the plot in inches instead of m, would
>> be accomplished with ticks locators and formatters.  Matplotlib would never
>> directly convert between cm and inches (any more than it converts from days
>> to hours for dates), the downstream-supplied tick formatter and labeller
>> would do it.
>> >
>> > Each axis would only get one converter, set by the first call to the
>> axis. Subsequent calls to the axis would pass all data (including bare
>> floats) to the converter.  If the converter wants to pass bare floats then
>> it can do so.  If it wants to accept other data types then it can do so.
>> It should be possible for the user to clear or set the converter, but then
>> they should know what they are doing and why.
>> >
>> > Whats missing?  I don’t think this is wildly different than what we
>> have, but maybe a bit more clear.
>> >
>> > Cheers,   Jody
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel at python.org
>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel at python.org
>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180207/d1f1fd6a/attachment-0001.html>


More information about the Matplotlib-devel mailing list