From tune.kamae at gmail.com  Thu Feb  1 10:02:06 2018
From: tune.kamae at gmail.com (tune.kamae at gmail.com)
Date: Fri, 2 Feb 2018 00:02:06 +0900
Subject: [Matplotlib-devel] Call notes 29 Jan
In-Reply-To: <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
References: <9159D15C-00C2-4857-BE57-CD71BE149966@uvic.ca>
 <CAE-UAvRJ7pYYR5M9O54f9E-VBxBZpw4wFoFj45P4pRn1GNC+AQ@mail.gmail.com>
 <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
Message-ID: <36af01d39b6d$a1f95950$e5ec0bf0$@gmail.com>

Hi,

I signed up to this group hoping to learn or contribute to interactive Matplotlib.
My interest is to make Matplotlib accessible to the blind students.

I have long been a user of Matplotlib but technically at intermediate level.  I have been playing with the interactive version for about 6 months and trying it out with blind people.

I browsed through Nicolas' tutorial. It is very well written. However I did not find description about the interactive feature.

There are a few document on the interactive Matplotlib. It will be nice if some pages can be spent for the interactive Matplotlib and its use with sound and tts: I am using beeo sound in the "sound" and "winsound" packages and SAPI for TTS). There is an official tutorial at
https://matplotlib.org/users/interactive.html

It will be nice to let readers know features using sound and tts. These features require knowledge on procedure to stop the sound/tts without destroying the session. I end up shutting ipyhton down and restarting.

Regards,

Tune Kamae

-----Original Message-----
From: Matplotlib-devel [mailto:matplotlib-devel-bounces+tune.kamae=gmail.com at python.org] On Behalf Of Nicolas Rougier
Sent: Thursday, February 1, 2018 12:19 PM
To: Nelle Varoquaux <nelle.varoquaux at gmail.com>
Cc: matplotlib development list <Matplotlib-devel at python.org>
Subject: Re: [Matplotlib-devel] Call notes 29 Jan



> On 31 Jan 2018, at 22:54, Nelle Varoquaux <nelle.varoquaux at gmail.com> wrote:
> 
>>  - Jody noted that beyond the book, a shorter ?getting started? guide on the webpage would still be desirable:
> 
> There was an attempt at integrating Nicolas Rougier's excellent 
> matplotlib tutorial to the doc. I believe he had given permission to 
> do so, and that the amount of work required to merge the tutorial was 
> extremely small.

Yes, and I can help with the integration as well (the tutorial needs an update anyway).

Nicolas


> 
> Cheers,
> N
> 
>> 
>>        ACTION: Jody to co-ordinate a couple of outline documents that could start outlining both of these projects before any meeting.
>> 
>> There was also some discussion of online documentation technology:
>>  - Notebooks (via nbsphinx: https://nbsphinx.readthedocs.io)
>>        - hard to make PRs with.  Diffs are a mess in GitHub.
>>      - Can?t use emacs (easily)
>>  - RST-based, with plot directive:
>>        - python authoring less than desirable
>>  - Sphinx-gallery based:
>>        - rst authoring less than desirable
>>        - sphinx gallery has very restricted ordering methods (file 
>> size and alphabetical)
>> 
>> ## Release 2.2
>> 
>> Various Release-Critical PRs were looked at.
>> 
>> 
>> --
>> Jody Klymak
>> http://web.uvic.ca/~jklymak/
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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


From jklymak at uvic.ca  Thu Feb  1 10:05:11 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 1 Feb 2018 07:05:11 -0800
Subject: [Matplotlib-devel] Call notes 29 Jan
In-Reply-To: <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
References: <9159D15C-00C2-4857-BE57-CD71BE149966@uvic.ca>
 <CAE-UAvRJ7pYYR5M9O54f9E-VBxBZpw4wFoFj45P4pRn1GNC+AQ@mail.gmail.com>
 <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
Message-ID: <24C16F59-C0F1-46A5-8F4B-6BDA15B1FC2E@uvic.ca>



> 
> Yes, and I can help with the integration as well (the tutorial needs an update anyway).

Speaking personally, I think that was exactly the scope I had in mind when I said we could use something between the very short and somewhat idiosyncratic intros we have now and a 200-page book. If you were willing to work that into the official docs it?d be a huge contribution.  

My only quibble is I somewhat prefer steering people away from the pyplot API, just because I think it becomes limiting.  

Thanks!  Jody

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180201/6d262807/attachment.html>

From jklymak at uvic.ca  Thu Feb  1 13:02:50 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 1 Feb 2018 10:02:50 -0800
Subject: [Matplotlib-devel] Call notes 29 Jan
In-Reply-To: <24C16F59-C0F1-46A5-8F4B-6BDA15B1FC2E@uvic.ca>
References: <9159D15C-00C2-4857-BE57-CD71BE149966@uvic.ca>
 <CAE-UAvRJ7pYYR5M9O54f9E-VBxBZpw4wFoFj45P4pRn1GNC+AQ@mail.gmail.com>
 <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
 <24C16F59-C0F1-46A5-8F4B-6BDA15B1FC2E@uvic.ca>
Message-ID: <9CBB4E35-1272-4954-86C7-2D5A9D6005BA@uvic.ca>

Dear Nicolas,

Looking at the doc tree, it seems that if this tutorial could be put in `doc/users/` we could TOC it right under ?Installing? as ?Getting Started Guide? or ?Introductory Tutorial".  

I?m not sure what machinery to use to author it in.  

The nice thing about using sphinx-gallery is that you get a downloadable *.py and Ipython Notebook.  If you go this route, it would live in `tutorials/introductory` and we could link directly in the table of contents.  

Note there is an existing `tutorials/introductory/usage.py` that starts out OK, but then has some esoterica tacked on the end.  I think your tutorial is nicer.  But the image at the start of `tutorials/introductory/usage.py` is quite nice?

If you aren?t up for doing the conversion yourself, I?m happy to help, or I?m sure others are.


Cheers,   Jody





> On 1 Feb 2018, at 07:05, Jody Klymak <jklymak at uvic.ca> wrote:
> 
> 
> 
>> 
>> Yes, and I can help with the integration as well (the tutorial needs an update anyway).
> 
> Speaking personally, I think that was exactly the scope I had in mind when I said we could use something between the very short and somewhat idiosyncratic intros we have now and a 200-page book. If you were willing to work that into the official docs it?d be a huge contribution.  
> 
> My only quibble is I somewhat prefer steering people away from the pyplot API, just because I think it becomes limiting.  
> 
> Thanks!  Jody
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Jody Klymak    
http://web.uvic.ca/~jklymak/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180201/5d579d9a/attachment.html>

From vincent.adrien at gmail.com  Thu Feb  1 16:48:28 2018
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Thu, 1 Feb 2018 13:48:28 -0800
Subject: [Matplotlib-devel] Call notes 29 Jan
In-Reply-To: <9CBB4E35-1272-4954-86C7-2D5A9D6005BA@uvic.ca>
References: <9159D15C-00C2-4857-BE57-CD71BE149966@uvic.ca>
 <CAE-UAvRJ7pYYR5M9O54f9E-VBxBZpw4wFoFj45P4pRn1GNC+AQ@mail.gmail.com>
 <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
 <24C16F59-C0F1-46A5-8F4B-6BDA15B1FC2E@uvic.ca>
 <9CBB4E35-1272-4954-86C7-2D5A9D6005BA@uvic.ca>
Message-ID: <af50fe33-5af5-80ab-db86-fb6e377a55ff@gmail.com>

On 02/01/2018 10:02 AM, Jody Klymak wrote:
> But the image at the start of `tutorials/introductory/usage.py` is quite nice?

Well, if I remember correctly, that is Nicolas who created that picture ;) !

Adrien

From jklymak at uvic.ca  Thu Feb  1 17:24:43 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 1 Feb 2018 14:24:43 -0800
Subject: [Matplotlib-devel] Call notes 29 Jan
In-Reply-To: <af50fe33-5af5-80ab-db86-fb6e377a55ff@gmail.com>
References: <9159D15C-00C2-4857-BE57-CD71BE149966@uvic.ca>
 <CAE-UAvRJ7pYYR5M9O54f9E-VBxBZpw4wFoFj45P4pRn1GNC+AQ@mail.gmail.com>
 <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
 <24C16F59-C0F1-46A5-8F4B-6BDA15B1FC2E@uvic.ca>
 <9CBB4E35-1272-4954-86C7-2D5A9D6005BA@uvic.ca>
 <af50fe33-5af5-80ab-db86-fb6e377a55ff@gmail.com>
Message-ID: <0D17BA58-8064-46B7-BA9E-2E972A5E6D2C@uvic.ca>

Maybe the original `usage.py` is his as well?

Cheers,  Jody

> On 1 Feb 2018, at 13:48, vincent.adrien at gmail.com wrote:
> 
> On 02/01/2018 10:02 AM, Jody Klymak wrote:
>> But the image at the start of `tutorials/introductory/usage.py` is quite nice?
> 
> Well, if I remember correctly, that is Nicolas who created that picture ;) !
> 
> Adrien
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Jody Klymak    
http://web.uvic.ca/~jklymak/






From vincent.adrien at gmail.com  Thu Feb  1 17:33:13 2018
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Thu, 1 Feb 2018 14:33:13 -0800
Subject: [Matplotlib-devel] Call notes 29 Jan
In-Reply-To: <0D17BA58-8064-46B7-BA9E-2E972A5E6D2C@uvic.ca>
References: <9159D15C-00C2-4857-BE57-CD71BE149966@uvic.ca>
 <CAE-UAvRJ7pYYR5M9O54f9E-VBxBZpw4wFoFj45P4pRn1GNC+AQ@mail.gmail.com>
 <03E005EC-7E4D-419E-9B0B-D75CD2F1574E@inria.fr>
 <24C16F59-C0F1-46A5-8F4B-6BDA15B1FC2E@uvic.ca>
 <9CBB4E35-1272-4954-86C7-2D5A9D6005BA@uvic.ca>
 <af50fe33-5af5-80ab-db86-fb6e377a55ff@gmail.com>
 <0D17BA58-8064-46B7-BA9E-2E972A5E6D2C@uvic.ca>
Message-ID: <982044e2-2b6b-c7eb-b666-e72c41b2b303@gmail.com>

FWIW, looking at the history confirmed what I remembered : the tutorial 
under its current form was introduced by Chris Holdgraf, who made a 
significant part of the documentation work with Nelle V. when we 
switched to sphinx-gallery a while ago. Nevertheless the picture 
?Anatomy...? had already been there in the gallery thanks to Nicolas R.

Cheers,
Adrien

On 02/01/2018 02:24 PM, Jody Klymak wrote:
> Maybe the original `usage.py` is his as well?
> 
> Cheers,  Jody
> 
>> On 1 Feb 2018, at 13:48, vincent.adrien at gmail.com wrote:
>>
>> On 02/01/2018 10:02 AM, Jody Klymak wrote:
>>> But the image at the start of `tutorials/introductory/usage.py` is quite nice?
>>
>> Well, if I remember correctly, that is Nicolas who created that picture ;) !
>>
>> Adrien
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> --
> Jody Klymak
> http://web.uvic.ca/~jklymak/
> 
> 
> 
> 
> 


From jklymak at uvic.ca  Sun Feb  4 00:25:18 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Sat, 3 Feb 2018 21:25:18 -0800
Subject: [Matplotlib-devel] Units discussion...
Message-ID: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>

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



 

From tcaswell at gmail.com  Mon Feb  5 23:06:45 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 06 Feb 2018 04:06:45 +0000
Subject: [Matplotlib-devel] New maintainer
Message-ID: <CAA48SF-_HTTNm_s1+aZacND987DVYJr+AQ+=Q3RD4nsqTSQfSA@mail.gmail.com>

Folks,

Please welcome Tim Hoffmann (@timhoffm) to the team!

Tom

PS Tim, sorry for being slow getting this out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180206/1c549cc0/attachment.html>

From vincent.adrien at gmail.com  Mon Feb  5 23:10:45 2018
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Mon, 5 Feb 2018 20:10:45 -0800
Subject: [Matplotlib-devel] New maintainer
In-Reply-To: <CAA48SF-_HTTNm_s1+aZacND987DVYJr+AQ+=Q3RD4nsqTSQfSA@mail.gmail.com>
References: <CAA48SF-_HTTNm_s1+aZacND987DVYJr+AQ+=Q3RD4nsqTSQfSA@mail.gmail.com>
Message-ID: <ec6fecc4-134d-c541-7326-48920e6fdf65@gmail.com>

Welcome Tim, and thanks for the significative recent work :)!

Best,
Adrien

On 02/05/2018 08:06 PM, Thomas Caswell wrote:
> Folks,
> 
> Please welcome?Tim Hoffmann (@timhoffm) to the team!
> 
> Tom
> 
> PS Tim, sorry for being slow getting this out.
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 


From pmhobson at gmail.com  Tue Feb  6 00:43:26 2018
From: pmhobson at gmail.com (Paul Hobson)
Date: Mon, 5 Feb 2018 21:43:26 -0800
Subject: [Matplotlib-devel] New maintainer
In-Reply-To: <ec6fecc4-134d-c541-7326-48920e6fdf65@gmail.com>
References: <CAA48SF-_HTTNm_s1+aZacND987DVYJr+AQ+=Q3RD4nsqTSQfSA@mail.gmail.com>
 <ec6fecc4-134d-c541-7326-48920e6fdf65@gmail.com>
Message-ID: <CADT3MECN_UwwQWMY6J_k7xsLnhg19gLj9nhtW2m_c8EFDETq-A@mail.gmail.com>

Glad to have you on board!
-p

On Mon, Feb 5, 2018 at 8:10 PM, vincent.adrien at gmail.com <
vincent.adrien at gmail.com> wrote:

> Welcome Tim, and thanks for the significative recent work :)!
>
> Best,
> Adrien
>
>
> On 02/05/2018 08:06 PM, Thomas Caswell wrote:
>
>> Folks,
>>
>> Please welcome Tim Hoffmann (@timhoffm) to the team!
>>
>> Tom
>>
>> PS Tim, sorry for being slow getting this out.
>>
>>
>> _______________________________________________
>> 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/20180205/7fea9fab/attachment.html>

From ben.v.root at gmail.com  Tue Feb  6 09:35:49 2018
From: ben.v.root at gmail.com (Benjamin Root)
Date: Tue, 6 Feb 2018 09:35:49 -0500
Subject: [Matplotlib-devel] New maintainer
In-Reply-To: <CADT3MECN_UwwQWMY6J_k7xsLnhg19gLj9nhtW2m_c8EFDETq-A@mail.gmail.com>
References: <CAA48SF-_HTTNm_s1+aZacND987DVYJr+AQ+=Q3RD4nsqTSQfSA@mail.gmail.com>
 <ec6fecc4-134d-c541-7326-48920e6fdf65@gmail.com>
 <CADT3MECN_UwwQWMY6J_k7xsLnhg19gLj9nhtW2m_c8EFDETq-A@mail.gmail.com>
Message-ID: <CANNq6Fk9ECrx3v7Gv-nYNW39xd-Jv=j8AFj+HyXn9zGQJS_O5A@mail.gmail.com>

Cheers!

On Tue, Feb 6, 2018 at 12:43 AM, Paul Hobson <pmhobson at gmail.com> wrote:

> Glad to have you on board!
> -p
>
> On Mon, Feb 5, 2018 at 8:10 PM, vincent.adrien at gmail.com <
> vincent.adrien at gmail.com> wrote:
>
>> Welcome Tim, and thanks for the significative recent work :)!
>>
>> Best,
>> Adrien
>>
>>
>> On 02/05/2018 08:06 PM, Thomas Caswell wrote:
>>
>>> Folks,
>>>
>>> Please welcome Tim Hoffmann (@timhoffm) to the team!
>>>
>>> Tom
>>>
>>> PS Tim, sorry for being slow getting this out.
>>>
>>>
>>> _______________________________________________
>>> 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/20180206/e1e44d57/attachment.html>

From theodore.r.drain at jpl.nasa.gov  Tue Feb  6 17:17:47 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Tue, 6 Feb 2018 22:17:47 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
Message-ID: <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>

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

From tcaswell at gmail.com  Tue Feb  6 21:56:16 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Wed, 07 Feb 2018 02:56:16 +0000
Subject: [Matplotlib-devel] new maintainer
Message-ID: <CAA48SF-iVC5WqsuOqq-5gqQ=2Gd-SSnLs=YHOvmoHgegpVxwig@mail.gmail.com>

Folks,

Please welcome Dietmar Schwertberger to the team.  He is going to take the
lead on the Wx backend.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180207/43563a26/attachment.html>

From ben.v.root at gmail.com  Tue Feb  6 22:15:04 2018
From: ben.v.root at gmail.com (Benjamin Root)
Date: Tue, 6 Feb 2018 22:15:04 -0500
Subject: [Matplotlib-devel] new maintainer
In-Reply-To: <CAA48SF-iVC5WqsuOqq-5gqQ=2Gd-SSnLs=YHOvmoHgegpVxwig@mail.gmail.com>
References: <CAA48SF-iVC5WqsuOqq-5gqQ=2Gd-SSnLs=YHOvmoHgegpVxwig@mail.gmail.com>
Message-ID: <CANNq6F=_LzBynJsRyRrQCHwh8aCxg5eUKkuu+b-NRDV5KvPayA@mail.gmail.com>

Great to see that backend getting some love! Welcome!

Cheers!
Ben Root


On Tue, Feb 6, 2018 at 9:56 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

> Folks,
>
> Please welcome Dietmar Schwertberger to the team.  He is going to take the
> lead on the Wx backend.
>
> Tom
>
> _______________________________________________
> 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/20180206/d27e819c/attachment.html>

From vincent.adrien at gmail.com  Wed Feb  7 00:44:03 2018
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Tue, 6 Feb 2018 21:44:03 -0800
Subject: [Matplotlib-devel] new maintainer
In-Reply-To: <CANNq6F=_LzBynJsRyRrQCHwh8aCxg5eUKkuu+b-NRDV5KvPayA@mail.gmail.com>
References: <CAA48SF-iVC5WqsuOqq-5gqQ=2Gd-SSnLs=YHOvmoHgegpVxwig@mail.gmail.com>
 <CANNq6F=_LzBynJsRyRrQCHwh8aCxg5eUKkuu+b-NRDV5KvPayA@mail.gmail.com>
Message-ID: <41a90e00-5e66-cdcb-7f6d-5949f6952af6@gmail.com>

Welcome Dietmar :)!

Cheers,
Adrien

On 02/06/2018 07:15 PM, Benjamin Root wrote:
> Great to see that backend getting some love! Welcome!
> 
> Cheers!
> Ben Root
> 
> 
> On Tue, Feb 6, 2018 at 9:56 PM, Thomas Caswell <tcaswell at gmail.com 
> <mailto:tcaswell at gmail.com>> wrote:
> 
>     Folks,
> 
>     Please welcome?Dietmar Schwertberger to the team.? He is going to
>     take the lead on the Wx backend.
> 
>     Tom
> 
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>     <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
> 


From jklymak at uvic.ca  Wed Feb  7 01:06:48 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Tue, 6 Feb 2018 22:06:48 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
Message-ID: <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>

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


From dstansby at gmail.com  Wed Feb  7 06:42:49 2018
From: dstansby at gmail.com (David Stansby)
Date: Wed, 7 Feb 2018 11:42:49 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
Message-ID: <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180207/5adf07b2/attachment.html>

From story645 at gmail.com  Wed Feb  7 10:14:54 2018
From: story645 at gmail.com (Hannah)
Date: Wed, 7 Feb 2018 10:14:54 -0500
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
Message-ID: <CAOuQ7j0pY9izJYo1YK7QM73irTK6UMFKU=QZxE=R36Gq2ODexg@mail.gmail.com>

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>

From theodore.r.drain at jpl.nasa.gov  Wed Feb  7 10:33:36 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Wed, 7 Feb 2018 15:33:36 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>,
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
Message-ID: <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>

That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.    

Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.  

Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.  

That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.

Ted

________________________________________
From: David Stansby <dstansby at gmail.com>
Sent: Wednesday, February 7, 2018 3:42 AM
To: Jody Klymak
Cc: Drain, Theodore R (392P); matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

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<mailto: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<mailto: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<mailto:jpl.nasa.gov at python.org>> on behalf of Jody Klymak <jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
> https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel


From marcidy at gmail.com  Thu Feb  8 03:29:57 2018
From: marcidy at gmail.com (Matt Arcidy)
Date: Thu, 8 Feb 2018 00:29:57 -0800
Subject: [Matplotlib-devel] Documentation
Message-ID: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>

Hi All,

Please forgive the presumption of pulling this topic out of from the
meeting thread especially as this is also in a self-introduction email.

I want to help with the documentation effort.  I read Tom's article in
numfocus and the desired skillset rang true.  I have 10ish years experience
writing tech docs, a few 100+ pages.   I write creatively, and I am still
somewhat new to matplotlib.  I am happy to work in any capacity, though i
am most interested in cranking out the first draft of the book.

I have looked into the available documentation over the past month+ so I
could come with understanding and ideas, some of which I hope are actually
good.

Both the meeting thread and Tom requested ideas for reorganizing the
tutorials and examples as a place to start, so I'll throw one out: explicit
definition of an audience, something to which all the documentation can
adhere.

Right now the tutorials are leveled as beginner, intermediate, and expert,
which is great, but it's not clear what that means.  Explicitly defining
the required skill sets, while not perfect, will allow sorting of concepts
and people into each bin.

As an example, (please excuse the contrivence):

Laura
- Sophomore in college
- dead set on being a data scientist
- 2 programming classes in python
- never used any kind of CAD software ever (i.e. does not have any concept
of a plot beyond a line on graph paper)

Xian
- 1 week away from Zoology PhD dissertation, under a deadline
- Has used R and Matplotlib to create very basic plots for papers
- Wants to create a plot with species heart size over adult weight, with
the marker being a jpg of the species' actual heart, beating at the actual
species' heart rate on the plot.

Ayah
- Post Doc or professional
- 10+ years of plotting experience using various packages but not matplotlib
- has funding to contribute significant functionality, but needs to get up
to speed on everything now

Obviously this is just beginner, intermediate, expert, but they can be
explicitly targeted/taught based on their skill level.  Laura needs
hand-holding, Xian needs a great API reference, Ayah needs a mosaic of
everything and a good architecture map.

In the same vein as above, learning paths through the tutorial documents.
There are some separable plotting skills, like visually designing the plot,
animation, application development, matplotlib development...etc. Each
skill could have beginner/intermediate/expert level tutorials which
progress naturally, creating a learning tract for each skill.  Skills can
be stacked to flow into specific roles.

Looking at this from outside, the best part about this project is all the
information is already there. I have more ideas to dump on you, but I'll
postpone until I have a better understanding of where I can fit.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/c7c835b6/attachment.html>

From antony.lee at berkeley.edu  Thu Feb  8 11:09:32 2018
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 8 Feb 2018 17:09:32 +0100
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
Message-ID: <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>

I'm momentarily a bit away from Matplotlib development due to real life
piling up, so I'll just keep this short.

One major point (already mentioned by others) that led, I think, to some
devs (including myself) being relatively dismissive about unit support is
the lack of well-defined use case, other than "it'd be nice if we supported
units" (i.e., especially from the point of view of devs who *don't* use
units themselves, it ends up being an ever moving target).  In particular,
tests on unit support ("unit unit tests"? :-)) currently only rely on the
old JPL unit code that ended up integrated into Matplotlib's test suite,
but does not test integration with the two major unit packages I am aware
of (pint and astropy.units).

>From the email of Ted it appears that these are not sufficient to represent
all kinds of relevant units.  In particular, I was at some point hoping to
completely work in deunitized data internally, *including the plotting*,
and rely on the fact that if the deunitized and the unitized data are
usually linked by an affine transform, so the plotting part doesn't need to
convert back to unitized data and we only need to place and label the ticks
accordingly; however Ted mentioned relativistic units, which imply the use
of a non-affine transform.  So I think it would also be really helpful if
JPL could release some reasonably documented unit library with their actual
use cases (and how it differs from pint & astropy.units), so that we know
better what is actually needed (I believe carrying the JPL unit code in our
own code base is a mistake).

As for the public vs private, or rather unitized vs deunitized API
discussion, I believe a relatively simple and consistent line would be to
make Axes methods unitized and everything else deunitized (but with clear
ways to convert to and from unitized data when not using Axes methods).

Antony

2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
theodore.r.drain at jpl.nasa.gov>:

> That sounds fine to me.  Our original unit prototype API actually had
> conversions for both directions but I think the float->unit version was
> removed (or really moved) when the ticker/formatter portion of the unit API
> was settled on.
>
> Using floats/numpy arrays internally is going to easier and faster so I
> think that's a plus.  The biggest issue we're going to run in to is what's
> defined as "internal" vs part of the unit API.  Some things are easy like
> the Axes/Axis API.  But we also use low level API's like the patches.  Are
> those unitized?  This is the pro and con of using something like Python
> where basically everything is public.  It makes it possible to do lots of
> things, but it's much harder to define a clear library with a specific
> public API.
>
> Somewhere in the process we should write a proposal that outlines which
> classes/methods are part of the unit api and which are going to be
> considered internal.  I'm sure we can help with that effort.
>
> That also might help clarify/influence code structure - if internal
> implementation classes are placed in a sub-package inside MPL 3.0, it
> becomes clearer to people later on what the "official' public API vs what
> can be optimized to just use floats.  Obviously the dev's would need to
> decide if that kind of restructuring is worth it or not.
>
> Ted
>
> ________________________________________
> From: David Stansby <dstansby at gmail.com>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> 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<mailto:jklyma
> k 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<mailto: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<mailto:jpl.nasa.gov at python.org>> on behalf of
> Jody Klymak <jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org>
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto: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/20180208/fc3c08ed/attachment-0001.html>

From story645 at gmail.com  Thu Feb  8 11:15:05 2018
From: story645 at gmail.com (Hannah)
Date: Thu, 8 Feb 2018 11:15:05 -0500
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
Message-ID: <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>

Hi Matt,
I'm super psyched that you're onboard and totally agree with you on the
importance of identifying audience. I think that's a lot of where the docs
really struggle because the audience is very broad.

For example, I introduce matplotlib a lot to the following audiences who I
don't think you've mentioned yet:

high school students
-little to no programming classes
-a summer REU
-only know about the plots they've seen in their science class

humanaties masters and graduate students
- little/no programming experience
- frame of reference for visualization is usually journalism viz like New
York Times or art installations.
- often don't have or forgot the vocabulary around  scientific and
statistical plots (what is a measurment, scale, etc)

Computer Science students
- undergrad through grad
- taking a visualization course
- have lots of programming experience, but not necessarily in Python
- want to make highly information dense plots or dashboards


And I really would love a survey of the community to get an even better
sense of who is using matplotlib.

-Hannah

On Feb 8, 2018 3:30 AM, "Matt Arcidy" <marcidy at gmail.com> wrote:

Hi All,

Please forgive the presumption of pulling this topic out of from the
meeting thread especially as this is also in a self-introduction email.

I want to help with the documentation effort.  I read Tom's article in
numfocus and the desired skillset rang true.  I have 10ish years experience
writing tech docs, a few 100+ pages.   I write creatively, and I am still
somewhat new to matplotlib.  I am happy to work in any capacity, though i
am most interested in cranking out the first draft of the book.

I have looked into the available documentation over the past month+ so I
could come with understanding and ideas, some of which I hope are actually
good.

Both the meeting thread and Tom requested ideas for reorganizing the
tutorials and examples as a place to start, so I'll throw one out: explicit
definition of an audience, something to which all the documentation can
adhere.

Right now the tutorials are leveled as beginner, intermediate, and expert,
which is great, but it's not clear what that means.  Explicitly defining
the required skill sets, while not perfect, will allow sorting of concepts
and people into each bin.

As an example, (please excuse the contrivence):

Laura
- Sophomore in college
- dead set on being a data scientist
- 2 programming classes in python
- never used any kind of CAD software ever (i.e. does not have any concept
of a plot beyond a line on graph paper)

Xian
- 1 week away from Zoology PhD dissertation, under a deadline
- Has used R and Matplotlib to create very basic plots for papers
- Wants to create a plot with species heart size over adult weight, with
the marker being a jpg of the species' actual heart, beating at the actual
species' heart rate on the plot.

Ayah
- Post Doc or professional
- 10+ years of plotting experience using various packages but not matplotlib
- has funding to contribute significant functionality, but needs to get up
to speed on everything now

Obviously this is just beginner, intermediate, expert, but they can be
explicitly targeted/taught based on their skill level.  Laura needs
hand-holding, Xian needs a great API reference, Ayah needs a mosaic of
everything and a good architecture map.

In the same vein as above, learning paths through the tutorial documents.
There are some separable plotting skills, like visually designing the plot,
animation, application development, matplotlib development...etc. Each
skill could have beginner/intermediate/expert level tutorials which
progress naturally, creating a learning tract for each skill.  Skills can
be stacked to flow into specific roles.

Looking at this from outside, the best part about this project is all the
information is already there. I have more ideas to dump on you, but I'll
postpone until I have a better understanding of where I can fit.

Thanks!

_______________________________________________
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/20180208/186fcf85/attachment.html>

From jklymak at uvic.ca  Thu Feb  8 11:47:06 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 8 Feb 2018 08:47:06 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
Message-ID: <B5071399-2897-4286-A564-9ACD6896050A@uvic.ca>

Thanks Antony, 



> On Feb 8, 2018, at  8:09 AM, Antony Lee <antony.lee at berkeley.edu> wrote:


> From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).

? or an indication that the astropy (for instance) use-case is good enough to base an API around.  

> As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).

I was going to suggest that distinction as well.  Anything that requires `axes.add_artist` is deunitized since we use those artists all over the place internally and keeping track of whether we have units or not would be really hard.  

Cheers,   Jody

> Antony
> 
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>>:
> That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.
> 
> Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.
> 
> Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.
> 
> That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.
> 
> Ted
> 
> ________________________________________
> From: David Stansby <dstansby at gmail.com <mailto:dstansby at gmail.com>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> 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 <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto: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 <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto: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 <mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org>>> on behalf of Jody Klymak <jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto: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 <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>
> > https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>
> > https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <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/20180208/f822932a/attachment-0001.html>

From theodore.r.drain at jpl.nasa.gov  Thu Feb  8 12:13:53 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Thu, 8 Feb 2018 17:13:53 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>,
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
Message-ID: <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>

Sorry - that's not what I meant.  The unit conversions API that's in place works fine  I can't think of a better way to describe the use cases than the basic ones that seem (at least to me) to be obvious.  Numbers with units (5*km) and time classes (datetime or some other time class like we use) are the primary use case.   Another way to say it is that users have data where the normal representation is not float and they want to plot it, control how the transformation to float is done (plot in km or miles, in UTC or GPS time) and manipulate the plot after it's plotted (get bounds, change bounds, change units, move artists, edit data, etc) in the non-float representation that their data is already in.

I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data.  

This is kind of what I meant in my previous email about use cases.  Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.

I'm not sure I understand the statement that units are a moving target.  The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.  

Ted

________________________________________
From: anntzer.lee at gmail.com <anntzer.lee at gmail.com> on behalf of Antony Lee <antony.lee at berkeley.edu>
Sent: Thursday, February 8, 2018 8:09 AM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.

One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target).  In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).

>From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).

As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).

Antony

2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>>:
That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.

Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.

Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.

That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.

Ted

________________________________________
From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com>>
Sent: Wednesday, February 7, 2018 3:42 AM
To: Jody Klymak
Cc: Drain, Theodore R (392P); matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

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<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov<mailto: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<mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org<mailto:jpl.nasa.gov at python.org>>> on behalf of Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel


From antony.lee at berkeley.edu  Thu Feb  8 12:37:15 2018
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 8 Feb 2018 18:37:15 +0100
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
Message-ID: <CAGRr6BEj+=VX2M+bdBCR9ebK24WL+LV0ZjaaAnu0EydCsbvBTQ@mail.gmail.com>

The problem here (as you mentioned) is that essentially close to everything
is a public API in Matplotlib, and I believe quite strongly that it is
unreasonable to make every function check for unitized data (and what about
attributes? are bboxes and transforms supposed to handle units too?).  For
example, this leads to Line2D.get_data have the orig=True[False kwarg and
the class needs to internally keep both unitized and deunitized data
around; duplicating this support throughout all artists would be a *lot* of
code.

While Axes methods can reasonably support units out of the box, I think it
is more reasonable to have (up to bikeshedding) `Axes.unitize` and
`Axes.deunitize` and then have people who need to play with the artists
themselves do e.g. `artist.set_data(artist.axes.deunitize(unitized_data))`
and `artist.axes.unitize(artist.get_data())`.  Yes, I realize this may be
more work for you, but it's also a tradeoff of less work for us :-)  With
this design, another possibility (which I guess Tom is not going to like,
but I actually think is reasonable) would be for you to patch all the
Artist classes yourself to support unitized data in all methods you want
(using the proper wrapper methods).

The "moving target" part is basically that there has never been complete
support for units everywhere in the code base, and because things are added
in a piecemeal fashion rather than with a well thought-out design, I'm a
bit tired of the constant stream of "oh, this function doesn't support
datetimes, we need to fix it".  Again, I believe rethinking the design in a
comprehensive fashion would help with that.

Antony

2018-02-08 18:13 GMT+01:00 Drain, Theodore R (392P) <
theodore.r.drain at jpl.nasa.gov>:

> Sorry - that's not what I meant.  The unit conversions API that's in place
> works fine  I can't think of a better way to describe the use cases than
> the basic ones that seem (at least to me) to be obvious.  Numbers with
> units (5*km) and time classes (datetime or some other time class like we
> use) are the primary use case.   Another way to say it is that users have
> data where the normal representation is not float and they want to plot it,
> control how the transformation to float is done (plot in km or miles, in
> UTC or GPS time) and manipulate the plot after it's plotted (get bounds,
> change bounds, change units, move artists, edit data, etc) in the non-float
> representation that their data is already in.
>
> I realize that units are "a pain", but they're hugely useful.  Just
> plotting datetimes is going to be a pain without units (and was a huge pain
> before the unit system).  The proposal that only Axes supports units is
> going to cause us a massive problem as that's rarely everything that we do
> with a plot.  I could do a survey to find all the interactions we use (and
> that doesn't even touch the 1000's of lines of code our users have written)
> if that would help but anything that's part of the public api (axes,
> artists, patches, etc) is probably being used - i.e. pretty much anything
> that's in the current user's guide is something that we use/want/need to
> work with unitized data.
>
> This is kind of what I meant in my previous email about use cases.  Saying
> "just Axes has units" is basically saying the only valid unit use case is
> create a plot one time and look at it.  You can't manipulate it, edit it,
> or build any kind of plotting GUI application (which we have many of) once
> the plot has been created.  The Artist classes are one of the primary API's
> for applications.  Artists are created, edited, and manipulated if you want
> to allow the user to modify things in a plot after it's created.    Even
> the most basic cases like calling Line2D.set_data() wouldn't be allowed
> with units if only Axes has unit support.
>
> I'm not sure I understand the statement that units are a moving target.
> The reason it keeps popping up is that code gets added without something
> considering units which then triggers a bug reports which require fixing.
> If there was a clearer policy and new code was required to have test cases
> that cover non-unit and unit inputs, I think things would go much
> smoother.  We'd be happy to help with submitting new test cases to cover
> unit cases in existing code once a policy is decided on.  Maybe what's
> needed is better documentation for developers who don't use units so they
> can easily write a test case with units when adding/modifying functionality.
>
> Ted
>
> ________________________________________
> From: anntzer.lee at gmail.com <anntzer.lee at gmail.com> on behalf of Antony
> Lee <antony.lee at berkeley.edu>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> I'm momentarily a bit away from Matplotlib development due to real life
> piling up, so I'll just keep this short.
>
> One major point (already mentioned by others) that led, I think, to some
> devs (including myself) being relatively dismissive about unit support is
> the lack of well-defined use case, other than "it'd be nice if we supported
> units" (i.e., especially from the point of view of devs who *don't* use
> units themselves, it ends up being an ever moving target).  In particular,
> tests on unit support ("unit unit tests"? :-)) currently only rely on the
> old JPL unit code that ended up integrated into Matplotlib's test suite,
> but does not test integration with the two major unit packages I am aware
> of (pint and astropy.units).
>
> From the email of Ted it appears that these are not sufficient to
> represent all kinds of relevant units.  In particular, I was at some point
> hoping to completely work in deunitized data internally, *including the
> plotting*, and rely on the fact that if the deunitized and the unitized
> data are usually linked by an affine transform, so the plotting part
> doesn't need to convert back to unitized data and we only need to place and
> label the ticks accordingly; however Ted mentioned relativistic units,
> which imply the use of a non-affine transform.  So I think it would also be
> really helpful if JPL could release some reasonably documented unit library
> with their actual use cases (and how it differs from pint & astropy.units),
> so that we know better what is actually needed (I believe carrying the JPL
> unit code in our own code base is a mistake).
>
> As for the public vs private, or rather unitized vs deunitized API
> discussion, I believe a relatively simple and consistent line would be to
> make Axes methods unitized and everything else deunitized (but with clear
> ways to convert to and from unitized data when not using Axes methods).
>
> Antony
>
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>>:
> That sounds fine to me.  Our original unit prototype API actually had
> conversions for both directions but I think the float->unit version was
> removed (or really moved) when the ticker/formatter portion of the unit API
> was settled on.
>
> Using floats/numpy arrays internally is going to easier and faster so I
> think that's a plus.  The biggest issue we're going to run in to is what's
> defined as "internal" vs part of the unit API.  Some things are easy like
> the Axes/Axis API.  But we also use low level API's like the patches.  Are
> those unitized?  This is the pro and con of using something like Python
> where basically everything is public.  It makes it possible to do lots of
> things, but it's much harder to define a clear library with a specific
> public API.
>
> Somewhere in the process we should write a proposal that outlines which
> classes/methods are part of the unit api and which are going to be
> considered internal.  I'm sure we can help with that effort.
>
> That also might help clarify/influence code structure - if internal
> implementation classes are placed in a sub-package inside MPL 3.0, it
> becomes clearer to people later on what the "official' public API vs what
> can be optimized to just use floats.  Obviously the dev's would need to
> decide if that kind of restructuring is worth it or not.
>
> Ted
>
> ________________________________________
> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> 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<mailto:jklyma
> k at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:theodore.r.drain at jpl.nasa.gov
> ><mailto:theodore.r.drain at jpl.nasa.gov<mailto:theo
> dore.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<mailto:jpl.nasa.gov at python.org><mailto:
> jpl.nasa.gov at python.org<mailto:jpl.nasa.gov at python.org>>> on behalf of
> Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca><mailto:jklymak@
> uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org><mailto:
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto: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/20180208/3e457026/attachment-0001.html>

From jklymak at uvic.ca  Thu Feb  8 12:39:20 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 8 Feb 2018 09:39:20 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
Message-ID: <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>


> I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data. 

OK, *for discussion*: A scope of work for JPL and Matplotlib might be:

1) develop better toy unit module that has most of the desired features (maybe the existing one is fine, but please see https://github.com/matplotlib/matplotlib/issues/9713 <https://github.com/matplotlib/matplotlib/issues/9713> for why I?m a little dismayed with the state of things).  

2) write a developer?s guide explaining how units should be/are implemented 
	a) in matplotlib modules
        b) by downstream developers (this is probably adequate already).

It sounds like what you are saying is that units should be carried to the draw stage (or cache stage) for all artists.  Thats maybe fine, but as a new developer, I found the units support woefully under-documented.  The fact that others have hacked in units support in various inconsistent ways means that we need to police all this better.  

OTOH, maybe Antony and I are poor people to lead this charge, given that we don?t need unit support.  But I don?t think we are being hypercritical in pointing out it needs work.

Thanks a lot,   Jody


> This is kind of what I meant in my previous email about use cases.  Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.
> 
> I'm not sure I understand the statement that units are a moving target.  The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.  
> 
> Ted
> 
> ________________________________________
> From: anntzer.lee at gmail.com <mailto:anntzer.lee at gmail.com> <anntzer.lee at gmail.com <mailto:anntzer.lee at gmail.com>> on behalf of Antony Lee <antony.lee at berkeley.edu <mailto:antony.lee at berkeley.edu>>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.
> 
> One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target). In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).
> 
>> From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).
> 
> As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).
> 
> Antony
> 
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>>>:
> That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.
> 
> Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.
> 
> Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.
> 
> That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.
> 
> Ted
> 
> ________________________________________
> From: David Stansby <dstansby at gmail.com <mailto:dstansby at gmail.com><mailto:dstansby at gmail.com <mailto:dstansby at gmail.com>>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> 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 <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca>><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto: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 <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto: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 <mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org>><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org>>>> on behalf of Jody Klymak <jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca>><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto: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 <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/be016cd5/attachment-0001.html>

From theodore.r.drain at jpl.nasa.gov  Thu Feb  8 12:54:33 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Thu, 8 Feb 2018 17:54:33 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>,
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
Message-ID: <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>

Sorry if it came across that way - I wasn't try to say that it doesn't need work.  I completely agree with you on 1) and 2).

As far as what to do about units in the draw stage - I'm not saying anything like that (thought that might be the result).  I'm saying that to support units, we should design the API's to support units and be explicit about which API's support units and which don't (new doc tag maybe?).  I'm not making any statements about the underlying affect of that statement on the code.  There are a probably a number of designs that meet that API goal but I don't know enough of the MPL internals to advocate for one over the other.

I think we can help with building a better toy unit system.  Or we can standardize on datetime and some existing unit package.  Whatever makes it easier for people to write test cases.

 ________________________________________
From: Jody Klymak <jklymak at uvic.ca>
Sent: Thursday, February 8, 2018 9:39 AM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data.

OK, *for discussion*: A scope of work for JPL and Matplotlib might be:

1) develop better toy unit module that has most of the desired features (maybe the existing one is fine, but please see https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little dismayed with the state of things).

2) write a developer?s guide explaining how units should be/are implemented
a) in matplotlib modules
        b) by downstream developers (this is probably adequate already).

It sounds like what you are saying is that units should be carried to the draw stage (or cache stage) for all artists.  Thats maybe fine, but as a new developer, I found the units support woefully under-documented.  The fact that others have hacked in units support in various inconsistent ways means that we need to police all this better.

OTOH, maybe Antony and I are poor people to lead this charge, given that we don?t need unit support.  But I don?t think we are being hypercritical in pointing out it needs work.

Thanks a lot,   Jody


This is kind of what I meant in my previous email about use cases.  Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.

I'm not sure I understand the statement that units are a moving target.  The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.

Ted

________________________________________
From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com> <anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com>> on behalf of Antony Lee <antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu>>
Sent: Thursday, February 8, 2018 8:09 AM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.

One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target). In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).

>From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).

As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).

Antony

2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov>>:
That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.

Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.

Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.

That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.

Ted

________________________________________
From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com><mailto:dstansby at gmail.com>>
Sent: Wednesday, February 7, 2018 3:42 AM
To: Jody Klymak
Cc: Drain, Theodore R (392P); matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

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<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov<mailto: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<mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org<mailto:jpl.nasa.gov at python.org>>> on behalf of Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel


From dstansby at gmail.com  Thu Feb  8 13:02:57 2018
From: dstansby at gmail.com (David Stansby)
Date: Thu, 8 Feb 2018 18:02:57 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
Message-ID: <CAGm9cHDQ0prB08pmBq37hktoVExnkV=BTshioOJhAd=0-A2OHg@mail.gmail.com>

*puts hand up* I'm (sort of...) a Matplotlib developer and use (am starting
to use) units in my day to day research.

My proposal remains this:

   - The user provides a method for converting objects of their custom
   class to a floating point numbers
   - The user provides a method for converting floating point numbers to
   their custom class
   - *Everything *in Matplotlib that accepts data accepts custom type
   objects
   - The first thing it does is convert these objects to floats, and then
   everything we do internally is with those floats

Can anyone point out reasons that this isn't the right way to do it? This
has the advantages:

   - Matplotlib takes no responsibility for the conversion
   - We only every calculate with floats
   - You can use whatever objects you want, as long as your converter goes
   object --> float

Having thought a little bit this seems like the obvious way to do it, but I
may be missing something.

David

On 8 February 2018 at 17:39, Jody Klymak <jklymak at uvic.ca> wrote:

>
> I realize that units are "a pain", but they're hugely useful.  Just
> plotting datetimes is going to be a pain without units (and was a huge pain
> before the unit system).  The proposal that only Axes supports units is
> going to cause us a massive problem as that's rarely everything that we do
> with a plot.  I could do a survey to find all the interactions we use (and
> that doesn't even touch the 1000's of lines of code our users have written)
> if that would help but anything that's part of the public api (axes,
> artists, patches, etc) is probably being used - i.e. pretty much anything
> that's in the current user's guide is something that we use/want/need to
> work with unitized data.
>
>
> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
>
> 1) develop better toy unit module that has most of the desired features
> (maybe the existing one is fine, but please see https://github.com/
> matplotlib/matplotlib/issues/9713 for why I?m a little dismayed with the
> state of things).
>
> 2) write a developer?s guide explaining how units should be/are
> implemented
> a) in matplotlib modules
>         b) by downstream developers (this is probably adequate already).
>
> It sounds like what you are saying is that units should be carried to the
> draw stage (or cache stage) for all artists.  Thats maybe fine, but as a
> new developer, I found the units support woefully under-documented.  The
> fact that others have hacked in units support in various inconsistent ways
> means that we need to police all this better.
>
> OTOH, maybe Antony and I are poor people to lead this charge, given that
> we don?t need unit support.  But I don?t think we are being hypercritical
> in pointing out it needs work.
>
> Thanks a lot,   Jody
>
>
> This is kind of what I meant in my previous email about use cases.  Saying
> "just Axes has units" is basically saying the only valid unit use case is
> create a plot one time and look at it.  You can't manipulate it, edit it,
> or build any kind of plotting GUI application (which we have many of) once
> the plot has been created.  The Artist classes are one of the primary API's
> for applications.  Artists are created, edited, and manipulated if you want
> to allow the user to modify things in a plot after it's created.    Even
> the most basic cases like calling Line2D.set_data() wouldn't be allowed
> with units if only Axes has unit support.
>
> I'm not sure I understand the statement that units are a moving target.
> The reason it keeps popping up is that code gets added without something
> considering units which then triggers a bug reports which require fixing.
> If there was a clearer policy and new code was required to have test cases
> that cover non-unit and unit inputs, I think things would go much
> smoother.  We'd be happy to help with submitting new test cases to cover
> unit cases in existing code once a policy is decided on.  Maybe what's
> needed is better documentation for developers who don't use units so they
> can easily write a test case with units when adding/modifying
> functionality.
>
> Ted
>
> ________________________________________
> From: anntzer.lee at gmail.com <anntzer.lee at gmail.com> on behalf of Antony
> Lee <antony.lee at berkeley.edu>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> I'm momentarily a bit away from Matplotlib development due to real life
> piling up, so I'll just keep this short.
>
> One major point (already mentioned by others) that led, I think, to some
> devs (including myself) being relatively dismissive about unit support is
> the lack of well-defined use case, other than "it'd be nice if we supported
> units" (i.e., especially from the point of view of devs who *don't* use
> units themselves, it ends up being an ever moving target). In particular,
> tests on unit support ("unit unit tests"? :-)) currently only rely on the
> old JPL unit code that ended up integrated into Matplotlib's test suite,
> but does not test integration with the two major unit packages I am aware
> of (pint and astropy.units).
>
> From the email of Ted it appears that these are not sufficient to
> represent all kinds of relevant units.  In particular, I was at some point
> hoping to completely work in deunitized data internally, *including the
> plotting*, and rely on the fact that if the deunitized and the unitized
> data are usually linked by an affine transform, so the plotting part
> doesn't need to convert back to unitized data and we only need to place and
> label the ticks accordingly; however Ted mentioned relativistic units,
> which imply the use of a non-affine transform.  So I think it would also be
> really helpful if JPL could release some reasonably documented unit library
> with their actual use cases (and how it differs from pint & astropy.units),
> so that we know better what is actually needed (I believe carrying the JPL
> unit code in our own code base is a mistake).
>
>
> As for the public vs private, or rather unitized vs deunitized API
> discussion, I believe a relatively simple and consistent line would be to
> make Axes methods unitized and everything else deunitized (but with clear
> ways to convert to and from unitized data when not using Axes methods).
>
> Antony
>
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>>>:
> That sounds fine to me.  Our original unit prototype API actually had
> conversions for both directions but I think the float->unit version was
> removed (or really moved) when the ticker/formatter portion of the unit API
> was settled on.
>
> Using floats/numpy arrays internally is going to easier and faster so I
> think that's a plus.  The biggest issue we're going to run in to is what's
> defined as "internal" vs part of the unit API.  Some things are easy like
> the Axes/Axis API.  But we also use low level API's like the patches.  Are
> those unitized?  This is the pro and con of using something like Python
> where basically everything is public.  It makes it possible to do lots of
> things, but it's much harder to define a clear library with a specific
> public API.
>
> Somewhere in the process we should write a proposal that outlines which
> classes/methods are part of the unit api and which are going to be
> considered internal.  I'm sure we can help with that effort.
>
> That also might help clarify/influence code structure - if internal
> implementation classes are placed in a sub-package inside MPL 3.0, it
> becomes clearer to people later on what the "official' public API vs what
> can be optimized to just use floats.  Obviously the dev's would need to
> decide if that kind of restructuring is worth it or not.
>
> Ted
>
> ________________________________________
> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com
> <dstansby at gmail.com>>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> 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<mailto:
> jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
> <jklymak at uvic.ca><mailto:jklymak at uvic.ca <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<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov
> <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<mailto:jpl.nasa.gov at python.org
> <jpl.nasa.gov at python.org>><mailto:jpl.nasa.gov at python.org
> <jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org
> <jpl.nasa.gov at python.org>>>> on behalf of Jody Klymak <jklymak at uvic.ca<
> mailto:jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
> <jklymak at uvic.ca><mailto:jklymak at uvic.ca <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<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <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/20180208/027540af/attachment-0001.html>

From antony.lee at berkeley.edu  Thu Feb  8 13:16:25 2018
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 8 Feb 2018 19:16:25 +0100
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGm9cHDQ0prB08pmBq37hktoVExnkV=BTshioOJhAd=0-A2OHg@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <CAGm9cHDQ0prB08pmBq37hktoVExnkV=BTshioOJhAd=0-A2OHg@mail.gmail.com>
Message-ID: <CAGRr6BFW0EE0xcfzzsFE+dRWh+Ekb9PPj00WQUN=1+Sr9+U7+g@mail.gmail.com>

If you think you can make this work, I'm all for it.  This would definitely
be a project where I think a large PR covering many changes would be nicer
(well, it'd still be hell to review...) to convince us skeptics :-) that
the approach is indeed viable.
Antony

2018-02-08 19:02 GMT+01:00 David Stansby <dstansby at gmail.com>:

> *puts hand up* I'm (sort of...) a Matplotlib developer and use (am
> starting to use) units in my day to day research.
>
> My proposal remains this:
>
>    - The user provides a method for converting objects of their custom
>    class to a floating point numbers
>    - The user provides a method for converting floating point numbers to
>    their custom class
>    - *Everything *in Matplotlib that accepts data accepts custom type
>    objects
>    - The first thing it does is convert these objects to floats, and then
>    everything we do internally is with those floats
>
> Can anyone point out reasons that this isn't the right way to do it? This
> has the advantages:
>
>    - Matplotlib takes no responsibility for the conversion
>    - We only every calculate with floats
>    - You can use whatever objects you want, as long as your converter
>    goes object --> float
>
> Having thought a little bit this seems like the obvious way to do it, but
> I may be missing something.
>
> David
>
> On 8 February 2018 at 17:39, Jody Klymak <jklymak at uvic.ca> wrote:
>
>>
>> I realize that units are "a pain", but they're hugely useful.  Just
>> plotting datetimes is going to be a pain without units (and was a huge pain
>> before the unit system).  The proposal that only Axes supports units is
>> going to cause us a massive problem as that's rarely everything that we do
>> with a plot.  I could do a survey to find all the interactions we use (and
>> that doesn't even touch the 1000's of lines of code our users have written)
>> if that would help but anything that's part of the public api (axes,
>> artists, patches, etc) is probably being used - i.e. pretty much anything
>> that's in the current user's guide is something that we use/want/need to
>> work with unitized data.
>>
>>
>> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
>>
>> 1) develop better toy unit module that has most of the desired features
>> (maybe the existing one is fine, but please see
>> https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a
>> little dismayed with the state of things).
>>
>> 2) write a developer?s guide explaining how units should be/are
>> implemented
>> a) in matplotlib modules
>>         b) by downstream developers (this is probably adequate already).
>>
>> It sounds like what you are saying is that units should be carried to the
>> draw stage (or cache stage) for all artists.  Thats maybe fine, but as a
>> new developer, I found the units support woefully under-documented.  The
>> fact that others have hacked in units support in various inconsistent ways
>> means that we need to police all this better.
>>
>> OTOH, maybe Antony and I are poor people to lead this charge, given that
>> we don?t need unit support.  But I don?t think we are being hypercritical
>> in pointing out it needs work.
>>
>> Thanks a lot,   Jody
>>
>>
>> This is kind of what I meant in my previous email about use cases.
>> Saying "just Axes has units" is basically saying the only valid unit use
>> case is create a plot one time and look at it.  You can't manipulate it,
>> edit it, or build any kind of plotting GUI application (which we have many
>> of) once the plot has been created.  The Artist classes are one of the
>> primary API's for applications.  Artists are created, edited, and
>> manipulated if you want to allow the user to modify things in a plot after
>> it's created.    Even the most basic cases like calling Line2D.set_data()
>> wouldn't be allowed with units if only Axes has unit support.
>>
>> I'm not sure I understand the statement that units are a moving target.
>> The reason it keeps popping up is that code gets added without something
>> considering units which then triggers a bug reports which require fixing.
>> If there was a clearer policy and new code was required to have test cases
>> that cover non-unit and unit inputs, I think things would go much
>> smoother.  We'd be happy to help with submitting new test cases to cover
>> unit cases in existing code once a policy is decided on.  Maybe what's
>> needed is better documentation for developers who don't use units so they
>> can easily write a test case with units when adding/modifying
>> functionality.
>>
>> Ted
>>
>> ________________________________________
>> From: anntzer.lee at gmail.com <anntzer.lee at gmail.com> on behalf of Antony
>> Lee <antony.lee at berkeley.edu>
>> Sent: Thursday, February 8, 2018 8:09 AM
>> To: Drain, Theodore R (392P)
>> Cc: matplotlib development list
>> Subject: Re: [Matplotlib-devel] Units discussion...
>>
>> I'm momentarily a bit away from Matplotlib development due to real life
>> piling up, so I'll just keep this short.
>>
>> One major point (already mentioned by others) that led, I think, to some
>> devs (including myself) being relatively dismissive about unit support is
>> the lack of well-defined use case, other than "it'd be nice if we supported
>> units" (i.e., especially from the point of view of devs who *don't* use
>> units themselves, it ends up being an ever moving target). In particular,
>> tests on unit support ("unit unit tests"? :-)) currently only rely on the
>> old JPL unit code that ended up integrated into Matplotlib's test suite,
>> but does not test integration with the two major unit packages I am aware
>> of (pint and astropy.units).
>>
>> From the email of Ted it appears that these are not sufficient to
>> represent all kinds of relevant units.  In particular, I was at some point
>> hoping to completely work in deunitized data internally, *including the
>> plotting*, and rely on the fact that if the deunitized and the unitized
>> data are usually linked by an affine transform, so the plotting part
>> doesn't need to convert back to unitized data and we only need to place and
>> label the ticks accordingly; however Ted mentioned relativistic units,
>> which imply the use of a non-affine transform.  So I think it would also be
>> really helpful if JPL could release some reasonably documented unit library
>> with their actual use cases (and how it differs from pint & astropy.units),
>> so that we know better what is actually needed (I believe carrying the JPL
>> unit code in our own code base is a mistake).
>>
>>
>> As for the public vs private, or rather unitized vs deunitized API
>> discussion, I believe a relatively simple and consistent line would be to
>> make Axes methods unitized and everything else deunitized (but with clear
>> ways to convert to and from unitized data when not using Axes methods).
>>
>> Antony
>>
>> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
>> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov>>>:
>> That sounds fine to me.  Our original unit prototype API actually had
>> conversions for both directions but I think the float->unit version was
>> removed (or really moved) when the ticker/formatter portion of the unit API
>> was settled on.
>>
>> Using floats/numpy arrays internally is going to easier and faster so I
>> think that's a plus.  The biggest issue we're going to run in to is what's
>> defined as "internal" vs part of the unit API.  Some things are easy like
>> the Axes/Axis API.  But we also use low level API's like the patches.  Are
>> those unitized?  This is the pro and con of using something like Python
>> where basically everything is public.  It makes it possible to do lots of
>> things, but it's much harder to define a clear library with a specific
>> public API.
>>
>> Somewhere in the process we should write a proposal that outlines which
>> classes/methods are part of the unit api and which are going to be
>> considered internal.  I'm sure we can help with that effort.
>>
>> That also might help clarify/influence code structure - if internal
>> implementation classes are placed in a sub-package inside MPL 3.0, it
>> becomes clearer to people later on what the "official' public API vs what
>> can be optimized to just use floats.  Obviously the dev's would need to
>> decide if that kind of restructuring is worth it or not.
>>
>> Ted
>>
>> ________________________________________
>> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com
>> <dstansby at gmail.com>>>
>> Sent: Wednesday, February 7, 2018 3:42 AM
>> To: Jody Klymak
>> Cc: Drain, Theodore R (392P); matplotlib development list
>> Subject: Re: [Matplotlib-devel] Units discussion...
>>
>> 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<mailto:jklyma
>> k at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca <jklymak at uvic.ca><
>> mailto:jklymak at uvic.ca <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<mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov
>> <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<mailto:jpl.nasa.gov at python.org
>> <jpl.nasa.gov at python.org>><mailto:jpl.nasa.gov at python.org
>> <jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org
>> <jpl.nasa.gov at python.org>>>> on behalf of Jody Klymak <jklymak at uvic.ca<
>> mailto:jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
>> <jklymak at uvic.ca><mailto:jklymak at uvic.ca <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<mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>>>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>>>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>>>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
>> <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/20180208/1e55cb2a/attachment-0001.html>

From theodore.r.drain at jpl.nasa.gov  Thu Feb  8 13:40:53 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Thu, 8 Feb 2018 18:40:53 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGRr6BFW0EE0xcfzzsFE+dRWh+Ekb9PPj00WQUN=1+Sr9+U7+g@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <CAGm9cHDQ0prB08pmBq37hktoVExnkV=BTshioOJhAd=0-A2OHg@mail.gmail.com>,
 <CAGRr6BFW0EE0xcfzzsFE+dRWh+Ekb9PPj00WQUN=1+Sr9+U7+g@mail.gmail.com>
Message-ID: <b1622a0f72834376a190ca4949c24f74@jpl.nasa.gov>

It sounds like the solution to not supporting units everywhere was to tell users to add a one line call to all inputs and a one line call to all outputs to convert to/from floats.  So if that's a viable solution, then doesn't it follow that having that code in the library is also a viable solution? And isn't that the point of a library to reduce the same code being written over and over again?  I'm not saying it's not work.  But I don't see any concrete problems with the approach being put forth.  

One possible plan might be:

1) Decide on the data management approach.  Starting with something like "units are removed and added at the function interface points and not kept internally" might be a fine.  So basically classes have to do the input->internal conversion for inputs and the internal->output conversion for return values but unitized data is not kept internally.  This does require that unit converters also handle non-unitized data as MPL classes will be calling other methods with their internal data (non-unitized) but that shouldn't be a huge problem.  This might also lead to a class hierarchy of unit converters where a user converter tries to handle the data and if it can't, it calls the base converter which handles floats, numpy, arrays, etc.

2) Update the doc processing (or just codify a standard) to identify unit supporting methods.  Add developer docs to explain how and where external<->internal data conversions should occur.

3) Implement "standard" date and unit test classes and converters to use for all test cases

4) Create a prioritized list of the API's to work on.  Start with Axes and add standardized unit handling in all of those methods first (or maybe prioritize the methods in Axes since there are a lot of them).  Ideally, this includes updating the docs and having unit and non-unit test cases for each.  Once that's done and proves the concept, start working through the underlying Artist's and Patches as time permits.  

I think this approach allows individual methods to be updated and tested.  They don't all have to be done at once and since the converter has to handle non-unitized data, this shouldn't break existing code.  It seems like each method in Axes can be it's own PR w/ test case to make review and merging simpler.  Working from the top (Axes) down also means that the internal classes don't need to be changed.

I can probably help w/ resources for doing this but I'll have to check on availability once a plan is finalized.

Ted



________________________________________
From: Matplotlib-devel <matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org> on behalf of Antony Lee <antony.lee at berkeley.edu>
Sent: Thursday, February 8, 2018 10:16 AM
To: David Stansby
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

If you think you can make this work, I'm all for it.  This would definitely be a project where I think a large PR covering many changes would be nicer (well, it'd still be hell to review...) to convince us skeptics :-) that the approach is indeed viable.
Antony

2018-02-08 19:02 GMT+01:00 David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com>>:
*puts hand up* I'm (sort of...) a Matplotlib developer and use (am starting to use) units in my day to day research.

My proposal remains this:

  *   The user provides a method for converting objects of their custom class to a floating point numbers
  *   The user provides a method for converting floating point numbers to their custom class
  *   Everything in Matplotlib that accepts data accepts custom type objects
  *   The first thing it does is convert these objects to floats, and then everything we do internally is with those floats

Can anyone point out reasons that this isn't the right way to do it? This has the advantages:

  *   Matplotlib takes no responsibility for the conversion
  *   We only every calculate with floats
  *   You can use whatever objects you want, as long as your converter goes object --> float

Having thought a little bit this seems like the obvious way to do it, but I may be missing something.

David

On 8 February 2018 at 17:39, Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca>> wrote:

I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data.

OK, *for discussion*: A scope of work for JPL and Matplotlib might be:

1) develop better toy unit module that has most of the desired features (maybe the existing one is fine, but please see https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little dismayed with the state of things).

2) write a developer?s guide explaining how units should be/are implemented
a) in matplotlib modules
        b) by downstream developers (this is probably adequate already).

It sounds like what you are saying is that units should be carried to the draw stage (or cache stage) for all artists.  Thats maybe fine, but as a new developer, I found the units support woefully under-documented.  The fact that others have hacked in units support in various inconsistent ways means that we need to police all this better.

OTOH, maybe Antony and I are poor people to lead this charge, given that we don?t need unit support.  But I don?t think we are being hypercritical in pointing out it needs work.

Thanks a lot,   Jody


This is kind of what I meant in my previous email about use cases.  Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.

I'm not sure I understand the statement that units are a moving target.  The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.

Ted

________________________________________
From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com> <anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com>> on behalf of Antony Lee <antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu>>
Sent: Thursday, February 8, 2018 8:09 AM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.

One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target). In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).

>From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).

As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).

Antony

2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov>>:
That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.

Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.

Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.

That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.

Ted

________________________________________
From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com><mailto:dstansby at gmail.com>>
Sent: Wednesday, February 7, 2018 3:42 AM
To: Jody Klymak
Cc: Drain, Theodore R (392P); matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

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<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov<mailto: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<mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org<mailto:jpl.nasa.gov at python.org>>> on behalf of Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel



_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel



From jklymak at uvic.ca  Thu Feb  8 13:48:57 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 8 Feb 2018 10:48:57 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
Message-ID: <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>



> On 8 Feb 2018, at 09:54, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov> wrote:
> 
> I think we can help with building a better toy unit system.  Or we can standardize on datetime and some existing unit package.  Whatever makes it easier for people to write test cases.

For me, the problem w/ datetime is that it is not fully featured units handling in that it doesn?t support multiple units.  Its really just a class of data that we have known conversion to float for. 

What we need an example of is how the following should work. 

```python
x = np.arange(10)
y = x*2 * myunitclass.in
ax.plot(x, y)
z = x*2 * myunitclass.cm
ax.plot(x, z)

```

So when a new feature is added, we can ask that its units support is made clear.  I guess I don?t mind if those are astropy units or yt units, or pint, or?? though there will be some pushback about including another test dependency.  

Would pint units work?  Its a very small dependency, but maybe not as full featured or structured wildly differently from the others?  

A test suite to my mind would 
 - test basic functionality
 - test mixing allowed dimensions (i.e. inches and centimeters)
 - test changing the axis units (so all the plotted data changes its values, *or* the tick locators/formatters change their values).
 - test that disallowed mixed dimensions fail.
 - ??

Cheers,  Jody









> ________________________________________
> From: Jody Klymak <jklymak at uvic.ca <mailto:jklymak at uvic.ca>>
> Sent: Thursday, February 8, 2018 9:39 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data.
> 
> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
> 
> 1) develop better toy unit module that has most of the desired features (maybe the existing one is fine, but please see https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little dismayed with the state of things).
> 
> 2) write a developer?s guide explaining how units should be/are implemented
> a) in matplotlib modules
>        b) by downstream developers (this is probably adequate already).
> 
> It sounds like what you are saying is that units should be carried to the draw stage (or cache stage) for all artists.  Thats maybe fine, but as a new developer, I found the units support woefully under-documented. The fact that others have hacked in units support in various inconsistent ways means that we need to police all this better.
> 
> OTOH, maybe Antony and I are poor people to lead this charge, given that we don?t need unit support.  But I don?t think we are being hypercritical in pointing out it needs work.
> 
> Thanks a lot,   Jody
> 
> 
> This is kind of what I meant in my previous email about use cases. Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.
> 
> I'm not sure I understand the statement that units are a moving target. The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.
> 
> Ted
> 
> ________________________________________
> From: anntzer.lee at gmail.com <mailto:anntzer.lee at gmail.com><mailto:anntzer.lee at gmail.com <mailto:anntzer.lee at gmail.com>> <anntzer.lee at gmail.com <mailto:anntzer.lee at gmail.com><mailto:anntzer.lee at gmail.com <mailto:anntzer.lee at gmail.com>>> on behalf of Antony Lee <antony.lee at berkeley.edu <mailto:antony.lee at berkeley.edu><mailto:antony.lee at berkeley.edu <mailto:antony.lee at berkeley.edu>>>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.
> 
> One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target). In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).
> 
>> From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).
> 
> As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).
> 
> Antony
> 
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>>>:
> That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.
> 
> Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.
> 
> Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.
> 
> That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.
> 
> Ted
> 
> ________________________________________
> From: David Stansby <dstansby at gmail.com <mailto:dstansby at gmail.com><mailto:dstansby at gmail.com <mailto:dstansby at gmail.com>><mailto:dstansby at gmail.com <mailto:dstansby at gmail.com>>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> 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 <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca>><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca>><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto: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 <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto: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 <mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org <mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org>><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org>><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org <mailto:jpl.nasa.gov at python.org>>>> on behalf of Jody Klymak <jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca>><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca>><mailto:jklymak at uvic.ca <mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca <mailto: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 <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel <https://mail.python.org/mailman/listinfo/matplotlib-devel>
--
Jody Klymak    
http://web.uvic.ca/~jklymak/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/f48d7de2/attachment-0001.html>

From nathan12343 at gmail.com  Thu Feb  8 13:52:04 2018
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Thu, 8 Feb 2018 12:52:04 -0600
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
Message-ID: <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>

On Thu, Feb 8, 2018 at 12:48 PM, Jody Klymak <jklymak at uvic.ca> wrote:

>
>
> On 8 Feb 2018, at 09:54, Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov> wrote:
>
> I think we can help with building a better toy unit system.  Or we can
> standardize on datetime and some existing unit package.  Whatever makes it
> easier for people to write test cases.
>
>
> For me, the problem w/ datetime is that it is not fully featured units
> handling in that it doesn?t support multiple units.  Its really just a
> class of data that we have known conversion to float for.
>
> What we need an example of is how the following should work.
>
> ```python
> x = np.arange(10)
> y = x*2 * myunitclass.in
> ax.plot(x, y)
> z = x*2 * myunitclass.cm
> ax.plot(x, z)
>
> ```
>
> So when a new feature is added, we can ask that its units support is made
> clear.  I guess I don?t mind if those are astropy units or yt units, or
> pint, or?? though there will be some pushback about including another test
> dependency.
>
> Would pint units work?  Its a very small dependency, but maybe not as full
> featured or structured wildly differently from the others?
>

One wrinkle: pint implements a "wrapper" array class rather than an ndarray
subclass. Both astropy and yt use and ndarray subclass. There are some
classes of errors that only happen for one style of unit arrays and other
classes of errors that only happen for the other.


>
> A test suite to my mind would
>  - test basic functionality
>  - test mixing allowed dimensions (i.e. inches and centimeters)
>  - test changing the axis units (so all the plotted data changes its
> values, *or* the tick locators/formatters change their values).
>  - test that disallowed mixed dimensions fail.
>  - ??
>
> Cheers,  Jody
>
>
>
>
>
>
>
>
>
> ________________________________________
> From: Jody Klymak <jklymak at uvic.ca>
> Sent: Thursday, February 8, 2018 9:39 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> I realize that units are "a pain", but they're hugely useful.  Just
> plotting datetimes is going to be a pain without units (and was a huge pain
> before the unit system).  The proposal that only Axes supports units is
> going to cause us a massive problem as that's rarely everything that we do
> with a plot.  I could do a survey to find all the interactions we use (and
> that doesn't even touch the 1000's of lines of code our users have written)
> if that would help but anything that's part of the public api (axes,
> artists, patches, etc) is probably being used - i.e. pretty much anything
> that's in the current user's guide is something that we use/want/need to
> work with unitized data.
>
> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
>
> 1) develop better toy unit module that has most of the desired features
> (maybe the existing one is fine, but please see
> https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little
> dismayed with the state of things).
>
> 2) write a developer?s guide explaining how units should be/are implemented
> a) in matplotlib modules
>        b) by downstream developers (this is probably adequate already).
>
> It sounds like what you are saying is that units should be carried to the
> draw stage (or cache stage) for all artists.  Thats maybe fine, but as a
> new developer, I found the units support woefully under-documented. The
> fact that others have hacked in units support in various inconsistent ways
> means that we need to police all this better.
>
> OTOH, maybe Antony and I are poor people to lead this charge, given that
> we don?t need unit support.  But I don?t think we are being hypercritical
> in pointing out it needs work.
>
> Thanks a lot,   Jody
>
>
> This is kind of what I meant in my previous email about use cases. Saying
> "just Axes has units" is basically saying the only valid unit use case is
> create a plot one time and look at it.  You can't manipulate it, edit it,
> or build any kind of plotting GUI application (which we have many of) once
> the plot has been created.  The Artist classes are one of the primary API's
> for applications.  Artists are created, edited, and manipulated if you want
> to allow the user to modify things in a plot after it's created.    Even
> the most basic cases like calling Line2D.set_data() wouldn't be allowed
> with units if only Axes has unit support.
>
> I'm not sure I understand the statement that units are a moving target.
> The reason it keeps popping up is that code gets added without something
> considering units which then triggers a bug reports which require fixing.
> If there was a clearer policy and new code was required to have test cases
> that cover non-unit and unit inputs, I think things would go much
> smoother.  We'd be happy to help with submitting new test cases to cover
> unit cases in existing code once a policy is decided on.  Maybe what's
> needed is better documentation for developers who don't use units so they
> can easily write a test case with units when adding/modifying functionality.
>
> Ted
>
> ________________________________________
> From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com
> <anntzer.lee at gmail.com>> <anntzer.lee at gmail.com<mailto:
> anntzer.lee at gmail.com <anntzer.lee at gmail.com>>> on behalf of Antony Lee <
> antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu
> <antony.lee at berkeley.edu>>>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> I'm momentarily a bit away from Matplotlib development due to real life
> piling up, so I'll just keep this short.
>
> One major point (already mentioned by others) that led, I think, to some
> devs (including myself) being relatively dismissive about unit support is
> the lack of well-defined use case, other than "it'd be nice if we supported
> units" (i.e., especially from the point of view of devs who *don't* use
> units themselves, it ends up being an ever moving target). In particular,
> tests on unit support ("unit unit tests"? :-)) currently only rely on the
> old JPL unit code that ended up integrated into Matplotlib's test suite,
> but does not test integration with the two major unit packages I am aware
> of (pint and astropy.units).
>
> From the email of Ted it appears that these are not sufficient to
> represent all kinds of relevant units.  In particular, I was at some point
> hoping to completely work in deunitized data internally, *including the
> plotting*, and rely on the fact that if the deunitized and the unitized
> data are usually linked by an affine transform, so the plotting part
> doesn't need to convert back to unitized data and we only need to place and
> label the ticks accordingly; however Ted mentioned relativistic units,
> which imply the use of a non-affine transform.  So I think it would also be
> really helpful if JPL could release some reasonably documented unit library
> with their actual use cases (and how it differs from pint & astropy.units),
> so that we know better what is actually needed (I believe carrying the JPL
> unit code in our own code base is a mistake).
>
>
> As for the public vs private, or rather unitized vs deunitized API
> discussion, I believe a relatively simple and consistent line would be to
> make Axes methods unitized and everything else deunitized (but with clear
> ways to convert to and from unitized data when not using Axes methods).
>
> Antony
>
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>>>:
> That sounds fine to me.  Our original unit prototype API actually had
> conversions for both directions but I think the float->unit version was
> removed (or really moved) when the ticker/formatter portion of the unit API
> was settled on.
>
> Using floats/numpy arrays internally is going to easier and faster so I
> think that's a plus.  The biggest issue we're going to run in to is what's
> defined as "internal" vs part of the unit API.  Some things are easy like
> the Axes/Axis API.  But we also use low level API's like the patches.  Are
> those unitized?  This is the pro and con of using something like Python
> where basically everything is public.  It makes it possible to do lots of
> things, but it's much harder to define a clear library with a specific
> public API.
>
> Somewhere in the process we should write a proposal that outlines which
> classes/methods are part of the unit api and which are going to be
> considered internal.  I'm sure we can help with that effort.
>
> That also might help clarify/influence code structure - if internal
> implementation classes are placed in a sub-package inside MPL 3.0, it
> becomes clearer to people later on what the "official' public API vs what
> can be optimized to just use floats.  Obviously the dev's would need to
> decide if that kind of restructuring is worth it or not.
>
> Ted
>
> ________________________________________
> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com
> <dstansby at gmail.com>><mailto:dstansby at gmail.com <dstansby at gmail.com>>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> 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<mailto:
> jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
> <jklymak at uvic.ca>><mailto:jklymak at uvic.ca <jklymak at uvic.ca><mailto:
> jklymak at uvic.ca <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<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov
> <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<mailto:matplotlib-devel-
> bounces+ted.drain=jpl.nasa.gov at python.org
> <matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org>><mailto:jpl.
> nasa.gov at python.org <jpl.nasa.gov at python.org>><mailto:
> jpl.nasa.gov at python.org <jpl.nasa.gov at python.org><mailto
> :jpl.nasa.gov at python.org <jpl.nasa.gov at python.org>>>> on behalf of Jody
> Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca <jklymak at uvic.ca>><mailto:
> jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
> <jklymak at uvic.ca><mailto:jklymak at uvic.ca <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<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
> --
> Jody Klymak
> http://web.uvic.ca/~jklymak/
>
>
>
>
>
>
> _______________________________________________
> 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/20180208/06a31652/attachment-0001.html>

From jklymak at uvic.ca  Thu Feb  8 14:06:56 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 8 Feb 2018 11:06:56 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
Message-ID: <07C7001B-806B-4F68-8415-6FB6D859075E@uvic.ca>



> One wrinkle: pint implements a "wrapper" array class rather than an ndarray subclass. Both astropy and yt use and ndarray subclass. There are some classes of errors that only happen for one style of unit arrays and other classes of errors that only happen for the other.


OK. glad I asked.  Is that the case w/ JPL units as well?  If that stipulation makes things easier, maybe se could enforce it?  

Is there a smaller library that subclasses ndarray for units support?  I imagine we could vendorize a subset of whatever astropy or yt do.  Or maybe they aren?t so huge that they would be unreasonable to make as test dependencies.  yt is only 68 Mb.


Cheers,   Jody

--
Jody Klymak    
http://web.uvic.ca/~jklymak/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/6efbc3b8/attachment.html>

From theodore.r.drain at jpl.nasa.gov  Thu Feb  8 14:08:18 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Thu, 8 Feb 2018 19:08:18 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>,
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
Message-ID: <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>

Does numpy subclassing really matter?  If the docs say the unit converter must convert from the external type to the internal type, then as long as the converter does that, it doesn't matter what the external type is or what it inherits from right?  The point is that the converter class is the only class manipulating the external data objects - MPL shouldn't care what they are or what they inherit from.

I think one issue is that data types are malleable in the API right now.  Lists, tuples, numpy, ints, floats, etc are all possible inputs in many/most cases.  IMO, the unit API should not be malleable at all.  The unit converter API should say that the return type of external->internal conversion is always a specific value type (e.g. list of float, numpy float 64 array).

Jody: IMO, your example should plot the data in inches in the first plot call, then convert the second input to inches and plot that.  The plot calls supports the xunits keyword argument which tells the converter what floating point unit conversion to apply.  If that keyword is not specified, then it defaults to the type of the input.  The example that needs to be more clear is if I do this:

ax.plot( x1, y1, xunits="km" )
ax.plot( x2, y2, xunits="miles" )

IMO, either the floats are km or miles, not both.  So either the first call sticks the converter to using km and the second xunits is ignored.  Or the second input overrides the first and requires that the first artists go back through a conversion to miles.  Either is a reasonable choice for behavior (but the first is much easier to implement).

________________________________________
From: Nathan Goldbaum <nathan12343 at gmail.com>
Sent: Thursday, February 8, 2018 10:52 AM
To: Jody Klymak
Cc: Drain, Theodore R (392P); matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

On Thu, Feb 8, 2018 at 12:48 PM, Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca>> wrote:


On 8 Feb 2018, at 09:54, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>> wrote:

I think we can help with building a better toy unit system.  Or we can standardize on datetime and some existing unit package.  Whatever makes it easier for people to write test cases.

For me, the problem w/ datetime is that it is not fully featured units handling in that it doesn?t support multiple units.  Its really just a class of data that we have known conversion to float for.

What we need an example of is how the following should work.

```python
x = np.arange(10)
y = x*2 * myunitclass.in<http://myunitclass.in>
ax.plot(x, y)
z = x*2 * myunitclass.cm<http://myunitclass.cm>
ax.plot(x, z)

```

So when a new feature is added, we can ask that its units support is made clear.  I guess I don?t mind if those are astropy units or yt units, or pint, or?? though there will be some pushback about including another test dependency.

Would pint units work?  Its a very small dependency, but maybe not as full featured or structured wildly differently from the others?

One wrinkle: pint implements a "wrapper" array class rather than an ndarray subclass. Both astropy and yt use and ndarray subclass. There are some classes of errors that only happen for one style of unit arrays and other classes of errors that only happen for the other.


A test suite to my mind would
 - test basic functionality
 - test mixing allowed dimensions (i.e. inches and centimeters)
 - test changing the axis units (so all the plotted data changes its values, *or* the tick locators/formatters change their values).
 - test that disallowed mixed dimensions fail.
 - ??

Cheers,  Jody









________________________________________
From: Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca>>
Sent: Thursday, February 8, 2018 9:39 AM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data.

OK, *for discussion*: A scope of work for JPL and Matplotlib might be:

1) develop better toy unit module that has most of the desired features (maybe the existing one is fine, but please see https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little dismayed with the state of things).

2) write a developer?s guide explaining how units should be/are implemented
a) in matplotlib modules
       b) by downstream developers (this is probably adequate already).

It sounds like what you are saying is that units should be carried to the draw stage (or cache stage) for all artists.  Thats maybe fine, but as a new developer, I found the units support woefully under-documented. The fact that others have hacked in units support in various inconsistent ways means that we need to police all this better.

OTOH, maybe Antony and I are poor people to lead this charge, given that we don?t need unit support.  But I don?t think we are being hypercritical in pointing out it needs work.

Thanks a lot,   Jody


This is kind of what I meant in my previous email about use cases. Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.

I'm not sure I understand the statement that units are a moving target. The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.

Ted

________________________________________
From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com><mailto:anntzer.lee at gmail.com> <anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com><mailto:anntzer.lee at gmail.com>> on behalf of Antony Lee <antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu><mailto:antony.lee at berkeley.edu>>
Sent: Thursday, February 8, 2018 8:09 AM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.

One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target). In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).

>From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).

As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).

Antony

2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov>>:
That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.

Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.

Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.

That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.

Ted

________________________________________
From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com><mailto:dstansby at gmail.com><mailto:dstansby at gmail.com>>
Sent: Wednesday, February 7, 2018 3:42 AM
To: Jody Klymak
Cc: Drain, Theodore R (392P); matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

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<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov<mailto: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<mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org<mailto:jpl.nasa.gov at python.org>>> on behalf of Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Jody Klymak
http://web.uvic.ca/~jklymak/






_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel



From jklymak at uvic.ca  Thu Feb  8 14:24:08 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 8 Feb 2018 11:24:08 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
Message-ID: <1F3968A6-0C1F-45BA-B248-FF7FE134CA36@uvic.ca>



> On 8 Feb 2018, at 11:08, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov> wrote:
> 
> Does numpy subclassing really matter?  If the docs say the unit converter must convert from the external type to the internal type, then as long as the converter does that, it doesn't matter what the external type is or what it inherits from right?  The point is that the converter class is the only class manipulating the external data objects - MPL shouldn't care what they are or what they inherit from.
> 
> I think one issue is that data types are malleable in the API right now.  Lists, tuples, numpy, ints, floats, etc are all possible inputs in many/most cases.  IMO, the unit API should not be malleable at all.  The unit converter API should say that the return type of external->internal conversion is always a specific value type (e.g. list of float, numpy float 64 array).

Yep, I think we all agree on this, but it ends up being messy?.


> Jody: IMO, your example should plot the data in inches in the first plot call, then convert the second input to inches and plot that.  The plot calls supports the xunits keyword argument which tells the converter what floating point unit conversion to apply.  If that keyword is not specified, then it defaults to the type of the input.  The example that needs to be more clear is if I do this:
> 
> ax.plot( x1, y1, xunits="km" )
> ax.plot( x2, y2, xunits="miles" )
> 
> IMO, either the floats are km or miles, not both.  So either the first call sticks the converter to using km and the second xunits is ignored.  Or the second input overrides the first and requires that the first artists go back through a conversion to miles.  Either is a reasonable choice for behavior (but the first is much easier to implement).

That?d be great.  Thats not what our toy does now.  This way of setting the units is also not very flexible. I could imagine users wanting to change units at some point, either by setting the units in the `ax.plot` calls or explicitly on the `Axis` objects themselves.  If we carry the unitized objects around, and only convert at draw time, post-facto conversion is fine.  If we carry de-unitized data around, then we need an inverse so we can re-convert.  

*My* idea which some others have also esposed, is that the converter converts to floats (likely representing some base unit that makes sense, i.e in the example above ?meters? or ?kilometers?).  The ?xunits? are maleable until draw time, at which point the Formatter and Locator decide how to format themselves.  The xdata is never changed.  Thats basically how our datetime formatting works - it is converted to days since epoch and then the Formatter and Locator decide how to format the axis.  I think this works equally well for other artists plotted in dataspace.  Because you have an inverse function, other tools that rely on getting data-space data like cursor position, making a box, etc, can still return the inverse in apprpriate units.

Cheers,  Jody




> ________________________________________
> From: Nathan Goldbaum <nathan12343 at gmail.com>
> Sent: Thursday, February 8, 2018 10:52 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> On Thu, Feb 8, 2018 at 12:48 PM, Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca>> wrote:
> 
> 
> On 8 Feb 2018, at 09:54, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>> wrote:
> 
> I think we can help with building a better toy unit system.  Or we can standardize on datetime and some existing unit package.  Whatever makes it easier for people to write test cases.
> 
> For me, the problem w/ datetime is that it is not fully featured units handling in that it doesn?t support multiple units.  Its really just a class of data that we have known conversion to float for.
> 
> What we need an example of is how the following should work.
> 
> ```python
> x = np.arange(10)
> y = x*2 * myunitclass.in<http://myunitclass.in>
> ax.plot(x, y)
> z = x*2 * myunitclass.cm<http://myunitclass.cm>
> ax.plot(x, z)
> 
> ```
> 
> So when a new feature is added, we can ask that its units support is made clear.  I guess I don?t mind if those are astropy units or yt units, or pint, or?? though there will be some pushback about including another test dependency.
> 
> Would pint units work?  Its a very small dependency, but maybe not as full featured or structured wildly differently from the others?
> 
> One wrinkle: pint implements a "wrapper" array class rather than an ndarray subclass. Both astropy and yt use and ndarray subclass. There are some classes of errors that only happen for one style of unit arrays and other classes of errors that only happen for the other.
> 
> 
> A test suite to my mind would
> - test basic functionality
> - test mixing allowed dimensions (i.e. inches and centimeters)
> - test changing the axis units (so all the plotted data changes its values, *or* the tick locators/formatters change their values).
> - test that disallowed mixed dimensions fail.
> - ??
> 
> Cheers,  Jody
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ________________________________________
> From: Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca>>
> Sent: Thursday, February 8, 2018 9:39 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> I realize that units are "a pain", but they're hugely useful.  Just plotting datetimes is going to be a pain without units (and was a huge pain before the unit system).  The proposal that only Axes supports units is going to cause us a massive problem as that's rarely everything that we do with a plot.  I could do a survey to find all the interactions we use (and that doesn't even touch the 1000's of lines of code our users have written) if that would help but anything that's part of the public api (axes, artists, patches, etc) is probably being used - i.e. pretty much anything that's in the current user's guide is something that we use/want/need to work with unitized data.
> 
> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
> 
> 1) develop better toy unit module that has most of the desired features (maybe the existing one is fine, but please see https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little dismayed with the state of things).
> 
> 2) write a developer?s guide explaining how units should be/are implemented
> a) in matplotlib modules
>       b) by downstream developers (this is probably adequate already).
> 
> It sounds like what you are saying is that units should be carried to the draw stage (or cache stage) for all artists.  Thats maybe fine, but as a new developer, I found the units support woefully under-documented. The fact that others have hacked in units support in various inconsistent ways means that we need to police all this better.
> 
> OTOH, maybe Antony and I are poor people to lead this charge, given that we don?t need unit support.  But I don?t think we are being hypercritical in pointing out it needs work.
> 
> Thanks a lot,   Jody
> 
> 
> This is kind of what I meant in my previous email about use cases. Saying "just Axes has units" is basically saying the only valid unit use case is create a plot one time and look at it.  You can't manipulate it, edit it, or build any kind of plotting GUI application (which we have many of) once the plot has been created.  The Artist classes are one of the primary API's for applications.  Artists are created, edited, and manipulated if you want to allow the user to modify things in a plot after it's created.    Even the most basic cases like calling Line2D.set_data() wouldn't be allowed with units if only Axes has unit support.
> 
> I'm not sure I understand the statement that units are a moving target. The reason it keeps popping up is that code gets added without something considering units which then triggers a bug reports which require fixing.  If there was a clearer policy and new code was required to have test cases that cover non-unit and unit inputs, I think things would go much smoother.  We'd be happy to help with submitting new test cases to cover unit cases in existing code once a policy is decided on.  Maybe what's needed is better documentation for developers who don't use units so they can easily write a test case with units when adding/modifying functionality.
> 
> Ted
> 
> ________________________________________
> From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com><mailto:anntzer.lee at gmail.com> <anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com><mailto:anntzer.lee at gmail.com>> on behalf of Antony Lee <antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu><mailto:antony.lee at berkeley.edu>>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> I'm momentarily a bit away from Matplotlib development due to real life piling up, so I'll just keep this short.
> 
> One major point (already mentioned by others) that led, I think, to some devs (including myself) being relatively dismissive about unit support is the lack of well-defined use case, other than "it'd be nice if we supported units" (i.e., especially from the point of view of devs who *don't* use units themselves, it ends up being an ever moving target). In particular, tests on unit support ("unit unit tests"? :-)) currently only rely on the old JPL unit code that ended up integrated into Matplotlib's test suite, but does not test integration with the two major unit packages I am aware of (pint and astropy.units).
> 
>> From the email of Ted it appears that these are not sufficient to represent all kinds of relevant units.  In particular, I was at some point hoping to completely work in deunitized data internally, *including the plotting*, and rely on the fact that if the deunitized and the unitized data are usually linked by an affine transform, so the plotting part doesn't need to convert back to unitized data and we only need to place and label the ticks accordingly; however Ted mentioned relativistic units, which imply the use of a non-affine transform.  So I think it would also be really helpful if JPL could release some reasonably documented unit library with their actual use cases (and how it differs from pint & astropy.units), so that we know better what is actually needed (I believe carrying the JPL unit code in our own code base is a mistake).
> 
> As for the public vs private, or rather unitized vs deunitized API discussion, I believe a relatively simple and consistent line would be to make Axes methods unitized and everything else deunitized (but with clear ways to convert to and from unitized data when not using Axes methods).
> 
> Antony
> 
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov>>:
> That sounds fine to me.  Our original unit prototype API actually had conversions for both directions but I think the float->unit version was removed (or really moved) when the ticker/formatter portion of the unit API was settled on.
> 
> Using floats/numpy arrays internally is going to easier and faster so I think that's a plus.  The biggest issue we're going to run in to is what's defined as "internal" vs part of the unit API.  Some things are easy like the Axes/Axis API.  But we also use low level API's like the patches.  Are those unitized?  This is the pro and con of using something like Python where basically everything is public.  It makes it possible to do lots of things, but it's much harder to define a clear library with a specific public API.
> 
> Somewhere in the process we should write a proposal that outlines which classes/methods are part of the unit api and which are going to be considered internal.  I'm sure we can help with that effort.
> 
> That also might help clarify/influence code structure - if internal implementation classes are placed in a sub-package inside MPL 3.0, it becomes clearer to people later on what the "official' public API vs what can be optimized to just use floats.  Obviously the dev's would need to decide if that kind of restructuring is worth it or not.
> 
> Ted
> 
> ________________________________________
> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com><mailto:dstansby at gmail.com><mailto:dstansby at gmail.com>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
> 
> 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<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov<mailto: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<mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org><mailto:jpl.nasa.gov at python.org<mailto:jpl.nasa.gov at python.org>>> on behalf of Jody Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca><mailto:jklymak at uvic.ca<mailto: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<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> --
> Jody Klymak
> http://web.uvic.ca/~jklymak/
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto: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

--
Jody Klymak    
http://web.uvic.ca/~jklymak/






From nathan12343 at gmail.com  Thu Feb  8 15:13:22 2018
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Thu, 8 Feb 2018 14:13:22 -0600
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
Message-ID: <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>

On Thu, Feb 8, 2018 at 1:08 PM, Drain, Theodore R (392P) <
theodore.r.drain at jpl.nasa.gov> wrote:

> Does numpy subclassing really matter?  If the docs say the unit converter
> must convert from the external type to the internal type, then as long as
> the converter does that, it doesn't matter what the external type is or
> what it inherits from right?  The point is that the converter class is the
> only class manipulating the external data objects - MPL shouldn't care what
> they are or what they inherit from.
>

To make my statement more concrete, here's a matplotlib pull request that
fixed a bug that only triggered for astropy and yt but not for pint:

https://github.com/matplotlib/matplotlib/pull/6622

In this case it was an issue because of difference in how NumPy's masked
array deals with ndarray subclasses versus array wrapper classes.


> I think one issue is that data types are malleable in the API right now.
> Lists, tuples, numpy, ints, floats, etc are all possible inputs in
> many/most cases.  IMO, the unit API should not be malleable at all.  The
> unit converter API should say that the return type of external->internal
> conversion is always a specific value type (e.g. list of float, numpy float
> 64 array).
>
> Jody: IMO, your example should plot the data in inches in the first plot
> call, then convert the second input to inches and plot that.  The plot
> calls supports the xunits keyword argument which tells the converter what
> floating point unit conversion to apply.  If that keyword is not specified,
> then it defaults to the type of the input.  The example that needs to be
> more clear is if I do this:
>
> ax.plot( x1, y1, xunits="km" )
> ax.plot( x2, y2, xunits="miles" )
>
> IMO, either the floats are km or miles, not both.  So either the first
> call sticks the converter to using km and the second xunits is ignored.  Or
> the second input overrides the first and requires that the first artists go
> back through a conversion to miles.  Either is a reasonable choice for
> behavior (but the first is much easier to implement).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/07de0b18/attachment-0001.html>

From rmay31 at gmail.com  Thu Feb  8 15:15:10 2018
From: rmay31 at gmail.com (Ryan May)
Date: Thu, 8 Feb 2018 13:15:10 -0700
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
Message-ID: <CAKH0P+VtSYS2DNF+yMpfC1SzVjo3vkuju9oV88SWPQKDV2q62Q@mail.gmail.com>

Hi,

Let me start by saying that this will probably come across as crabby, and I
don't really mean for it to do so. I'm happy people are looking at
improving unit support. HOWEVER, I'm concerned that those trying to push
right now are completely ignorant of what actually exists in matplotlib and
how the rest of the ecosystem of unit packages works, don't have personal
use cases and are completely unclear of what others use cases are, and seem
to be throwing things at the wall as rapidly as possible. For instance,
Anthony:

> One major point (already mentioned by others) that led, I think, to some
devs (including myself) being relatively dismissive about unit support is
the lack of well-defined use case, other than "it'd be nice if we supported
units"
> (i.e., especially from the point of view of devs who *don't* use units
themselves, it ends up being an ever moving target).  In particular, tests
on unit support ("unit unit tests"? :-)) currently only rely on the old JPL
unit code
> that ended up integrated into Matplotlib's test suite, but does not test
integration with the two major unit packages I am aware of (pint and
astropy.units).

False. Until David Stansby's contribution, I wrote every line of code in:
https://github.com/matplotlib/matplotlib/commits/master/lib/matplotlib/tests/test_units.py.
Either way, that test has literally *nothing* to do with JPL's
implementation. (And 30s of github could have revealed this.) I added that
code *literally* to check whether we're properly interfacing with a library
just like pint.

> Is there a smaller library that subclasses ndarray for units support?  I
imagine we could vendorize a subset of whatever astropy or yt do.  Or maybe
they aren?t so huge that they would be unreasonable to make as test
dependencies.  yt is only 68 Mb.

No. Just no. Again, I have stubbed out just fine the functionality within
test_units.py to function just like pint--in about 25 lines. I'm happy to
do so for an ndarray subclass-based one as well.

Now, about the functionality:

> What we need an example of is how the following should work.
> ```python
> x = np.arange(10)
> y  = x*2 * myunitclass.in
> ax.plot(x, y)
> z = x*2 * myunitclass.cm
> ax.plot(x, z)
> ```

That currently works today, and works just fine. Same test file:
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tests/test_units.py#L72-L81
You're plotting things with the same dimensionality, the converter
interface can convert to the units that exist already on the axes. Done.
I'm quite happy with it.

Honestly, I'm not trying to be mean about this. But I come into an email
thread where things are moving so fast, with factually incorrect
information flying around, that I'm simply overwhelmed. (14 messages in 3
hours???) I don't think email is a good place to discuss this.

To be clear, I am *ecstatic* that people are looking at unit challenges,
and I agree that the way we're implementing it in matplotlib is
hacky--handling it uniquely for each plotting method rather than
systematically. And I'm happy to have new voices come in and try to improve
the situation with new ideas. But I see people railing against the current
converter interface as if it's unused, crusty, or otherwise completely
inadequate. The converter WORKS fine. The problem is in that we have to
hook up unit machinery individually to each plotting method, because each
plotting method is its own special snowflake--unique and unlike any other.
What we need is to rationalize the implementation of plots, specifically
the data handling (missing data, units, shape, etc.), and then implementing
units will be a sane task.

Or maybe I'm wrong, and there is some structural deficiency in the current
converter--but I'd at least like to see those arguments coming from a place
knowledge, not conjecture about how this thing may or may not be working
currently, and wild speculation about how it's supposed to work. Contrary
to the "lack of well-defined use case" idea, there are plenty--they might
not be written down, but that doesn't mean they haven't been discussed
before.

Let's find a better venue for this discussion that lends itself for
everyone to join in *together*, synchronously, and in a form where we're
not guessing at tone.

Ryan

On Thu, Feb 8, 2018 at 11:48 AM, Jody Klymak <jklymak at uvic.ca> wrote:

>
>
> On 8 Feb 2018, at 09:54, Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov> wrote:
>
> I think we can help with building a better toy unit system.  Or we can
> standardize on datetime and some existing unit package.  Whatever makes it
> easier for people to write test cases.
>
>
> For me, the problem w/ datetime is that it is not fully featured units
> handling in that it doesn?t support multiple units.  Its really just a
> class of data that we have known conversion to float for.
>
> What we need an example of is how the following should work.
>
> ```python
> x = np.arange(10)
> y = x*2 * myunitclass.in
> ax.plot(x, y)
> z = x*2 * myunitclass.cm
> ax.plot(x, z)
>
> ```
>
> So when a new feature is added, we can ask that its units support is made
> clear.  I guess I don?t mind if those are astropy units or yt units, or
> pint, or?? though there will be some pushback about including another test
> dependency.
>
> Would pint units work?  Its a very small dependency, but maybe not as full
> featured or structured wildly differently from the others?
>
> A test suite to my mind would
>  - test basic functionality
>  - test mixing allowed dimensions (i.e. inches and centimeters)
>  - test changing the axis units (so all the plotted data changes its
> values, *or* the tick locators/formatters change their values).
>  - test that disallowed mixed dimensions fail.
>  - ??
>
> Cheers,  Jody
>
>
>
>
>
>
>
>
>
> ________________________________________
> From: Jody Klymak <jklymak at uvic.ca>
> Sent: Thursday, February 8, 2018 9:39 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> I realize that units are "a pain", but they're hugely useful.  Just
> plotting datetimes is going to be a pain without units (and was a huge pain
> before the unit system).  The proposal that only Axes supports units is
> going to cause us a massive problem as that's rarely everything that we do
> with a plot.  I could do a survey to find all the interactions we use (and
> that doesn't even touch the 1000's of lines of code our users have written)
> if that would help but anything that's part of the public api (axes,
> artists, patches, etc) is probably being used - i.e. pretty much anything
> that's in the current user's guide is something that we use/want/need to
> work with unitized data.
>
> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
>
> 1) develop better toy unit module that has most of the desired features
> (maybe the existing one is fine, but please see
> https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a little
> dismayed with the state of things).
>
> 2) write a developer?s guide explaining how units should be/are implemented
> a) in matplotlib modules
>        b) by downstream developers (this is probably adequate already).
>
> It sounds like what you are saying is that units should be carried to the
> draw stage (or cache stage) for all artists.  Thats maybe fine, but as a
> new developer, I found the units support woefully under-documented. The
> fact that others have hacked in units support in various inconsistent ways
> means that we need to police all this better.
>
> OTOH, maybe Antony and I are poor people to lead this charge, given that
> we don?t need unit support.  But I don?t think we are being hypercritical
> in pointing out it needs work.
>
> Thanks a lot,   Jody
>
>
> This is kind of what I meant in my previous email about use cases. Saying
> "just Axes has units" is basically saying the only valid unit use case is
> create a plot one time and look at it.  You can't manipulate it, edit it,
> or build any kind of plotting GUI application (which we have many of) once
> the plot has been created.  The Artist classes are one of the primary API's
> for applications.  Artists are created, edited, and manipulated if you want
> to allow the user to modify things in a plot after it's created.    Even
> the most basic cases like calling Line2D.set_data() wouldn't be allowed
> with units if only Axes has unit support.
>
> I'm not sure I understand the statement that units are a moving target.
> The reason it keeps popping up is that code gets added without something
> considering units which then triggers a bug reports which require fixing.
> If there was a clearer policy and new code was required to have test cases
> that cover non-unit and unit inputs, I think things would go much
> smoother.  We'd be happy to help with submitting new test cases to cover
> unit cases in existing code once a policy is decided on.  Maybe what's
> needed is better documentation for developers who don't use units so they
> can easily write a test case with units when adding/modifying functionality.
>
> Ted
>
> ________________________________________
> From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com
> <anntzer.lee at gmail.com>> <anntzer.lee at gmail.com<mailto:
> anntzer.lee at gmail.com <anntzer.lee at gmail.com>>> on behalf of Antony Lee <
> antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu
> <antony.lee at berkeley.edu>>>
> Sent: Thursday, February 8, 2018 8:09 AM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> I'm momentarily a bit away from Matplotlib development due to real life
> piling up, so I'll just keep this short.
>
> One major point (already mentioned by others) that led, I think, to some
> devs (including myself) being relatively dismissive about unit support is
> the lack of well-defined use case, other than "it'd be nice if we supported
> units" (i.e., especially from the point of view of devs who *don't* use
> units themselves, it ends up being an ever moving target). In particular,
> tests on unit support ("unit unit tests"? :-)) currently only rely on the
> old JPL unit code that ended up integrated into Matplotlib's test suite,
> but does not test integration with the two major unit packages I am aware
> of (pint and astropy.units).
>
> From the email of Ted it appears that these are not sufficient to
> represent all kinds of relevant units.  In particular, I was at some point
> hoping to completely work in deunitized data internally, *including the
> plotting*, and rely on the fact that if the deunitized and the unitized
> data are usually linked by an affine transform, so the plotting part
> doesn't need to convert back to unitized data and we only need to place and
> label the ticks accordingly; however Ted mentioned relativistic units,
> which imply the use of a non-affine transform.  So I think it would also be
> really helpful if JPL could release some reasonably documented unit library
> with their actual use cases (and how it differs from pint & astropy.units),
> so that we know better what is actually needed (I believe carrying the JPL
> unit code in our own code base is a mistake).
>
>
> As for the public vs private, or rather unitized vs deunitized API
> discussion, I believe a relatively simple and consistent line would be to
> make Axes methods unitized and everything else deunitized (but with clear
> ways to convert to and from unitized data when not using Axes methods).
>
> Antony
>
> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>>>:
> That sounds fine to me.  Our original unit prototype API actually had
> conversions for both directions but I think the float->unit version was
> removed (or really moved) when the ticker/formatter portion of the unit API
> was settled on.
>
> Using floats/numpy arrays internally is going to easier and faster so I
> think that's a plus.  The biggest issue we're going to run in to is what's
> defined as "internal" vs part of the unit API.  Some things are easy like
> the Axes/Axis API.  But we also use low level API's like the patches.  Are
> those unitized?  This is the pro and con of using something like Python
> where basically everything is public.  It makes it possible to do lots of
> things, but it's much harder to define a clear library with a specific
> public API.
>
> Somewhere in the process we should write a proposal that outlines which
> classes/methods are part of the unit api and which are going to be
> considered internal.  I'm sure we can help with that effort.
>
> That also might help clarify/influence code structure - if internal
> implementation classes are placed in a sub-package inside MPL 3.0, it
> becomes clearer to people later on what the "official' public API vs what
> can be optimized to just use floats.  Obviously the dev's would need to
> decide if that kind of restructuring is worth it or not.
>
> Ted
>
> ________________________________________
> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com
> <dstansby at gmail.com>><mailto:dstansby at gmail.com <dstansby at gmail.com>>>
> Sent: Wednesday, February 7, 2018 3:42 AM
> To: Jody Klymak
> Cc: Drain, Theodore R (392P); matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> 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<mailto:
> jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
> <jklymak at uvic.ca>><mailto:jklymak at uvic.ca <jklymak at uvic.ca><mailto:
> jklymak at uvic.ca <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<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov
> <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<mailto:matplotlib-devel-
> bounces+ted.drain=jpl.nasa.gov at python.org
> <matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org>><mailto:jpl.
> nasa.gov at python.org <jpl.nasa.gov at python.org>><mailto:
> jpl.nasa.gov at python.org <jpl.nasa.gov at python.org><mailto
> :jpl.nasa.gov at python.org <jpl.nasa.gov at python.org>>>> on behalf of Jody
> Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca <jklymak at uvic.ca>><mailto:
> jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
> <jklymak at uvic.ca><mailto:jklymak at uvic.ca <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<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
> <Matplotlib-devel at python.org>>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
> --
> Jody Klymak
> http://web.uvic.ca/~jklymak/
>
>
>
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>


-- 
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/62eb36e5/attachment-0001.html>

From matti.picus at gmail.com  Thu Feb  8 15:22:09 2018
From: matti.picus at gmail.com (Matti Picus)
Date: Thu, 8 Feb 2018 15:22:09 -0500
Subject: [Matplotlib-devel] Matplotlib-devel Digest, Vol 31, Issue 18
In-Reply-To: <mailman.1537.1518120934.27155.matplotlib-devel@python.org>
References: <mailman.1537.1518120934.27155.matplotlib-devel@python.org>
Message-ID: <dd097358-f6f6-45bb-6a60-488c32a4e53d@gmail.com>

There is this "Matplotlib Enhancement Proposals" 
https://matplotlib.org/devel/MEP/index.html which I guess starts as a 
pull request with a new MEP, and discussion continues on github under 
the pull request?

Matti


On 2/8/2018 3:15 PM, matplotlib-devel-request at python.org wrote:
> Let's find a better venue for this discussion that lends itself for
> everyone to join in*together*, synchronously, and in a form where we're
> not guessing at tone.


From antony.lee at berkeley.edu  Thu Feb  8 15:49:35 2018
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 8 Feb 2018 21:49:35 +0100
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAKH0P+VtSYS2DNF+yMpfC1SzVjo3vkuju9oV88SWPQKDV2q62Q@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAKH0P+VtSYS2DNF+yMpfC1SzVjo3vkuju9oV88SWPQKDV2q62Q@mail.gmail.com>
Message-ID: <CAGRr6BGgqA4Bv6zbOgbkbAcAH7E=62z+pYovVo0Zitj15=RSkg@mail.gmail.com>

I apologize for the erroneous statements I have made regarding tests.  I
should, in fact, be well aware of test_units, having had to fight with it
when fixing PR#9774 (see the part modifying axes/_base.py).  However, my
intent (and again, I readily admit I wrote something else and that was
incorrect) was that the test is against our own mocking of a minimal unit
system, rather than an external, actually used one.  In other words, I
would much prefer actually bringing in pint as a test dependency (at least
for CI -- we can always locally skipif it), and whatever else we need to
cover all cases.  Why?  Because, for someone who is not a unit specialist,
how do I know whether your mock unit class is actually relevant and has
anything to do with "real-life" units?

There may not be a fundamental structural deficiency in the current
converter setup in itself, but I maintain that the need to add an ad hoc
implementation to "each uniquely special snowflake" (plotting method),
rather than at well defined entry points, is less than ideal.  As you
mentioned, this may not actually be due to units, but just to Matplotlib's
general architecture, but unit support make this more visible (... IMO).

Finally, please understand the "lack of well defined use case" from the
point of view of a developer who does not use unitized data.  He sees a
bunch of rather complex code to convert units around (e.g. Line2D.recache
and everything that calls into it), and meanwhile, what is the *only*
documentation he sees on the unit system?  It is the docstring of the units
module, which is frankly less than optimal.  At that point, he just sees
the unit support code as a burden that has to be carried around.
Obviously, I totally understand that people use Matplotlib with different
use cases, and there may be things I use in Matplotlib that you couldn't
care less about.  However, as Jody mentioned some time ago, the unit system
is literally supposed to touch *any* data that comes into Matplotlib, and
can therefore hardly be ignored by any dev.  I believe this is consistent
with the call for a MEP clarifying the use cases of units.

Antony

2018-02-08 21:15 GMT+01:00 Ryan May <rmay31 at gmail.com>:

> Hi,
>
> Let me start by saying that this will probably come across as crabby, and
> I don't really mean for it to do so. I'm happy people are looking at
> improving unit support. HOWEVER, I'm concerned that those trying to push
> right now are completely ignorant of what actually exists in matplotlib and
> how the rest of the ecosystem of unit packages works, don't have personal
> use cases and are completely unclear of what others use cases are, and seem
> to be throwing things at the wall as rapidly as possible. For instance,
> Anthony:
>
> > One major point (already mentioned by others) that led, I think, to
> some devs (including myself) being relatively dismissive about unit support
> is the lack of well-defined use case, other than "it'd be nice if we
> supported units"
> > (i.e., especially from the point of view of devs who *don't* use units
> themselves, it ends up being an ever moving target).  In particular, tests
> on unit support ("unit unit tests"? :-)) currently only rely on the old JPL
> unit code
> > that ended up integrated into Matplotlib's test suite, but does not test
> integration with the two major unit packages I am aware of (pint and
> astropy.units).
>
> False. Until David Stansby's contribution, I wrote every line of code in:
> https://github.com/matplotlib/matplotlib/commits/
> master/lib/matplotlib/tests/test_units.py. Either way, that test has
> literally *nothing* to do with JPL's implementation. (And 30s of github
> could have revealed this.) I added that code *literally* to check whether
> we're properly interfacing with a library just like pint.
>
> > Is there a smaller library that subclasses ndarray for units support?
> I imagine we could vendorize a subset of whatever astropy or yt do.  Or
> maybe they aren?t so huge that they would be unreasonable to make as test
> dependencies.  yt is only 68 Mb.
>
> No. Just no. Again, I have stubbed out just fine the functionality within
> test_units.py to function just like pint--in about 25 lines. I'm happy to
> do so for an ndarray subclass-based one as well.
>
> Now, about the functionality:
>
> > What we need an example of is how the following should work.
> > ```python
> > x = np.arange(10)
> > y  = x*2 * myunitclass.in
> > ax.plot(x, y)
> > z = x*2 * myunitclass.cm
> > ax.plot(x, z)
> > ```
>
> That currently works today, and works just fine. Same test file:
> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tests/
> test_units.py#L72-L81 You're plotting things with the same
> dimensionality, the converter interface can convert to the units that exist
> already on the axes. Done. I'm quite happy with it.
>
> Honestly, I'm not trying to be mean about this. But I come into an email
> thread where things are moving so fast, with factually incorrect
> information flying around, that I'm simply overwhelmed. (14 messages in 3
> hours???) I don't think email is a good place to discuss this.
>
> To be clear, I am *ecstatic* that people are looking at unit challenges,
> and I agree that the way we're implementing it in matplotlib is
> hacky--handling it uniquely for each plotting method rather than
> systematically. And I'm happy to have new voices come in and try to improve
> the situation with new ideas. But I see people railing against the current
> converter interface as if it's unused, crusty, or otherwise completely
> inadequate. The converter WORKS fine. The problem is in that we have to
> hook up unit machinery individually to each plotting method, because each
> plotting method is its own special snowflake--unique and unlike any other.
> What we need is to rationalize the implementation of plots, specifically
> the data handling (missing data, units, shape, etc.), and then implementing
> units will be a sane task.
>
> Or maybe I'm wrong, and there is some structural deficiency in the current
> converter--but I'd at least like to see those arguments coming from a place
> knowledge, not conjecture about how this thing may or may not be working
> currently, and wild speculation about how it's supposed to work. Contrary
> to the "lack of well-defined use case" idea, there are plenty--they might
> not be written down, but that doesn't mean they haven't been discussed
> before.
>
> Let's find a better venue for this discussion that lends itself for
> everyone to join in *together*, synchronously, and in a form where we're
> not guessing at tone.
>
> Ryan
>
> On Thu, Feb 8, 2018 at 11:48 AM, Jody Klymak <jklymak at uvic.ca> wrote:
>
>>
>>
>> On 8 Feb 2018, at 09:54, Drain, Theodore R (392P) <
>> theodore.r.drain at jpl.nasa.gov> wrote:
>>
>> I think we can help with building a better toy unit system.  Or we can
>> standardize on datetime and some existing unit package.  Whatever makes it
>> easier for people to write test cases.
>>
>>
>> For me, the problem w/ datetime is that it is not fully featured units
>> handling in that it doesn?t support multiple units.  Its really just a
>> class of data that we have known conversion to float for.
>>
>> What we need an example of is how the following should work.
>>
>> ```python
>> x = np.arange(10)
>> y = x*2 * myunitclass.in
>> ax.plot(x, y)
>> z = x*2 * myunitclass.cm
>> ax.plot(x, z)
>>
>> ```
>>
>> So when a new feature is added, we can ask that its units support is made
>> clear.  I guess I don?t mind if those are astropy units or yt units, or
>> pint, or?? though there will be some pushback about including another test
>> dependency.
>>
>> Would pint units work?  Its a very small dependency, but maybe not as
>> full featured or structured wildly differently from the others?
>>
>> A test suite to my mind would
>>  - test basic functionality
>>  - test mixing allowed dimensions (i.e. inches and centimeters)
>>  - test changing the axis units (so all the plotted data changes its
>> values, *or* the tick locators/formatters change their values).
>>  - test that disallowed mixed dimensions fail.
>>  - ??
>>
>> Cheers,  Jody
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________________
>> From: Jody Klymak <jklymak at uvic.ca>
>> Sent: Thursday, February 8, 2018 9:39 AM
>> To: Drain, Theodore R (392P)
>> Cc: matplotlib development list
>> Subject: Re: [Matplotlib-devel] Units discussion...
>>
>> I realize that units are "a pain", but they're hugely useful.  Just
>> plotting datetimes is going to be a pain without units (and was a huge pain
>> before the unit system).  The proposal that only Axes supports units is
>> going to cause us a massive problem as that's rarely everything that we do
>> with a plot.  I could do a survey to find all the interactions we use (and
>> that doesn't even touch the 1000's of lines of code our users have written)
>> if that would help but anything that's part of the public api (axes,
>> artists, patches, etc) is probably being used - i.e. pretty much anything
>> that's in the current user's guide is something that we use/want/need to
>> work with unitized data.
>>
>> OK, *for discussion*: A scope of work for JPL and Matplotlib might be:
>>
>> 1) develop better toy unit module that has most of the desired features
>> (maybe the existing one is fine, but please see
>> https://github.com/matplotlib/matplotlib/issues/9713 for why I?m a
>> little dismayed with the state of things).
>>
>> 2) write a developer?s guide explaining how units should be/are
>> implemented
>> a) in matplotlib modules
>>        b) by downstream developers (this is probably adequate already).
>>
>> It sounds like what you are saying is that units should be carried to the
>> draw stage (or cache stage) for all artists.  Thats maybe fine, but as a
>> new developer, I found the units support woefully under-documented. The
>> fact that others have hacked in units support in various inconsistent ways
>> means that we need to police all this better.
>>
>> OTOH, maybe Antony and I are poor people to lead this charge, given that
>> we don?t need unit support.  But I don?t think we are being hypercritical
>> in pointing out it needs work.
>>
>> Thanks a lot,   Jody
>>
>>
>> This is kind of what I meant in my previous email about use cases. Saying
>> "just Axes has units" is basically saying the only valid unit use case is
>> create a plot one time and look at it.  You can't manipulate it, edit it,
>> or build any kind of plotting GUI application (which we have many of) once
>> the plot has been created.  The Artist classes are one of the primary API's
>> for applications.  Artists are created, edited, and manipulated if you want
>> to allow the user to modify things in a plot after it's created.    Even
>> the most basic cases like calling Line2D.set_data() wouldn't be allowed
>> with units if only Axes has unit support.
>>
>> I'm not sure I understand the statement that units are a moving target.
>> The reason it keeps popping up is that code gets added without something
>> considering units which then triggers a bug reports which require fixing.
>> If there was a clearer policy and new code was required to have test cases
>> that cover non-unit and unit inputs, I think things would go much
>> smoother.  We'd be happy to help with submitting new test cases to cover
>> unit cases in existing code once a policy is decided on.  Maybe what's
>> needed is better documentation for developers who don't use units so they
>> can easily write a test case with units when adding/modifying functionality.
>>
>> Ted
>>
>> ________________________________________
>> From: anntzer.lee at gmail.com<mailto:anntzer.lee at gmail.com
>> <anntzer.lee at gmail.com>> <anntzer.lee at gmail.com<mailto:
>> anntzer.lee at gmail.com <anntzer.lee at gmail.com>>> on behalf of Antony Lee <
>> antony.lee at berkeley.edu<mailto:antony.lee at berkeley.edu
>> <antony.lee at berkeley.edu>>>
>> Sent: Thursday, February 8, 2018 8:09 AM
>> To: Drain, Theodore R (392P)
>> Cc: matplotlib development list
>> Subject: Re: [Matplotlib-devel] Units discussion...
>>
>> I'm momentarily a bit away from Matplotlib development due to real life
>> piling up, so I'll just keep this short.
>>
>> One major point (already mentioned by others) that led, I think, to some
>> devs (including myself) being relatively dismissive about unit support is
>> the lack of well-defined use case, other than "it'd be nice if we supported
>> units" (i.e., especially from the point of view of devs who *don't* use
>> units themselves, it ends up being an ever moving target). In particular,
>> tests on unit support ("unit unit tests"? :-)) currently only rely on the
>> old JPL unit code that ended up integrated into Matplotlib's test suite,
>> but does not test integration with the two major unit packages I am aware
>> of (pint and astropy.units).
>>
>> From the email of Ted it appears that these are not sufficient to
>> represent all kinds of relevant units.  In particular, I was at some point
>> hoping to completely work in deunitized data internally, *including the
>> plotting*, and rely on the fact that if the deunitized and the unitized
>> data are usually linked by an affine transform, so the plotting part
>> doesn't need to convert back to unitized data and we only need to place and
>> label the ticks accordingly; however Ted mentioned relativistic units,
>> which imply the use of a non-affine transform.  So I think it would also be
>> really helpful if JPL could release some reasonably documented unit library
>> with their actual use cases (and how it differs from pint & astropy.units),
>> so that we know better what is actually needed (I believe carrying the JPL
>> unit code in our own code base is a mistake).
>>
>>
>> As for the public vs private, or rather unitized vs deunitized API
>> discussion, I believe a relatively simple and consistent line would be to
>> make Axes methods unitized and everything else deunitized (but with clear
>> ways to convert to and from unitized data when not using Axes methods).
>>
>> Antony
>>
>> 2018-02-07 16:33 GMT+01:00 Drain, Theodore R (392P) <
>> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov>>>:
>> That sounds fine to me.  Our original unit prototype API actually had
>> conversions for both directions but I think the float->unit version was
>> removed (or really moved) when the ticker/formatter portion of the unit API
>> was settled on.
>>
>> Using floats/numpy arrays internally is going to easier and faster so I
>> think that's a plus.  The biggest issue we're going to run in to is what's
>> defined as "internal" vs part of the unit API.  Some things are easy like
>> the Axes/Axis API.  But we also use low level API's like the patches.  Are
>> those unitized?  This is the pro and con of using something like Python
>> where basically everything is public.  It makes it possible to do lots of
>> things, but it's much harder to define a clear library with a specific
>> public API.
>>
>> Somewhere in the process we should write a proposal that outlines which
>> classes/methods are part of the unit api and which are going to be
>> considered internal.  I'm sure we can help with that effort.
>>
>> That also might help clarify/influence code structure - if internal
>> implementation classes are placed in a sub-package inside MPL 3.0, it
>> becomes clearer to people later on what the "official' public API vs what
>> can be optimized to just use floats.  Obviously the dev's would need to
>> decide if that kind of restructuring is worth it or not.
>>
>> Ted
>>
>> ________________________________________
>> From: David Stansby <dstansby at gmail.com<mailto:dstansby at gmail.com
>> <dstansby at gmail.com>><mailto:dstansby at gmail.com <dstansby at gmail.com>>>
>> Sent: Wednesday, February 7, 2018 3:42 AM
>> To: Jody Klymak
>> Cc: Drain, Theodore R (392P); matplotlib development list
>> Subject: Re: [Matplotlib-devel] Units discussion...
>>
>> 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<mailto:jklyma
>> k at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca <jklymak at uvic.ca>><
>> mailto:jklymak at uvic.ca <jklymak at uvic.ca><mailto:jklymak at uvic.ca
>> <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<mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov>><mailto:theodore.r.drain at jpl.nasa.gov
>> <theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov
>> <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<mailto:matplotlib-devel-bounce
>> s+ted.drain=jpl.nasa.gov at python.org
>> <matplotlib-devel-bounces+ted.drain=jpl.nasa.gov at python.org>><
>> mailto:jpl.nasa.gov at python.org <jpl.nasa.gov at python.org>><mailto:jpl.
>> nasa.gov at python.org <jpl.nasa.gov at python.org><mailto:
>> jpl.nasa.gov at python.org <jpl.nasa.gov at python.org>>>> on behalf of Jody
>> Klymak <jklymak at uvic.ca<mailto:jklymak at uvic.ca <jklymak at uvic.ca>><
>> mailto:jklymak at uvic.ca <jklymak at uvic.ca>><mailto:jklymak at uvic.ca
>> <jklymak at uvic.ca><mailto:jklymak at uvic.ca <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<mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>>>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org><mailto:Matplotlib-devel at python.org
>> <Matplotlib-devel at python.org>
>>
>> ...
>
> [Message tronqu?]
> _______________________________________________
> 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/20180208/57631f66/attachment-0001.html>

From theodore.r.drain at jpl.nasa.gov  Thu Feb  8 16:47:17 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Thu, 8 Feb 2018 21:47:17 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>,
 <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
Message-ID: <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>

FYI for anyone interested - we already submitted (around the time of the first unit submit code in 2009) a mock of up our unit and time classes, with converters and tickers which is located in matplotlib/testing/jpl_units/.  It doesn't appear to be used in any tests anymore but it's there if anyone wants to look at it and was used in the original unit API testing.  

I think everyone isn't in as much disagreement as it appears.  The way MPL works right now, it's easy for dev's who aren't familiar with units to write code that works and appears correct, but fails for some cases like units.  And they won't know that until a user runs into that case.  So we should work to improve this situation.  The solution will most likely be some combination of code changes, clearer dev docs, and more and better test cases.

I think a big problem is that the plots have no defined internal data representation.  Since Python is untyped, it's easy to write code that works for one test case but fails others you might not think of.  It also means that inside a plot method, a developer really doesn't know what functions they're allowed to use.  Is the data variable a list?  Is it unitized?  Is it integers? floats? a numpy array?  

That's why I'd propose that for any numeric data type, the unit converter must return a numpy array of floats.  Then the plot code (and dev docs) can be very explicit about what functionality can be used and you can be sure that after the external->internal converter is run, you know what the data type is.  If done properly, I think this actually makes the existing code simpler.  We can have a sequence of converters that try to run on the input which would include "standard" types like lists and integers.  So if a user puts in a Python list of integers, floats, numpy, or their own type, etc, the developer knows that once the converter at the top of the method runs, they have a numpy array of floats to work with and there is no guess as to what functions will work or not work.

If this works, then it can be "the one way" to write a plot function for numeric data and every method can have the conversion as the first step.

Ted
ps: I think this dev list is the best forum for this discussion unless you can arrange a conference where we can all meet up.  I find gitter is too hard to follow unless you're watching it in real time.  A forum thread would be better IMO, but we don't have that.  

________________________________________
From: Nathan Goldbaum <nathan12343 at gmail.com>
Sent: Thursday, February 8, 2018 12:13 PM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

On Thu, Feb 8, 2018 at 1:08 PM, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>> wrote:
Does numpy subclassing really matter?  If the docs say the unit converter must convert from the external type to the internal type, then as long as the converter does that, it doesn't matter what the external type is or what it inherits from right?  The point is that the converter class is the only class manipulating the external data objects - MPL shouldn't care what they are or what they inherit from.

To make my statement more concrete, here's a matplotlib pull request that fixed a bug that only triggered for astropy and yt but not for pint:

https://github.com/matplotlib/matplotlib/pull/6622

In this case it was an issue because of difference in how NumPy's masked array deals with ndarray subclasses versus array wrapper classes.

I think one issue is that data types are malleable in the API right now.  Lists, tuples, numpy, ints, floats, etc are all possible inputs in many/most cases.  IMO, the unit API should not be malleable at all.  The unit converter API should say that the return type of external->internal conversion is always a specific value type (e.g. list of float, numpy float 64 array).

Jody: IMO, your example should plot the data in inches in the first plot call, then convert the second input to inches and plot that.  The plot calls supports the xunits keyword argument which tells the converter what floating point unit conversion to apply.  If that keyword is not specified, then it defaults to the type of the input.  The example that needs to be more clear is if I do this:

ax.plot( x1, y1, xunits="km" )
ax.plot( x2, y2, xunits="miles" )

IMO, either the floats are km or miles, not both.  So either the first call sticks the converter to using km and the second xunits is ignored.  Or the second input overrides the first and requires that the first artists go back through a conversion to miles.  Either is a reasonable choice for behavior (but the first is much easier to implement).

From dstansby at gmail.com  Thu Feb  8 17:11:53 2018
From: dstansby at gmail.com (David Stansby)
Date: Thu, 8 Feb 2018 22:11:53 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
 <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
 <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>
Message-ID: <CAGm9cHC27AWGYsjwjqvHiD=71p6yoQw3y61_iNgDgZKmANKu1A@mail.gmail.com>

I agree with everything you've said there.

I propose to have a go at implementing what I proposed in the next few
weeks - on the surface it seems to me like it will simplify things a lot,
but I guess I'll see as I go how hard it actually is! If it works it will
be a bit of an upheaval for 3rd parties who use units at the moment, but
should be worth it in the long run.

David

On 8 February 2018 at 21:47, Drain, Theodore R (392P) <
theodore.r.drain at jpl.nasa.gov> wrote:

> FYI for anyone interested - we already submitted (around the time of the
> first unit submit code in 2009) a mock of up our unit and time classes,
> with converters and tickers which is located in
> matplotlib/testing/jpl_units/.  It doesn't appear to be used in any tests
> anymore but it's there if anyone wants to look at it and was used in the
> original unit API testing.
>
> I think everyone isn't in as much disagreement as it appears.  The way MPL
> works right now, it's easy for dev's who aren't familiar with units to
> write code that works and appears correct, but fails for some cases like
> units.  And they won't know that until a user runs into that case.  So we
> should work to improve this situation.  The solution will most likely be
> some combination of code changes, clearer dev docs, and more and better
> test cases.
>
> I think a big problem is that the plots have no defined internal data
> representation.  Since Python is untyped, it's easy to write code that
> works for one test case but fails others you might not think of.  It also
> means that inside a plot method, a developer really doesn't know what
> functions they're allowed to use.  Is the data variable a list?  Is it
> unitized?  Is it integers? floats? a numpy array?
>
> That's why I'd propose that for any numeric data type, the unit converter
> must return a numpy array of floats.  Then the plot code (and dev docs) can
> be very explicit about what functionality can be used and you can be sure
> that after the external->internal converter is run, you know what the data
> type is.  If done properly, I think this actually makes the existing code
> simpler.  We can have a sequence of converters that try to run on the input
> which would include "standard" types like lists and integers.  So if a user
> puts in a Python list of integers, floats, numpy, or their own type, etc,
> the developer knows that once the converter at the top of the method runs,
> they have a numpy array of floats to work with and there is no guess as to
> what functions will work or not work.
>
> If this works, then it can be "the one way" to write a plot function for
> numeric data and every method can have the conversion as the first step.
>
> Ted
> ps: I think this dev list is the best forum for this discussion unless you
> can arrange a conference where we can all meet up.  I find gitter is too
> hard to follow unless you're watching it in real time.  A forum thread
> would be better IMO, but we don't have that.
>
> ________________________________________
> From: Nathan Goldbaum <nathan12343 at gmail.com>
> Sent: Thursday, February 8, 2018 12:13 PM
> To: Drain, Theodore R (392P)
> Cc: matplotlib development list
> Subject: Re: [Matplotlib-devel] Units discussion...
>
> On Thu, Feb 8, 2018 at 1:08 PM, Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>>
> wrote:
> Does numpy subclassing really matter?  If the docs say the unit converter
> must convert from the external type to the internal type, then as long as
> the converter does that, it doesn't matter what the external type is or
> what it inherits from right?  The point is that the converter class is the
> only class manipulating the external data objects - MPL shouldn't care what
> they are or what they inherit from.
>
> To make my statement more concrete, here's a matplotlib pull request that
> fixed a bug that only triggered for astropy and yt but not for pint:
>
> https://github.com/matplotlib/matplotlib/pull/6622
>
> In this case it was an issue because of difference in how NumPy's masked
> array deals with ndarray subclasses versus array wrapper classes.
>
> I think one issue is that data types are malleable in the API right now.
> Lists, tuples, numpy, ints, floats, etc are all possible inputs in
> many/most cases.  IMO, the unit API should not be malleable at all.  The
> unit converter API should say that the return type of external->internal
> conversion is always a specific value type (e.g. list of float, numpy float
> 64 array).
>
> Jody: IMO, your example should plot the data in inches in the first plot
> call, then convert the second input to inches and plot that.  The plot
> calls supports the xunits keyword argument which tells the converter what
> floating point unit conversion to apply.  If that keyword is not specified,
> then it defaults to the type of the input.  The example that needs to be
> more clear is if I do this:
>
> ax.plot( x1, y1, xunits="km" )
> ax.plot( x2, y2, xunits="miles" )
>
> IMO, either the floats are km or miles, not both.  So either the first
> call sticks the converter to using km and the second xunits is ignored.  Or
> the second input overrides the first and requires that the first artists go
> back through a conversion to miles.  Either is a reasonable choice for
> behavior (but the first is much easier to implement).
> _______________________________________________
> 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/20180208/ed036a1b/attachment-0001.html>

From theodore.r.drain at jpl.nasa.gov  Thu Feb  8 18:18:54 2018
From: theodore.r.drain at jpl.nasa.gov (Drain, Theodore R (392P))
Date: Thu, 8 Feb 2018 23:18:54 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGm9cHC27AWGYsjwjqvHiD=71p6yoQw3y61_iNgDgZKmANKu1A@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
 <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
 <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>,
 <CAGm9cHC27AWGYsjwjqvHiD=71p6yoQw3y61_iNgDgZKmANKu1A@mail.gmail.com>
Message-ID: <e20a41193d3e4e24910354c9899fcc47@jpl.nasa.gov>

David,
What exactly is the proposal?  I'm not sure I fully understand that.  The existing unit system basically already does conversion to float, it's just not applied very evenly or in quite the same way in all the methods.

But - I wonder if this is the wrong first step to take.  At this point, do we know which methods are working fine as is and which ones are not?  Maybe it would be better to start writing a comprehensive set of unit test cases that pass different unitized data to each Axes method.  That could serve to define what we expect to happen and would help identify methods that don't currently work.  Failing unit tests are a nice way to identify code that needs to change and would help others know exactly what the "right" behavior is supposed to be.  Then code changes could be made to start correctly those issues.

Then a similar set of unit tests with unitized data could be written for artists and the same process could be repeated.  Once artists handle unitized data, it may also simplify the plot methods as well - at least for the ones whose primary role is to just build an artists.

Ted

________________________________________
From: David Stansby <dstansby at gmail.com>
Sent: Thursday, February 8, 2018 2:11 PM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

I agree with everything you've said there.

I propose to have a go at implementing what I proposed in the next few weeks - on the surface it seems to me like it will simplify things a lot, but I guess I'll see as I go how hard it actually is! If it works it will be a bit of an upheaval for 3rd parties who use units at the moment, but should be worth it in the long run.

David

On 8 February 2018 at 21:47, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>> wrote:
FYI for anyone interested - we already submitted (around the time of the first unit submit code in 2009) a mock of up our unit and time classes, with converters and tickers which is located in matplotlib/testing/jpl_units/.  It doesn't appear to be used in any tests anymore but it's there if anyone wants to look at it and was used in the original unit API testing.

I think everyone isn't in as much disagreement as it appears.  The way MPL works right now, it's easy for dev's who aren't familiar with units to write code that works and appears correct, but fails for some cases like units.  And they won't know that until a user runs into that case.  So we should work to improve this situation.  The solution will most likely be some combination of code changes, clearer dev docs, and more and better test cases.

I think a big problem is that the plots have no defined internal data representation.  Since Python is untyped, it's easy to write code that works for one test case but fails others you might not think of.  It also means that inside a plot method, a developer really doesn't know what functions they're allowed to use.  Is the data variable a list?  Is it unitized?  Is it integers? floats? a numpy array?

That's why I'd propose that for any numeric data type, the unit converter must return a numpy array of floats.  Then the plot code (and dev docs) can be very explicit about what functionality can be used and you can be sure that after the external->internal converter is run, you know what the data type is.  If done properly, I think this actually makes the existing code simpler.  We can have a sequence of converters that try to run on the input which would include "standard" types like lists and integers.  So if a user puts in a Python list of integers, floats, numpy, or their own type, etc, the developer knows that once the converter at the top of the method runs, they have a numpy array of floats to work with and there is no guess as to what functions will work or not work.

If this works, then it can be "the one way" to write a plot function for numeric data and every method can have the conversion as the first step.

Ted
ps: I think this dev list is the best forum for this discussion unless you can arrange a conference where we can all meet up.  I find gitter is too hard to follow unless you're watching it in real time.  A forum thread would be better IMO, but we don't have that.

________________________________________
From: Nathan Goldbaum <nathan12343 at gmail.com<mailto:nathan12343 at gmail.com>>
Sent: Thursday, February 8, 2018 12:13 PM
To: Drain, Theodore R (392P)
Cc: matplotlib development list
Subject: Re: [Matplotlib-devel] Units discussion...

On Thu, Feb 8, 2018 at 1:08 PM, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov>>> wrote:
Does numpy subclassing really matter?  If the docs say the unit converter must convert from the external type to the internal type, then as long as the converter does that, it doesn't matter what the external type is or what it inherits from right?  The point is that the converter class is the only class manipulating the external data objects - MPL shouldn't care what they are or what they inherit from.

To make my statement more concrete, here's a matplotlib pull request that fixed a bug that only triggered for astropy and yt but not for pint:

https://github.com/matplotlib/matplotlib/pull/6622

In this case it was an issue because of difference in how NumPy's masked array deals with ndarray subclasses versus array wrapper classes.

I think one issue is that data types are malleable in the API right now.  Lists, tuples, numpy, ints, floats, etc are all possible inputs in many/most cases.  IMO, the unit API should not be malleable at all.  The unit converter API should say that the return type of external->internal conversion is always a specific value type (e.g. list of float, numpy float 64 array).

Jody: IMO, your example should plot the data in inches in the first plot call, then convert the second input to inches and plot that.  The plot calls supports the xunits keyword argument which tells the converter what floating point unit conversion to apply.  If that keyword is not specified, then it defaults to the type of the input.  The example that needs to be more clear is if I do this:

ax.plot( x1, y1, xunits="km" )
ax.plot( x2, y2, xunits="miles" )

IMO, either the floats are km or miles, not both.  So either the first call sticks the converter to using km and the second xunits is ignored.  Or the second input overrides the first and requires that the first artists go back through a conversion to miles.  Either is a reasonable choice for behavior (but the first is much easier to implement).
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org<mailto:Matplotlib-devel at python.org>
https://mail.python.org/mailman/listinfo/matplotlib-devel


From jklymak at uvic.ca  Thu Feb  8 19:33:19 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 8 Feb 2018 16:33:19 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <e20a41193d3e4e24910354c9899fcc47@jpl.nasa.gov>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
 <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
 <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>
 <CAGm9cHC27AWGYsjwjqvHiD=71p6yoQw3y61_iNgDgZKmANKu1A@mail.gmail.com>
 <e20a41193d3e4e24910354c9899fcc47@jpl.nasa.gov>
Message-ID: <C97BF86D-EE70-4E9C-AF90-71D35B9929CB@uvic.ca>



> On 8 Feb 2018, at 15:18, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov> wrote:
> 
> On 8 February 2018 at 21:47, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>>> wrote:
> FYI for anyone interested - we already submitted (around the time of the first unit submit code in 2009) a mock of up our unit and time classes, with converters and tickers which is located in matplotlib/testing/jpl_units/.  It doesn't appear to be used in any tests anymore but it's there if anyone wants to look at it and was used in the original unit API testing.


Aha! `jpl_units` *is* used for a few tests in `test_axes.py` and `test_dates.py`, and `test_patches.py`

And those tests behave in what I?d say is a reasonable manner.  So maybe step 1 of coming up with a decent toy units system is accomplished.  

Steps 2 and 3 might be to add some more tests and some documentation/tutorial using the toy unit system.  I?m happy to give that a shot in the next few weeks.  Then we can move on to fixing the methods that don?t play well w/ units.  

Cheers,   Jody






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/7c812aed/attachment.html>

From marcidy at gmail.com  Fri Feb  9 05:36:41 2018
From: marcidy at gmail.com (Matt Arcidy)
Date: Fri, 9 Feb 2018 02:36:41 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
Message-ID: <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>

Good points.  I wonder if tagging is better with a search/filter than
only categorization.  Someone could filter/search for tutorials which
only use arithmetic and basic python, or grab all tutorials/examples
that use Axes.xlim, etc.  I guess that's for later though.

I don't know a good way to classify python as
beginner/intermediate/expert. Having taught all those levels, maybe
you have clear insight into that?

Do you have ideas for the survey, how, what etc?  That's a great idea.
I'd love to get as many profiles as possible up front.

I'm attempting to get a handle on all the functions used in the
examples/tutorials (note below). I'd like to categorize the
functions/concepts used for them as well.  Will need categories first
of course.

Those are 3 pretty good tasks I think:
1) classify python by skill level
2) survey ideas
3) gather data on current tutorials/examples and rough categorization

This is just a list, I'm not one to assign anything.  I'll work on
whatever needs to get done.

All:
I would like to be able to go through all the example/tutorial scripts
and pull out which matplotlib modules/functions/objects are used in
each script, just top level.  Since they are scripts and not modules,
I cannot seem to get reflection to work like a for a module (so far
anyways).  If anyone has a good tool I would greatly appreciate it.


Thanks,
-Matt


On Thu, Feb 8, 2018 at 8:15 AM, Hannah <story645 at gmail.com> wrote:
> Hi Matt,
> I'm super psyched that you're onboard and totally agree with you on the
> importance of identifying audience. I think that's a lot of where the docs
> really struggle because the audience is very broad.
>
> For example, I introduce matplotlib a lot to the following audiences who I
> don't think you've mentioned yet:
>
> high school students
> -little to no programming classes
> -a summer REU
> -only know about the plots they've seen in their science class
>
> humanaties masters and graduate students
> - little/no programming experience
> - frame of reference for visualization is usually journalism viz like New
> York Times or art installations.
> - often don't have or forgot the vocabulary around  scientific and
> statistical plots (what is a measurment, scale, etc)
>
> Computer Science students
> - undergrad through grad
> - taking a visualization course
> - have lots of programming experience, but not necessarily in Python
> - want to make highly information dense plots or dashboards
>
>
> And I really would love a survey of the community to get an even better
> sense of who is using matplotlib.
>
> -Hannah
>
> On Feb 8, 2018 3:30 AM, "Matt Arcidy" <marcidy at gmail.com> wrote:
>
> Hi All,
>
> Please forgive the presumption of pulling this topic out of from the meeting
> thread especially as this is also in a self-introduction email.
>
> I want to help with the documentation effort.  I read Tom's article in
> numfocus and the desired skillset rang true.  I have 10ish years experience
> writing tech docs, a few 100+ pages.   I write creatively, and I am still
> somewhat new to matplotlib.  I am happy to work in any capacity, though i am
> most interested in cranking out the first draft of the book.
>
> I have looked into the available documentation over the past month+ so I
> could come with understanding and ideas, some of which I hope are actually
> good.
>
> Both the meeting thread and Tom requested ideas for reorganizing the
> tutorials and examples as a place to start, so I'll throw one out: explicit
> definition of an audience, something to which all the documentation can
> adhere.
>
> Right now the tutorials are leveled as beginner, intermediate, and expert,
> which is great, but it's not clear what that means.  Explicitly defining the
> required skill sets, while not perfect, will allow sorting of concepts and
> people into each bin.
>
> As an example, (please excuse the contrivence):
>
> Laura
> - Sophomore in college
> - dead set on being a data scientist
> - 2 programming classes in python
> - never used any kind of CAD software ever (i.e. does not have any concept
> of a plot beyond a line on graph paper)
>
> Xian
> - 1 week away from Zoology PhD dissertation, under a deadline
> - Has used R and Matplotlib to create very basic plots for papers
> - Wants to create a plot with species heart size over adult weight, with the
> marker being a jpg of the species' actual heart, beating at the actual
> species' heart rate on the plot.
>
> Ayah
> - Post Doc or professional
> - 10+ years of plotting experience using various packages but not matplotlib
> - has funding to contribute significant functionality, but needs to get up
> to speed on everything now
>
> Obviously this is just beginner, intermediate, expert, but they can be
> explicitly targeted/taught based on their skill level.  Laura needs
> hand-holding, Xian needs a great API reference, Ayah needs a mosaic of
> everything and a good architecture map.
>
> In the same vein as above, learning paths through the tutorial documents.
> There are some separable plotting skills, like visually designing the plot,
> animation, application development, matplotlib development...etc. Each skill
> could have beginner/intermediate/expert level tutorials which progress
> naturally, creating a learning tract for each skill.  Skills can be stacked
> to flow into specific roles.
>
> Looking at this from outside, the best part about this project is all the
> information is already there. I have more ideas to dump on you, but I'll
> postpone until I have a better understanding of where I can fit.
>
> Thanks!
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
>

From dstansby at gmail.com  Fri Feb  9 06:55:03 2018
From: dstansby at gmail.com (David Stansby)
Date: Fri, 9 Feb 2018 11:55:03 +0000
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <C97BF86D-EE70-4E9C-AF90-71D35B9929CB@uvic.ca>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
 <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
 <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>
 <CAGm9cHC27AWGYsjwjqvHiD=71p6yoQw3y61_iNgDgZKmANKu1A@mail.gmail.com>
 <e20a41193d3e4e24910354c9899fcc47@jpl.nasa.gov>
 <C97BF86D-EE70-4E9C-AF90-71D35B9929CB@uvic.ca>
Message-ID: <CAGm9cHCdc_EyebrGzC1v3VqxVkmtA0aXye+L9+Lme1s+wv5xbg@mail.gmail.com>

After having thought about this a bit more, apologies for jumping the gun.

I'm trying to learn more about how the units system works at the moment and
why it works that way. I'll probably try and improve the docs a bit as I go.

One question I have at the moment is why do some plotting methods pass
units through them quite a long way, instead of just doing the conversion
right at the beginning of the method? It seems like the obvious thing to do
to me is do the conversion immediately, but I'm sure there must be a good
reason to pass units through in some places.

David

On 9 February 2018 at 00:33, Jody Klymak <jklymak at uvic.ca> wrote:

>
>
> On 8 Feb 2018, at 15:18, Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov> wrote:
>
> On 8 February 2018 at 21:47, Drain, Theodore R (392P) <
> theodore.r.drain at jpl.nasa.gov<mailto:theodore.r.drain at jpl.nasa.gov
> <theodore.r.drain at jpl.nasa.gov>>> wrote:
> FYI for anyone interested - we already submitted (around the time of the
> first unit submit code in 2009) a mock of up our unit and time classes,
> with converters and tickers which is located in
> matplotlib/testing/jpl_units/.  It doesn't appear to be used in any tests
> anymore but it's there if anyone wants to look at it and was used in the
> original unit API testing.
>
>
>
> Aha! `jpl_units` *is* used for a few tests in `test_axes.py` and
> `test_dates.py`, and `test_patches.py`
>
> And those tests behave in what I?d say is a reasonable manner.  So maybe
> step 1 of coming up with a decent toy units system is accomplished.
>
> Steps 2 and 3 might be to add some more tests and some
> documentation/tutorial using the toy unit system.  I?m happy to give that a
> shot in the next few weeks.  Then we can move on to fixing the methods that
> don?t play well w/ units.
>
> Cheers,   Jody
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180209/707e3bec/attachment.html>

From pmhobson at gmail.com  Fri Feb  9 12:07:29 2018
From: pmhobson at gmail.com (Paul Hobson)
Date: Fri, 9 Feb 2018 09:07:29 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
Message-ID: <CADT3MEBPDq8q3chgRitSYDua=hrFJ0EdDXXkmEJcU0Mmj5sjwA@mail.gmail.com>

On Fri, Feb 9, 2018 at 2:36 AM, Matt Arcidy <marcidy at gmail.com> wrote:

> Good points.  I wonder if tagging is better with a search/filter than
> only categorization.  Someone could filter/search for tutorials which
> only use arithmetic and basic python, or grab all tutorials/examples
> that use Axes.xlim, etc.
>


To some extent, this already happens with the sphinx-gallery examples. See,
for example:
https://matplotlib.org/devdocs/api/_as_gen/matplotlib.pyplot.contourf.html#examples-using-matplotlib-pyplot-contourf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180209/a95c3b13/attachment.html>

From jklymak at uvic.ca  Fri Feb  9 12:22:54 2018
From: jklymak at uvic.ca (Jody Klymak)
Date: Fri, 9 Feb 2018 09:22:54 -0800
Subject: [Matplotlib-devel] Units discussion...
In-Reply-To: <CAGm9cHCdc_EyebrGzC1v3VqxVkmtA0aXye+L9+Lme1s+wv5xbg@mail.gmail.com>
References: <169E7DEB-92A5-4059-A1FC-8274188CCF84@uvic.ca>
 <bcae8d978dc941b69e8613c97dd19990@jpl.nasa.gov>
 <28D9B599-28AA-443D-9B5E-AD802A369A13@uvic.ca>
 <CAGm9cHCuZWv-saczv1PqYtSbS3sRUR6VJBUz+T6XB=0YnMk8KA@mail.gmail.com>
 <7f48982f1b8b4ba8a2ab9cf87ae10809@jpl.nasa.gov>
 <CAGRr6BF-Su2umNt=XmzW_NqGQEHpH0brtTw=_5R1w-0wv+a5sg@mail.gmail.com>
 <59570b5a96a84f5bbff9c3e8e184b5d5@jpl.nasa.gov>
 <6EBE985F-E331-4237-AB8E-A4D833FAAC41@uvic.ca>
 <f5891bd5f19647f2a5847952be280ed3@jpl.nasa.gov>
 <B30C6FD4-8C24-40B6-8F9E-E2AE6D071A8F@uvic.ca>
 <CAJXewOmpE0-OcGj-m7sHUZRZ7v1pe3=DrfRiKs6JKVGeUn9s=w@mail.gmail.com>
 <db3ce4f6c7e140f19b9c47cc953212ab@jpl.nasa.gov>
 <CAJXewOnC=beavaKhiZVs5BZF4xoDtoHTLscO4w-Ns-AFHRZzSw@mail.gmail.com>
 <2443d76e81904f79a6db6f70b2f6fcc8@jpl.nasa.gov>
 <CAGm9cHC27AWGYsjwjqvHiD=71p6yoQw3y61_iNgDgZKmANKu1A@mail.gmail.com>
 <e20a41193d3e4e24910354c9899fcc47@jpl.nasa.gov>
 <C97BF86D-EE70-4E9C-AF90-71D35B9929CB@uvic.ca>
 <CAGm9cHCdc_EyebrGzC1v3VqxVkmtA0aXye+L9+Lme1s+wv5xbg@mail.gmail.com>
Message-ID: <A35BE6CE-1280-44DB-A68F-0189C18928E4@uvic.ca>



> On 9 Feb 2018, at 03:55, David Stansby <dstansby at gmail.com> wrote:
> 
> After having thought about this a bit more, apologies for jumping the gun.
> 
> I'm trying to learn more about how the units system works at the moment and why it works that way. I'll probably try and improve the docs a bit as I go.
> 
> One question I have at the moment is why do some plotting methods pass units through them quite a long way, instead of just doing the conversion right at the beginning of the method? It seems like the obvious thing to do to me is do the conversion immediately, but I'm sure there must be a good reason to pass units through in some places.

So that something like 

```python
ax.plot(a, b, units=?inches?)
ax.plot(a, c, units=?centimeters?)
```

will convert to centimeters at draw time.  This currently works with `plot` because `Line2D` objects carry the units through until the path gets cached.  It doesn?t work for `scatter`, though it seems possible that it could, but maybe only with violence to how `scatter` is architectured.

I was thinking of building a units tutorial on this, with what works and what doesn?t work documented.  But if you are eager to do it, then that?d be great.  

I found this to be a reasonable set of examples:

```python
import matplotlib.pyplot as plt
import numpy as np
import matplotlib.testing.jpl_units as units
units.register()

xdata = [x*units.sec for x in range(10)]
xdata = np.arange(10) * units.sec
ydata1 = (1.5*np.arange(10) - 0.5) * units.km
ydata2 = (1.75*np.arange(10) - 1.0) * units.km

fig, ax = plt.subplots()
ax.plot(xdata, ydata1, color='blue', xunits="sec")
ax.set_xlabel("x-label 001")

fig, ax = plt.subplots()
ax.plot(xdata, ydata1, color='blue', xunits="hour")
ax.set_xlabel("hours")

fig, ax = plt.subplots()
ax.plot(xdata, ydata1, color='blue', xunits="sec", yunits='m')
ax.plot(xdata, ydata2, color='green', xunits="hour")
ax.set_xlabel("hours")
plt.show()

```


> 
> David
> 
> On 9 February 2018 at 00:33, Jody Klymak <jklymak at uvic.ca <mailto:jklymak at uvic.ca>> wrote:
> 
> 
>> On 8 Feb 2018, at 15:18, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>> wrote:
>> 
>> On 8 February 2018 at 21:47, Drain, Theodore R (392P) <theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov><mailto:theodore.r.drain at jpl.nasa.gov <mailto:theodore.r.drain at jpl.nasa.gov>>> wrote:
>> FYI for anyone interested - we already submitted (around the time of the first unit submit code in 2009) a mock of up our unit and time classes, with converters and tickers which is located in matplotlib/testing/jpl_units/.  It doesn't appear to be used in any tests anymore but it's there if anyone wants to look at it and was used in the original unit API testing.
> 
> 
> Aha! `jpl_units` *is* used for a few tests in `test_axes.py` and `test_dates.py`, and `test_patches.py`
> 
> And those tests behave in what I?d say is a reasonable manner.  So maybe step 1 of coming up with a decent toy units system is accomplished.  
> 
> Steps 2 and 3 might be to add some more tests and some documentation/tutorial using the toy unit system.  I?m happy to give that a shot in the next few weeks.  Then we can move on to fixing the methods that don?t play well w/ units.  
> 
> Cheers,   Jody
> 
> 
> 
> 
> 
> 
> 

--
Jody Klymak    
http://web.uvic.ca/~jklymak/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180209/697fec22/attachment.html>

From tcaswell at gmail.com  Sun Feb 11 23:47:24 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 12 Feb 2018 04:47:24 +0000
Subject: [Matplotlib-devel] [ANN] Matplotlib v2.2.0rc1 tagged
Message-ID: <CAA48SF9zT7Fpzep_V3ifUkfgdPYXp5FowdXD7yrO=1LJNt5mdQ@mail.gmail.com>

Folks,

We have tagged RC1 for 2.2!  We have many bug-fixes, performance
improvements and new features in this release!

2.2 will be a 'long-term support' release and we will do bug-fix release on
it until 2020.

Aiming for a final release in 2 weeks (Mar 2).   We'll sort out over the
next week if we want to do an RC2 or not.  I have created a v2.2.x branch
for managing the 2.2.0 release work and the 2.2.x series going forward.

With this tag, the master branch is python 3 only.  There will be a follow
up email to discuss if we are py3.5+ or py3.6+, for now lets stay with 3.5+.

As part of this I have cleaned out the upstream branches and merged them
all up:

 - master: mpl3.0 work and new features, python3 only
 - v2.2.x : v2.2.x series work.  Only bug-fixes and documentation updates,
python 2.7, 3.4+
 - v2.1.2-doc : documentation changes only to rebuild the current stable
docs.  When 2.2.0 is out this will be replaced by v2.2.0-doc

Thanks to everyone who worked on this release!

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/b7241004/attachment.html>

From story645 at gmail.com  Mon Feb 12 15:59:58 2018
From: story645 at gmail.com (Hannah)
Date: Mon, 12 Feb 2018 15:59:58 -0500
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
Message-ID: <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>

Sorry for the late reply.

Good points.  I wonder if tagging is better with a search/filter than
> only categorization.  Someone could filter/search for tutorials which
> only use arithmetic and basic python, or grab all tutorials/examples
> that use Axes.xlim, etc.  I guess that's for later though.
>

Totally agree with you on this, and also wondering if there are ways to tag
the documentation with the type of graph the function is creating when the
name of the function is domain specific but the graph is used a bit more
widely. Specifically thinking about how stackplot is the technical term,
but a lot of people know them as stream graphs. Or imshow and matshow are
used to create heatmaps.



> I don't know a good way to classify python as
> beginner/intermediate/expert. Having taught all those levels, maybe
> you have clear insight into that?
>

I struggle with it too because it's so relative. What for me is
intermediate Python is beginner to some and expert to others. Object
Oriented seems to be a good demarcation,
but since the suggested way of interacting with mpl is through the OO I
dunno how to reconcile that. I wonder if mpl needs a little "intro to using
objects" type mini/breakaway section. I've been going through the data camp
tutorials and been frustrated that they're all pyplot, but that seems to be
the preferred intro-and I wonder if it'd be good for matplotlib to have
more bridge documentation that doesn't just show how to do things both ways
but explains why the OO way is better. Also a proper simple but object
oriented tutorial might help here.  Ben Root and Nicolas Rougier's
tutorials are in this direction.


Do you have ideas for the survey, how, what etc?  That's a great idea.
> I'd love to get as many profiles as possible up front.
>

I think something as simple as a google or survey monkey poll, advertised
really heavily on twitter/a pop up banner when people come to the docs/the
user mailing list/etc. might work. Pretty basic self assessment questions:
What's your fluency with Python? How long have you been using Python? How
long have you been using Matplolib? Which interface do you use more often?
pyplot/OO (with links/hover example of each), and sort of whatever else you
feel you'd need for docs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/5136287b/attachment.html>

From tcaswell at gmail.com  Mon Feb 12 17:30:04 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 12 Feb 2018 22:30:04 +0000
Subject: [Matplotlib-devel] 2018-02-12 call notes
Message-ID: <CAA48SF_cCg4qCAPBhfUujFYkyE6xfDpQHW1UDiL+JJcV5Yuoxw@mail.gmail.com>

Me, Eric, Ryan

Seems to be calm before the storm of 2.2rc1 issues.

Talked about which version of python 3 to use (follow up email coming)

Briefly discussed type annotations.

Discussed possible Matplotlib 4 redesign options.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/adc04564/attachment.html>

From tcaswell at gmail.com  Mon Feb 12 17:40:37 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 12 Feb 2018 22:40:37 +0000
Subject: [Matplotlib-devel] What minimum version of python3?
Message-ID: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>

These are derived from today's call:

Pro 3.6:
 - by the time we release, 3.7 will be out so will support "two most recent
python"
    - this gives 3 years of support on master of each python version
(assuming python sticks
 - ordered, faster dictionaries (as implementation detail in 3.6,
guaranteed in 3.7)
 - guaranteed ordered kwargs / class definitions (do precedence of
conflicting kwaargs)
 - fstrings
 - fspath / pathlib protocol

Con 3.6:
 - feels a bit agressive as 3.7 is not out yet
 - might get ahead of some LTS releases
   - but older version of Matplotlib will still work
   - user-space environments go along way to fixing this
     - conda
     -
https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7
   - ubuntu 18.04 is planned to be py3.6 by default

Pro 3.5:
 - more conservative approach
 - pypy3 support (but they will support 3.6 eventually)

The consensus on the call and on gitter seems to be for 3.6 as the minimum.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/339ecd9d/attachment.html>

From matthew.brett at gmail.com  Mon Feb 12 18:27:22 2018
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 12 Feb 2018 23:27:22 +0000
Subject: [Matplotlib-devel] What minimum version of python3?
In-Reply-To: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>
References: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>
Message-ID: <CAH6Pt5rA8w35d+Z5S7cRmnrExwTvrUdRdMY=P8U7hfOfz4y44Q@mail.gmail.com>

On Mon, Feb 12, 2018 at 10:40 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> These are derived from today's call:
>
> Pro 3.6:
>  - by the time we release, 3.7 will be out so will support "two most recent
> python"
>     - this gives 3 years of support on master of each python version
> (assuming python sticks
>  - ordered, faster dictionaries (as implementation detail in 3.6, guaranteed
> in 3.7)
>  - guaranteed ordered kwargs / class definitions (do precedence of
> conflicting kwaargs)
>  - fstrings
>  - fspath / pathlib protocol
>
> Con 3.6:
>  - feels a bit agressive as 3.7 is not out yet
>  - might get ahead of some LTS releases
>    - but older version of Matplotlib will still work
>    - user-space environments go along way to fixing this
>      - conda
>      -
> https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7
>    - ubuntu 18.04 is planned to be py3.6 by default
>
> Pro 3.5:
>  - more conservative approach
>  - pypy3 support (but they will support 3.6 eventually)
>
> The consensus on the call and on gitter seems to be for 3.6 as the minimum.

Man - that seems pretty extreme.   Are the 3.6 features really worth
it?  There must be a lot of Linuces at Python 3.5, even at the most
recent distribution.  Was there by any chance a majority of conda
users on the call?

Cheers,

Matthew

From nathan12343 at gmail.com  Mon Feb 12 18:48:51 2018
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Mon, 12 Feb 2018 23:48:51 +0000
Subject: [Matplotlib-devel] What minimum version of python3?
In-Reply-To: <CAH6Pt5rA8w35d+Z5S7cRmnrExwTvrUdRdMY=P8U7hfOfz4y44Q@mail.gmail.com>
References: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>
 <CAH6Pt5rA8w35d+Z5S7cRmnrExwTvrUdRdMY=P8U7hfOfz4y44Q@mail.gmail.com>
Message-ID: <CAJXewOmMdV9CBcNUdZjNP3cTdGE-CTjk7CvXKssbxBCjTgC5rw@mail.gmail.com>

Ubuntu 14.04 (which admittedly goes EOL in April) is still on python 3.4,
for example.

On Mon, Feb 12, 2018 at 5:28 PM Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Mon, Feb 12, 2018 at 10:40 PM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
> > These are derived from today's call:
> >
> > Pro 3.6:
> >  - by the time we release, 3.7 will be out so will support "two most
> recent
> > python"
> >     - this gives 3 years of support on master of each python version
> > (assuming python sticks
> >  - ordered, faster dictionaries (as implementation detail in 3.6,
> guaranteed
> > in 3.7)
> >  - guaranteed ordered kwargs / class definitions (do precedence of
> > conflicting kwaargs)
> >  - fstrings
> >  - fspath / pathlib protocol
> >
> > Con 3.6:
> >  - feels a bit agressive as 3.7 is not out yet
> >  - might get ahead of some LTS releases
> >    - but older version of Matplotlib will still work
> >    - user-space environments go along way to fixing this
> >      - conda
> >      -
> >
> https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7
> >    - ubuntu 18.04 is planned to be py3.6 by default
> >
> > Pro 3.5:
> >  - more conservative approach
> >  - pypy3 support (but they will support 3.6 eventually)
> >
> > The consensus on the call and on gitter seems to be for 3.6 as the
> minimum.
>
> Man - that seems pretty extreme.   Are the 3.6 features really worth
> it?  There must be a lot of Linuces at Python 3.5, even at the most
> recent distribution.  Was there by any chance a majority of conda
> users on the call?
>
> Cheers,
>
> Matthew
> _______________________________________________
> 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/20180212/f009feab/attachment-0001.html>

From vincent.adrien at gmail.com  Mon Feb 12 18:54:33 2018
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Mon, 12 Feb 2018 15:54:33 -0800
Subject: [Matplotlib-devel] What minimum version of python3?
In-Reply-To: <CAJXewOmMdV9CBcNUdZjNP3cTdGE-CTjk7CvXKssbxBCjTgC5rw@mail.gmail.com>
References: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>
 <CAH6Pt5rA8w35d+Z5S7cRmnrExwTvrUdRdMY=P8U7hfOfz4y44Q@mail.gmail.com>
 <CAJXewOmMdV9CBcNUdZjNP3cTdGE-CTjk7CvXKssbxBCjTgC5rw@mail.gmail.com>
Message-ID: <d9fca711-60f2-1f46-00a3-7fd68f5d0af9@gmail.com>

Well, I do not know how accurate is the following script:
https://github.com/Mariatta/python_versions_and_distros
but looking at the list it returned on 2017-10-15, it looks like Python 
3.6+ may be quite common **outside of the usual left-behind 
distributions ala Debian stable or CentOS**.

Adrien,
conda lover since he had to work with CentOS ^^...

On 02/12/2018 03:48 PM, Nathan Goldbaum wrote:
> Ubuntu 14.04 (which admittedly goes EOL in April) is still on python 
> 3.4, for example.
> 
> On Mon, Feb 12, 2018 at 5:28 PM Matthew Brett <matthew.brett at gmail.com 
> <mailto:matthew.brett at gmail.com>> wrote:
> 
>     On Mon, Feb 12, 2018 at 10:40 PM, Thomas Caswell <tcaswell at gmail.com
>     <mailto:tcaswell at gmail.com>> wrote:
>      > These are derived from today's call:
>      >
>      > Pro 3.6:
>      >? - by the time we release, 3.7 will be out so will support "two
>     most recent
>      > python"
>      >? ? ?- this gives 3 years of support on master of each python version
>      > (assuming python sticks
>      >? - ordered, faster dictionaries (as implementation detail in 3.6,
>     guaranteed
>      > in 3.7)
>      >? - guaranteed ordered kwargs / class definitions (do precedence of
>      > conflicting kwaargs)
>      >? - fstrings
>      >? - fspath / pathlib protocol
>      >
>      > Con 3.6:
>      >? - feels a bit agressive as 3.7 is not out yet
>      >? - might get ahead of some LTS releases
>      >? ? - but older version of Matplotlib will still work
>      >? ? - user-space environments go along way to fixing this
>      >? ? ? - conda
>      >? ? ? -
>      >
>     https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7
>      >? ? - ubuntu 18.04 is planned to be py3.6 by default
>      >
>      > Pro 3.5:
>      >? - more conservative approach
>      >? - pypy3 support (but they will support 3.6 eventually)
>      >
>      > The consensus on the call and on gitter seems to be for 3.6 as
>     the minimum.
> 
>     Man - that seems pretty extreme.? ?Are the 3.6 features really worth
>     it?? There must be a lot of Linuces at Python 3.5, even at the most
>     recent distribution.? Was there by any chance a majority of conda
>     users on the call?
> 
>     Cheers,
> 
>     Matthew
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel at python.org <mailto: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
> 


From chris.barker at noaa.gov  Mon Feb 12 20:56:34 2018
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Mon, 12 Feb 2018 17:56:34 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
Message-ID: <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>

Object Oriented seems to be a good demarcation,


I don?t think so? writing OO code, that is defining your own classes,
subclassing, etc. is non-beginner, but calling methods on existing objects
is not: you can?t get very far in python without using the methods of the
buil-ins: lists, dicts, strings....

but since the suggested way of interacting with mpl is through the OO


Which does mean calling methods on objects, but that?s about it.

 they're all pyplot, but that seems to be the preferred intro-and I wonder
if it'd be good for matplotlib to have more bridge documentation that
doesn't just show how to do things both ways but explains why the OO way is
better.


Yup. And I don?t think pyplot is any easier for newbies?other than existing
Matlab users ? admittedly a big group.

Also a proper simple but object oriented tutorial might help here.  Ben
Root and Nicolas Rougier's  tutorials are in this direction.


Yes!!

I say introduce the OO interface, then have a ?matplotlib for Matlab users?
section to translate for them.
.

I'd love to get as many profiles as possible up front.


Just now thought that ?Matlab user? is a profile to keep
In mind.

Pretty basic self assessment questions: What's your fluency with Python?
How long have you been using Python? How long have you been using
Matplolib?


What other languages/plotting libraries are you comfortable with?

-CHB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/7fb12549/attachment.html>

From chris.barker at noaa.gov  Mon Feb 12 21:00:04 2018
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Mon, 12 Feb 2018 18:00:04 -0800
Subject: [Matplotlib-devel] What minimum version of python3?
In-Reply-To: <d9fca711-60f2-1f46-00a3-7fd68f5d0af9@gmail.com>
References: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>
 <CAH6Pt5rA8w35d+Z5S7cRmnrExwTvrUdRdMY=P8U7hfOfz4y44Q@mail.gmail.com>
 <CAJXewOmMdV9CBcNUdZjNP3cTdGE-CTjk7CvXKssbxBCjTgC5rw@mail.gmail.com>
 <d9fca711-60f2-1f46-00a3-7fd68f5d0af9@gmail.com>
Message-ID: <CALGmxE+pQQppTpStZQeteyDcDjvfdu7q0u-CJxb5i1a1jk_ZXA@mail.gmail.com>

How many people are using the district-supplied python these days?

Do they need the latest MPL?

I have literally no idea.

-CHB

Sent from my iPhone

> On Feb 12, 2018, at 3:54 PM, "vincent.adrien at gmail.com" <vincent.adrien at gmail.com> wrote:
>
> Well, I do not know how accurate is the following script:
> https://github.com/Mariatta/python_versions_and_distros
> but looking at the list it returned on 2017-10-15, it looks like Python 3.6+ may be quite common **outside of the usual left-behind distributions ala Debian stable or CentOS**.
>
> Adrien,
> conda lover since he had to work with CentOS ^^...
>
>> On 02/12/2018 03:48 PM, Nathan Goldbaum wrote:
>> Ubuntu 14.04 (which admittedly goes EOL in April) is still on python 3.4, for example.
>> On Mon, Feb 12, 2018 at 5:28 PM Matthew Brett <matthew.brett at gmail.com <mailto:matthew.brett at gmail.com>> wrote:
>>    On Mon, Feb 12, 2018 at 10:40 PM, Thomas Caswell <tcaswell at gmail.com
>>    <mailto:tcaswell at gmail.com>> wrote:
>>     > These are derived from today's call:
>>     >
>>     > Pro 3.6:
>>     >  - by the time we release, 3.7 will be out so will support "two
>>    most recent
>>     > python"
>>     >     - this gives 3 years of support on master of each python version
>>     > (assuming python sticks
>>     >  - ordered, faster dictionaries (as implementation detail in 3.6,
>>    guaranteed
>>     > in 3.7)
>>     >  - guaranteed ordered kwargs / class definitions (do precedence of
>>     > conflicting kwaargs)
>>     >  - fstrings
>>     >  - fspath / pathlib protocol
>>     >
>>     > Con 3.6:
>>     >  - feels a bit agressive as 3.7 is not out yet
>>     >  - might get ahead of some LTS releases
>>     >    - but older version of Matplotlib will still work
>>     >    - user-space environments go along way to fixing this
>>     >      - conda
>>     >      -
>>     >
>>    https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7
>>     >    - ubuntu 18.04 is planned to be py3.6 by default
>>     >
>>     > Pro 3.5:
>>     >  - more conservative approach
>>     >  - pypy3 support (but they will support 3.6 eventually)
>>     >
>>     > The consensus on the call and on gitter seems to be for 3.6 as
>>    the minimum.
>>    Man - that seems pretty extreme.   Are the 3.6 features really worth
>>    it?  There must be a lot of Linuces at Python 3.5, even at the most
>>    recent distribution.  Was there by any chance a majority of conda
>>    users on the call?
>>    Cheers,
>>    Matthew
>>    _______________________________________________
>>    Matplotlib-devel mailing list
>>    Matplotlib-devel at python.org <mailto: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

From pmhobson at gmail.com  Mon Feb 12 21:13:12 2018
From: pmhobson at gmail.com (Paul Hobson)
Date: Mon, 12 Feb 2018 18:13:12 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
Message-ID: <CADT3MEBxuF0y+EZ_P2-7Gk7ryLsrUJ63f3Oe3K2Y=sDa0Msu3g@mail.gmail.com>

On Mon, Feb 12, 2018 at 5:56 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

> Object Oriented seems to be a good demarcation,
>
>
> I don?t think so? writing OO code, that is defining your own classes,
> subclassing, etc. is non-beginner, but calling methods on existing objects
> is not: you can?t get very far in python without using the methods of the
> buil-ins: lists, dicts, strings....
>
> but since the suggested way of interacting with mpl is through the OO
>
>
> Which does mean calling methods on objects, but that?s about it.
>
>  they're all pyplot, but that seems to be the preferred intro-and I wonder
> if it'd be good for matplotlib to have more bridge documentation that
> doesn't just show how to do things both ways but explains why the OO way is
> better.
>
>
> Yup. And I don?t think pyplot is any easier for newbies?other than
> existing Matlab users ? admittedly a big group.
>
> Also a proper simple but object oriented tutorial might help here.  Ben
> Root and Nicolas Rougier's  tutorials are in this direction.
>
>
> Yes!!
>
> I say introduce the OO interface, then have a ?matplotlib for Matlab
> users? section to translate for them.
> .
>
> I'd love to get as many profiles as possible up front.
>
>
> Just now thought that ?Matlab user? is a profile to keep
> In mind.
>
> Pretty basic self assessment questions: What's your fluency with Python?
> How long have you been using Python? How long have you been using
> Matplolib?
>
>
> What other languages/plotting libraries are you comfortable with?
>
> -CHB
>

I like where this discussion is going. If I could wave a magic wand, I set
up two parallel introductory tutorials:
1) for all new comers: show basic plotting and customization with the OO
interface
2) for new comers with MATLAB backgrounds:  show basic plotting and
customization with pyplot on the left and the OO interface on the right

-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/183f6428/attachment-0001.html>

From story645 at gmail.com  Mon Feb 12 21:26:19 2018
From: story645 at gmail.com (Hannah)
Date: Mon, 12 Feb 2018 21:26:19 -0500
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
Message-ID: <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>

On Mon, Feb 12, 2018 at 8:56 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

>
> but calling methods on existing objects is not: you can?t get very far in
> python without using the methods of the buil-ins: lists, dicts, strings....
>

I agree that you can't get very far in Python without it, but it still
majorly confuses the audiences I work with. Quite literally, the
demarcation my fellowship makes between the Python 101 and 201 we teach is
how explicitly we go into using objects. So I think an intro should provide
at least a soft explanation of methods/objects/etc.


>  they're all pyplot, but that seems to be the preferred intro-and I wonder
> if it'd be good for matplotlib to have more bridge documentation that
> doesn't just show how to do things both ways but explains why the OO way is
> better.
>
>
> Yup. And I don?t think pyplot is any easier for newbies?other than
> existing Matlab users ? admittedly a big group.
>

It is and it isn't. While it's technically still OO, I think it ends up
feeling weirdly declarative just keep layering these things (kinda like
ggplot), rather than the explicit here's an axis and attach information to
it. It seems like a super trivial distinction but I think it may be a
barrier for some people (also why I think a survey could be good here.)


> I say introduce the OO interface, then have a ?matplotlib for Matlab
> users? section to translate for them.
>
I like this approach too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180212/3279a0ff/attachment.html>

From marcidy at gmail.com  Mon Feb 12 22:48:05 2018
From: marcidy at gmail.com (Matt Arcidy)
Date: Mon, 12 Feb 2018 19:48:05 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
Message-ID: <CA+U3c5a16vypH=AqCYwLDQaruiHAEz-0E8_Opp=j3LKm+Gtk6g@mail.gmail.com>

Just for fun, I made graphs (too big to send, hosted here:
http://arcidy.com) from the backref information.  Functions used in
examples/tutorials are blue,  examples/tutorials are green.  Red edges
are from functions used in more than 10 tutorials to any tutorial that
uses the function.
- "full.png" has everything
- "filtered.png" as the top 10 most used functions removed.  e.g.
usual suspects like pyplot.plot()
They are big and I have residential internet, so might need a small
bit of patience.

Curious if it inspires ideas for analysis.  Longest path?  shortest
path?  what would these even mean?  I'm working on clustering
functions by module, or other groupings.
If you have ideas to analyze it, or you want any code or other format
(e.g. dot) please let me know.  This is all built off the backrefs
from the gallery, so thank you very much for that.  There's structure
so i just need to keep digging.

As an example, I noted there are separate "pyplot.subplot" (<- no 's')
and "pyplot.subplots" tutorials.  Maybe they could be in the same
examples, as one is a wrapper for the other.  Just an example, not
necessarily a good one.

Some specific comments below, but I'm on board with OO.



On Mon, Feb 12, 2018 at 6:26 PM, Hannah <story645 at gmail.com> wrote:
>
>
> On Mon, Feb 12, 2018 at 8:56 PM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>>
>>
>> but calling methods on existing objects is not: you can?t get very far in
>> python without using the methods of the buil-ins: lists, dicts, strings....
>
>
> I agree that you can't get very far in Python without it, but it still
> majorly confuses the audiences I work with. Quite literally, the demarcation
> my fellowship makes between the Python 101 and 201 we teach is how
> explicitly we go into using objects. So I think an intro should provide at
> least a soft explanation of methods/objects/etc.
>
>>
>>  they're all pyplot, but that seems to be the preferred intro-and I wonder
>> if it'd be good for matplotlib to have more bridge documentation that
>> doesn't just show how to do things both ways but explains why the OO way is
>> better.
>>
>>
>> Yup. And I don?t think pyplot is any easier for newbies?other than
>> existing Matlab users ? admittedly a big group.
The biggest issue I had with pyplot was finding it's limitations.  I
saw that coloring every marker a different color on a line is
possible, which leads me to the documentation for various objects, but
I eventually find that I can't do that with pyplot, I can only provide
one color per line.  There's a mix of undocumented features and
undocumented limitations (or maybe I couldn't find them, but even
then).   stackexchange has an API to search questions, at some point
will be fun/impossible to mine it.
>
>
> It is and it isn't. While it's technically still OO, I think it ends up
> feeling weirdly declarative just keep layering these things (kinda like
> ggplot), rather than the explicit here's an axis and attach information to
> it. It seems like a super trivial distinction but I think it may be a
> barrier for some people (also why I think a survey could be good here.)
>
>>
>> I say introduce the OO interface, then have a ?matplotlib for Matlab
>> users? section to translate for them.
>
> I like this approach too.
Agree, users don't need to know they are Object Oriented programming.
I believe Ben created a single image with everything labeled (tick,
marker, etc).  Learning the words/labels might be a sufficient
understanding of Plot Objects without requiring OO programming.  Just
programming with Plot Objects.  Which object to start with?  I was
thinking Figure because if the first thing you "see" and then drilling
down, but not at all married to it.  That could be considered
backwards but at the end of the day Figure is what get's modified so a
narrative arc about what's happening to the figure might work.

>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>

From tcaswell at gmail.com  Mon Feb 12 23:38:38 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 13 Feb 2018 04:38:38 +0000
Subject: [Matplotlib-devel] What minimum version of python3?
In-Reply-To: <CALGmxE+pQQppTpStZQeteyDcDjvfdu7q0u-CJxb5i1a1jk_ZXA@mail.gmail.com>
References: <CAA48SF95n_ZFp2iECnwVwT6DSmGiS0SwGhAKvg8jXyadhPnLLA@mail.gmail.com>
 <CAH6Pt5rA8w35d+Z5S7cRmnrExwTvrUdRdMY=P8U7hfOfz4y44Q@mail.gmail.com>
 <CAJXewOmMdV9CBcNUdZjNP3cTdGE-CTjk7CvXKssbxBCjTgC5rw@mail.gmail.com>
 <d9fca711-60f2-1f46-00a3-7fd68f5d0af9@gmail.com>
 <CALGmxE+pQQppTpStZQeteyDcDjvfdu7q0u-CJxb5i1a1jk_ZXA@mail.gmail.com>
Message-ID: <CAA48SF9ScjoZmWJrnk0DbsZ2e+_Lk5APNHFCarb1mRg2ZOP1GQ@mail.gmail.com>

We are talking about a release scheduled for July/August 2018 when 3.7 will
already be out and 3.6 will have been out for ~20 months so support
coverage will only get better.

>From the point of view of distributions, I am mostly worried about running
into an issue with a distribution that will not be able to package
Matplotlib.  Are there any distributions that _will_ want to package mpl
3.0 in August and will _not_ have 3.6 available in August?

If people are using system python / Matplotlib on older versions of OSs,
then they are using the old version that is packaged and are OK.  If they
want to build user-space envs there are a bunch of options (pyenv, conda,
activestate) which all current support python 3.6 as well as PPAs / IUS /
.. for system level 3.6.

I think it is incumbent on those advocating we support 3.5 to produce any
sort of estimate of the harm for dropping 3.5.

I am advocating a policy of 'last 2 python feature releases' (which is what
I remember from when I first started working on Matplotlib), what is the
alternative proposal?

As I have said before, I think the community's expectations have been
warped by having to support and provide new features for an almost decade
old version of python.

As a final fallback, the 2.2 series will continue to support 3.4 and 3.5
until 2020.

Tom

On Mon, Feb 12, 2018 at 9:00 PM Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

> How many people are using the district-supplied python these days?
>
> Do they need the latest MPL?
>
> I have literally no idea.
>
> -CHB
>
> Sent from my iPhone
>
> > On Feb 12, 2018, at 3:54 PM, "vincent.adrien at gmail.com" <
> vincent.adrien at gmail.com> wrote:
> >
> > Well, I do not know how accurate is the following script:
> > https://github.com/Mariatta/python_versions_and_distros
> > but looking at the list it returned on 2017-10-15, it looks like Python
> 3.6+ may be quite common **outside of the usual left-behind distributions
> ala Debian stable or CentOS**.
> >
> > Adrien,
> > conda lover since he had to work with CentOS ^^...
> >
> >> On 02/12/2018 03:48 PM, Nathan Goldbaum wrote:
> >> Ubuntu 14.04 (which admittedly goes EOL in April) is still on python
> 3.4, for example.
> >> On Mon, Feb 12, 2018 at 5:28 PM Matthew Brett <matthew.brett at gmail.com
> <mailto:matthew.brett at gmail.com>> wrote:
> >>    On Mon, Feb 12, 2018 at 10:40 PM, Thomas Caswell <tcaswell at gmail.com
> >>    <mailto:tcaswell at gmail.com>> wrote:
> >>     > These are derived from today's call:
> >>     >
> >>     > Pro 3.6:
> >>     >  - by the time we release, 3.7 will be out so will support "two
> >>    most recent
> >>     > python"
> >>     >     - this gives 3 years of support on master of each python
> version
> >>     > (assuming python sticks
> >>     >  - ordered, faster dictionaries (as implementation detail in 3.6,
> >>    guaranteed
> >>     > in 3.7)
> >>     >  - guaranteed ordered kwargs / class definitions (do precedence of
> >>     > conflicting kwaargs)
> >>     >  - fstrings
> >>     >  - fspath / pathlib protocol
> >>     >
> >>     > Con 3.6:
> >>     >  - feels a bit agressive as 3.7 is not out yet
> >>     >  - might get ahead of some LTS releases
> >>     >    - but older version of Matplotlib will still work
> >>     >    - user-space environments go along way to fixing this
> >>     >      - conda
> >>     >      -
> >>     >
> >>
> https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7
> >>     >    - ubuntu 18.04 is planned to be py3.6 by default
> >>     >
> >>     > Pro 3.5:
> >>     >  - more conservative approach
> >>     >  - pypy3 support (but they will support 3.6 eventually)
> >>     >
> >>     > The consensus on the call and on gitter seems to be for 3.6 as
> >>    the minimum.
> >>    Man - that seems pretty extreme.   Are the 3.6 features really worth
> >>    it?  There must be a lot of Linuces at Python 3.5, even at the most
> >>    recent distribution.  Was there by any chance a majority of conda
> >>    users on the call?
> >>    Cheers,
> >>    Matthew
> >>    _______________________________________________
> >>    Matplotlib-devel mailing list
> >>    Matplotlib-devel at python.org <mailto: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/20180213/d3ada13d/attachment-0001.html>

From chris.barker at noaa.gov  Tue Feb 13 11:12:24 2018
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Tue, 13 Feb 2018 08:12:24 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
Message-ID: <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>

I agree that you can't get very far in Python without it, but it still
majorly confuses the audiences I work with. Quite literally, the
demarcation my fellowship makes between the Python 101 and 201 we teach is
how explicitly we go into using objects. So I think an intro should provide
at least a soft explanation of methods/objects/etc.


THIS is maybe the core issue? are we introducing people to matplotlib, or
to the python language via matplotlib. Indeed, to programming itself?

Each of these requires a different type of introduction.

Maybe multiple entry points:

- Know Basic Python?
- Know another programming language?
- New to programming?

Personally, I think it?s ?better? to learn the basics of Python first, and
then introduce the scipy stack, but the reality is that people have work to
accomplish, and it?s often best to learn by solving a problem that
interests you ? so we should support that.

 they're all pyplot,
>
>
The challenge with pyplot is the learning curve ? it?s great to able to
simply start with:

plot(x, y)



but that seems to be the preferred intro-and I wonder if it'd be good for
> matplotlib to have more bridge documentation that doesn't just show how to
> do things both ways but explains why the OO way is better.
>
>
> Yup. And I don?t think pyplot is any easier for newbies?other than
> existing Matlab users ? admittedly a big group.
>

It is and it isn't. While it's technically still OO, I think it ends up
feeling weirdly declarative just keep layering these things (kinda like
ggplot), rather than the explicit here's an axis and attach information to
it. It seems like a super trivial distinction but I think it may be a
barrier for some people (also why I think a survey could be good here.)


> I say introduce the OO interface, then have a ?matplotlib for Matlab
> users? section to translate for them.
>
I like this approach too.

_______________________________________________
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/20180213/305ad8ac/attachment.html>

From marcidy at gmail.com  Tue Feb 13 12:23:36 2018
From: marcidy at gmail.com (Matt Arcidy)
Date: Tue, 13 Feb 2018 17:23:36 +0000
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
Message-ID: <CA+U3c5bggXp3H5sCgFq4SfPCb8KNN_q6kx=g=iS-vsRb8bo6VQ@mail.gmail.com>

I agree, though I'm curious if we still can't get one entry point which
then fans out.  very basic, pyplot.plot() even.  more about plotting than
python, matplotlib, math, geometry, etc.

I bet I can hack the Sphinx script to pull all imported/used modules and
functions except built -ins.  The examples/tutorials can be tagged with
"requires/suggests knowing..." any non-matplotlib function.

People then filter based on matplotlib tags of what they need to learn and
select the examples that fit based on the python they are familiar with.

theoretically I can mock this up.

Before doing too much more, I would love to hear any dissenting opinions or
even explicit support.  I have been involved in too many projects that
ended in a bridge to nowhere.  I'll ask on gitter too.

I definitely want to talk about surveying, I think no matter what that is
required.

On Tue, Feb 13, 2018, 08:12 Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

>
> I agree that you can't get very far in Python without it, but it still
> majorly confuses the audiences I work with. Quite literally, the
> demarcation my fellowship makes between the Python 101 and 201 we teach is
> how explicitly we go into using objects. So I think an intro should provide
> at least a soft explanation of methods/objects/etc.
>
>
> THIS is maybe the core issue? are we introducing people to matplotlib, or
> to the python language via matplotlib. Indeed, to programming itself?
>
> Each of these requires a different type of introduction.
>
> Maybe multiple entry points:
>
> - Know Basic Python?
> - Know another programming language?
> - New to programming?
>
> Personally, I think it?s ?better? to learn the basics of Python first, and
> then introduce the scipy stack, but the reality is that people have work to
> accomplish, and it?s often best to learn by solving a problem that
> interests you ? so we should support that.
>
>  they're all pyplot,
>>
>>
> The challenge with pyplot is the learning curve ? it?s great to able to
> simply start with:
>
> plot(x, y)
>
>
>
> but that seems to be the preferred intro-and I wonder if it'd be good for
>> matplotlib to have more bridge documentation that doesn't just show how to
>> do things both ways but explains why the OO way is better.
>>
>>
>> Yup. And I don?t think pyplot is any easier for newbies?other than
>> existing Matlab users ? admittedly a big group.
>>
>
> It is and it isn't. While it's technically still OO, I think it ends up
> feeling weirdly declarative just keep layering these things (kinda like
> ggplot), rather than the explicit here's an axis and attach information to
> it. It seems like a super trivial distinction but I think it may be a
> barrier for some people (also why I think a survey could be good here.)
>
>
>> I say introduce the OO interface, then have a ?matplotlib for Matlab
>> users? section to translate for them.
>>
> I like this approach too.
>
> _______________________________________________
> 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/20180213/1cbbe135/attachment.html>

From chris.barker at noaa.gov  Tue Feb 13 12:34:05 2018
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 13 Feb 2018 09:34:05 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
Message-ID: <CALGmxE+7uaDPAvcb7b-9kP5UxHqz87P-VWM1pNfXmnrFMDjkFQ@mail.gmail.com>

Sorry -- way too easy to hit send on my phone....

On Tue, Feb 13, 2018 at 8:12 AM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

> The challenge with pyplot is the learning curve ? it?s great to able to
> simply start with:
>
> plot(x, y)
>

and get the first plot -- like the classic:

print("hello world")

But you'll eventually run into limitations of the pyplot interface, and by
then you will have learned a lot of bad habits.

I think the challenge with the OO interface is not so much that you need to
use, say:

ax.set_title()

rather than simply

title()

But that you need to do SOMETHING to get that axis object in the first
place. And given that to make an axis object you need a figure object
first, it's just not as clean as it might be.

But I think that's a significant but small bump in the road on day one....

NOTE: is there any talk of updating the main axis interface to get away
from all the "set_*" methods? they are kind of ugly.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180213/72597211/attachment.html>

From chris.barker at noaa.gov  Tue Feb 13 12:38:51 2018
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 13 Feb 2018 09:38:51 -0800
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CA+U3c5bggXp3H5sCgFq4SfPCb8KNN_q6kx=g=iS-vsRb8bo6VQ@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
 <CA+U3c5bggXp3H5sCgFq4SfPCb8KNN_q6kx=g=iS-vsRb8bo6VQ@mail.gmail.com>
Message-ID: <CALGmxE+au7pg79wRj9noqVYhwk4kPUvk5JaJic8kcY=NEc8SJA@mail.gmail.com>

On Tue, Feb 13, 2018 at 9:23 AM, Matt Arcidy <marcidy at gmail.com> wrote:

> I agree, though I'm curious if we still can't get one entry point which
> then fans out.  very basic, pyplot.plot() even.  more about plotting than
> python, matplotlib, math, geometry, etc.
>

sure -- but you can't use matplotlib if you don't know how to call a method
(or a function), and maybe a bit about keyword arguments, etc. Granted,
many (most?) folks learn well by simply following examples -- show them
what to type, and they'll adapt it to their needs, but I think newbies
would really benefit from a bit more of the "why you type it this way", and
more experienced folks will find that annoying.

Maybe optional "sidebars" in the initial tutorial? -- links to "how this
works" kinds of things.

For instance, the first time a keyword argument is used, a link to a brief
tutorial on keyword arguments. If people want to know more, they follow
that link -- if they already understand kw args, then then skip on by...

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180213/9432d38f/attachment-0001.html>

From tcaswell at gmail.com  Tue Feb 13 12:57:25 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 13 Feb 2018 17:57:25 +0000
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
Message-ID: <CAA48SF_B7tgHfFc=rbfbGodJCSfQe-L3UcDH2d2+Cpz4bf10_Q@mail.gmail.com>

For the 'brand new to python' users, can we handle that by linking out to
the Scoptaz&Huff[1], VanderPlas [2], or SW carpentry material?

[1] http://shop.oreilly.com/product/0636920033424.do
[2] http://shop.oreilly.com/product/0636920034919.do

On Tue, Feb 13, 2018 at 11:12 AM Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

>
> I agree that you can't get very far in Python without it, but it still
> majorly confuses the audiences I work with. Quite literally, the
> demarcation my fellowship makes between the Python 101 and 201 we teach is
> how explicitly we go into using objects. So I think an intro should provide
> at least a soft explanation of methods/objects/etc.
>
>
> THIS is maybe the core issue? are we introducing people to matplotlib, or
> to the python language via matplotlib. Indeed, to programming itself?
>
> Each of these requires a different type of introduction.
>
> Maybe multiple entry points:
>
> - Know Basic Python?
> - Know another programming language?
> - New to programming?
>
> Personally, I think it?s ?better? to learn the basics of Python first, and
> then introduce the scipy stack, but the reality is that people have work to
> accomplish, and it?s often best to learn by solving a problem that
> interests you ? so we should support that.
>
>  they're all pyplot,
>>
>>
> The challenge with pyplot is the learning curve ? it?s great to able to
> simply start with:
>
> plot(x, y)
>
>
>
> but that seems to be the preferred intro-and I wonder if it'd be good for
>> matplotlib to have more bridge documentation that doesn't just show how to
>> do things both ways but explains why the OO way is better.
>>
>>
>> Yup. And I don?t think pyplot is any easier for newbies?other than
>> existing Matlab users ? admittedly a big group.
>>
>
> It is and it isn't. While it's technically still OO, I think it ends up
> feeling weirdly declarative just keep layering these things (kinda like
> ggplot), rather than the explicit here's an axis and attach information to
> it. It seems like a super trivial distinction but I think it may be a
> barrier for some people (also why I think a survey could be good here.)
>
>
>> I say introduce the OO interface, then have a ?matplotlib for Matlab
>> users? section to translate for them.
>>
> I like this approach too.
>
> _______________________________________________
> 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/20180213/3763fcef/attachment.html>

From max.linke88 at gmail.com  Tue Feb 13 15:29:27 2018
From: max.linke88 at gmail.com (Max Linke)
Date: Tue, 13 Feb 2018 20:29:27 +0000
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAA48SF_B7tgHfFc=rbfbGodJCSfQe-L3UcDH2d2+Cpz4bf10_Q@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
 <CAA48SF_B7tgHfFc=rbfbGodJCSfQe-L3UcDH2d2+Cpz4bf10_Q@mail.gmail.com>
Message-ID: <CAKRyePAzKCnoT825V3bP_5gq7Nr9bGW+qgdb1WnkNBG-mtrp2g@mail.gmail.com>

For starting with matplotlib and the OO interface I found the `anatomy of
matplotlib` talks a good introduction.
I recommend it to new students in my group to learn matplotlib.

https://www.youtube.com/results?search_query=anatomy+of+matplotlib+

On Tue, Feb 13, 2018 at 6:57 PM Thomas Caswell <tcaswell at gmail.com> wrote:

> For the 'brand new to python' users, can we handle that by linking out to
> the Scoptaz&Huff[1], VanderPlas [2], or SW carpentry material?
>
> [1] http://shop.oreilly.com/product/0636920033424.do
> [2] http://shop.oreilly.com/product/0636920034919.do
>
> On Tue, Feb 13, 2018 at 11:12 AM Chris Barker - NOAA Federal <
> chris.barker at noaa.gov> wrote:
>
>>
>> I agree that you can't get very far in Python without it, but it still
>> majorly confuses the audiences I work with. Quite literally, the
>> demarcation my fellowship makes between the Python 101 and 201 we teach is
>> how explicitly we go into using objects. So I think an intro should provide
>> at least a soft explanation of methods/objects/etc.
>>
>>
>> THIS is maybe the core issue? are we introducing people to matplotlib, or
>> to the python language via matplotlib. Indeed, to programming itself?
>>
>> Each of these requires a different type of introduction.
>>
>> Maybe multiple entry points:
>>
>> - Know Basic Python?
>> - Know another programming language?
>> - New to programming?
>>
>> Personally, I think it?s ?better? to learn the basics of Python first,
>> and then introduce the scipy stack, but the reality is that people have
>> work to accomplish, and it?s often best to learn by solving a problem that
>> interests you ? so we should support that.
>>
>>  they're all pyplot,
>>>
>>>
>> The challenge with pyplot is the learning curve ? it?s great to able to
>> simply start with:
>>
>> plot(x, y)
>>
>>
>>
>> but that seems to be the preferred intro-and I wonder if it'd be good for
>>> matplotlib to have more bridge documentation that doesn't just show how to
>>> do things both ways but explains why the OO way is better.
>>>
>>>
>>> Yup. And I don?t think pyplot is any easier for newbies?other than
>>> existing Matlab users ? admittedly a big group.
>>>
>>
>> It is and it isn't. While it's technically still OO, I think it ends up
>> feeling weirdly declarative just keep layering these things (kinda like
>> ggplot), rather than the explicit here's an axis and attach information to
>> it. It seems like a super trivial distinction but I think it may be a
>> barrier for some people (also why I think a survey could be good here.)
>>
>>
>>> I say introduce the OO interface, then have a ?matplotlib for Matlab
>>> users? section to translate for them.
>>>
>> I like this approach too.
>>
>> _______________________________________________
>> 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/20180213/41bd87fc/attachment-0001.html>

From chris.barker at noaa.gov  Tue Feb 13 18:20:08 2018
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Tue, 13 Feb 2018 18:20:08 -0500
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAA48SF_B7tgHfFc=rbfbGodJCSfQe-L3UcDH2d2+Cpz4bf10_Q@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
 <CAA48SF_B7tgHfFc=rbfbGodJCSfQe-L3UcDH2d2+Cpz4bf10_Q@mail.gmail.com>
Message-ID: <CALGmxEKNx-iwPQvbYv-VRyX7vqoQk1UWZ5YT29Z5s1gjcLtPpg@mail.gmail.com>

On Feb 13, 2018, at 9:57 AM, Thomas Caswell <tcaswell at gmail.com> wrote:

For the 'brand new to python' users, can we handle that by linking out to
the Scoptaz&Huff[1], VanderPlas [2], or SW carpentry material?


Well, yes ? maybe best to not take on too much!

-CHB

[1] http://shop.oreilly.com/product/0636920033424.do
[2] http://shop.oreilly.com/product/0636920034919.do

On Tue, Feb 13, 2018 at 11:12 AM Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

>
> I agree that you can't get very far in Python without it, but it still
> majorly confuses the audiences I work with. Quite literally, the
> demarcation my fellowship makes between the Python 101 and 201 we teach is
> how explicitly we go into using objects. So I think an intro should provide
> at least a soft explanation of methods/objects/etc.
>
>
> THIS is maybe the core issue? are we introducing people to matplotlib, or
> to the python language via matplotlib. Indeed, to programming itself?
>
> Each of these requires a different type of introduction.
>
> Maybe multiple entry points:
>
> - Know Basic Python?
> - Know another programming language?
> - New to programming?
>
> Personally, I think it?s ?better? to learn the basics of Python first, and
> then introduce the scipy stack, but the reality is that people have work to
> accomplish, and it?s often best to learn by solving a problem that
> interests you ? so we should support that.
>
>  they're all pyplot,
>>
>>
> The challenge with pyplot is the learning curve ? it?s great to able to
> simply start with:
>
> plot(x, y)
>
>
>
> but that seems to be the preferred intro-and I wonder if it'd be good for
>> matplotlib to have more bridge documentation that doesn't just show how to
>> do things both ways but explains why the OO way is better.
>>
>>
>> Yup. And I don?t think pyplot is any easier for newbies?other than
>> existing Matlab users ? admittedly a big group.
>>
>
> It is and it isn't. While it's technically still OO, I think it ends up
> feeling weirdly declarative just keep layering these things (kinda like
> ggplot), rather than the explicit here's an axis and attach information to
> it. It seems like a super trivial distinction but I think it may be a
> barrier for some people (also why I think a survey could be good here.)
>
>
>> I say introduce the OO interface, then have a ?matplotlib for Matlab
>> users? section to translate for them.
>>
> I like this approach too.
>
> _______________________________________________
> 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/20180213/8f263682/attachment.html>

From story645 at gmail.com  Tue Feb 13 18:24:03 2018
From: story645 at gmail.com (Hannah)
Date: Tue, 13 Feb 2018 18:24:03 -0500
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CALGmxE+au7pg79wRj9noqVYhwk4kPUvk5JaJic8kcY=NEc8SJA@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
 <CA+U3c5bggXp3H5sCgFq4SfPCb8KNN_q6kx=g=iS-vsRb8bo6VQ@mail.gmail.com>
 <CALGmxE+au7pg79wRj9noqVYhwk4kPUvk5JaJic8kcY=NEc8SJA@mail.gmail.com>
Message-ID: <CAOuQ7j2hQ_CqerqdOZ=ofmnm1XkruK1Jv8HNUGvB5NKVHdEg+g@mail.gmail.com>

> For instance, the first time a keyword argument is used, a link to a brief
> tutorial on keyword arguments. If people want to know more, they follow
> that link -- if they already understand kw args, then then skip on by...
>

I think this approach has a good balance of not reinventing the wheel while
also sign posting,

And Matt, I think  creating a narrative of this is a figure, on a figure we
put axes, could probably go a ways towards helping with the "why?" of it
all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180213/a879c612/attachment.html>

From marcidy at gmail.com  Tue Feb 13 19:20:50 2018
From: marcidy at gmail.com (Matt Arcidy)
Date: Wed, 14 Feb 2018 00:20:50 +0000
Subject: [Matplotlib-devel] Documentation
In-Reply-To: <CAOuQ7j2hQ_CqerqdOZ=ofmnm1XkruK1Jv8HNUGvB5NKVHdEg+g@mail.gmail.com>
References: <CA+U3c5bSqOCK4T2Lx_XNc5qZMfm_NTokz7+xXrEhYO3jpGD42g@mail.gmail.com>
 <CAOuQ7j12+-kdSJNLAZrq69OuyYo-X+Zhhxpjd8BYM47OAobJyg@mail.gmail.com>
 <CA+U3c5asR__sYg=+jGhbN5JfzHgZmYgzUaCYCQnNmmz-UiOi=g@mail.gmail.com>
 <CAOuQ7j0pOXzt-djRm1-JbAi6N+D4_qE0SC4ZigdAUi_hcda1xw@mail.gmail.com>
 <CALGmxEJ7aV8rk9Mj2aVr_M=QOfqd7PqO9JpzD-q1wOyOMaZnrQ@mail.gmail.com>
 <CAOuQ7j2EG_Bz=8Lb=iA5eNUG9aefZmRp27DpviGAhJkHp8U8mg@mail.gmail.com>
 <CALGmxE+SQJvvUTmV5Rj6c_VarsECEAj0qbKGq=EdzZoWha04BA@mail.gmail.com>
 <CA+U3c5bggXp3H5sCgFq4SfPCb8KNN_q6kx=g=iS-vsRb8bo6VQ@mail.gmail.com>
 <CALGmxE+au7pg79wRj9noqVYhwk4kPUvk5JaJic8kcY=NEc8SJA@mail.gmail.com>
 <CAOuQ7j2hQ_CqerqdOZ=ofmnm1XkruK1Jv8HNUGvB5NKVHdEg+g@mail.gmail.com>
Message-ID: <CA+U3c5bEp4ugapfGNLWynb6f2SLJ_vgXPnOYfcqGzV6-=OuYvw@mail.gmail.com>

I will add args inspection to my Sphinx hacking.  That will also let me
discriminate functions calls by tutorial/example as well, plus add that
info to search parameters.  plt.plot() usage in examples will greatly
benefit from this.

On Tue, Feb 13, 2018, 15:24 Hannah <story645 at gmail.com> wrote:

>
> For instance, the first time a keyword argument is used, a link to a brief
>> tutorial on keyword arguments. If people want to know more, they follow
>> that link -- if they already understand kw args, then then skip on by...
>>
>
> I think this approach has a good balance of not reinventing the wheel
> while also sign posting,
>
> And Matt, I think  creating a narrative of this is a figure, on a figure
> we put axes, could probably go a ways towards helping with the "why?" of it
> all.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180214/8d565afa/attachment.html>

From tcaswell at gmail.com  Wed Feb 14 14:23:32 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Wed, 14 Feb 2018 19:23:32 +0000
Subject: [Matplotlib-devel] [ANN] Matplotlib v2.2.0rc1
Message-ID: <CAA48SF-XnEgLhAO+y-sUhzXuqvHC-QFMg-BQ1iYjVUwcxFmknQ@mail.gmail.com>

Folks,

We are happy to release Matplotlib v2.2.0rc1!

This is a feature release which includes new functionality (along with many
bug-fixes). One of the hi-lights of this release is a constrained layout
manager, please see https://matplotlib.org/devdocs/users/whats_new.html for
details.

API changes are at https://matplotlib.org/devdocs/api/api_changes.html

The rc can be installed via pip

   pip install --pre matplotlib

or via conda from conda-forge

   conda install -c conda-forge/label/rc matplotlib -c conda-forge

The goal is to do 2.2.0 final around Mar. 2, please test these out and
report bugs this week and next!

mpl2.2 will be the last feature release in the Matplotlib 2.x series and
the last feature release of Matplotlib to support python 2.7 and intend to
provide bug fixes to 2.2 until 2020.  We are looking for someone to take
the lead on maintaining the 2.2.x branch, if you are interested please
reach out!

The next feature release after 2.2 will be 3.0 scheduled for July-August
2018.

Thank you everyone (100+) who contributed to this release!

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180214/3b536dc7/attachment.html>