add rc param for centimeter support

[andreas-h]

It would be great if I could specify a figsize in centimeters. I would like to write

import matplotlib as mpl
mpl.rcParams['lengthunit'] = 'c'
figure(figsize=(12, 8))

instead of

figure(figsize=(12/2.54, 8/2.54))

I think this would be a great addition for the non-anglo-saxon world ;)

[mdboom]

I agree -- requiring inches there is rather archaic. However, I don't think an rcParam is the right way to do it. I'd rather see the unit be part of the parameter, e.g.:

figsize=((12, 'cm', (8, 'cm'))

or

figsize=('12cm', '8cm')

Neither of those are perfect (more thinking needs to be done), but I think changing global state for this could be too problematic.

[pwuertz]

Absolutely love the idea of using "unit-aware" objects instead of numbers for defining lengths and sizes as also stated in #1109.

@mdboom, would you be in favour of a unit-class that supports arithmetic operators like __add__, __mul__, __sub__, etc? So for example one could define figsize = (12*cm, 8*cm) or figsize = (12*cm, 8*cm + 1*mm).

[WeatherGod]

Perhaps something like this?

http://packages.python.org/quantities/user/tutorial.html

[pwuertz]

@WeatherGod, Thanks for the hint! I think I was looking for something like that for quite some time ^^. That tight integration with numpy seems nice. Is anyone imagining the plotting of such data with unit aware axis labelling too? ;)

[dmcdougall]

@pwuertz I don't see the benefit of unit aware plotting/axis labelling. It requires almost no effort to append '(cm)' or '(s)' to my x-axis label. Date/time units are useful, and already supported. What is requested here is nothing to do with unit-aware plotting but physical figure attributes. Perhaps I'm overlooking something.

[pwuertz]

@dmcdougall Of course this is about figure attributes and my original question to mdboom was if he is in favor of a unit class that would support arithmetic operations with ints and floats.

WeatherGod came up with that project that takes this one step further. If matplotlib adapted this package, the idea of supporting it at plot level came to my mind. Think about plotting an array of times. When you decide that you want the plot to be displayed in us instead of ms you could change that at a single position in the code. Rescaling all of the plotted data and adding the correct unit to the label would be handled automatically. Just an idea, completely off-topic.

[dmcdougall]

When you decide that you want the plot to be displayed in us instead of ms you could change that at a single position in the code.

That's a fair point.

[pelson]

@pwuertz : I think it is worthy of a MEP. I love the idea, and would like to see this idea get developed further and discussed before we can make a sound decision about it. Would you be willing to write a MEP?

EDIT: Fixed typo from PEP->MEP. Doh!

[dmcdougall]

Would you be willing to write a PEP?

MEP?

[pelson]

MEP?

Ja ja. Sorry 😃.

[pwuertz]

A MEP for general support of physical units that focuses on properties like figsize and discusses optional features like plotting of unit-aware data?

[mdboom]

I think such a MEP would be great. I see the two pieces: one for parameters like figsize, possible font size as well) and one for unitized data. These pieces can be implemented somewhat independently (i.e. we can do one without the other), but it might be worth discussing them at the same time to contemplate some consistency between the two. We already have lots of the infrastructure for unitized data that is currently used for dates, and it would be worth investigating how that could be extended. For a long time, I've felt good docs on how to add a new unit would be very helpful -- it's not a part of the code that I personally understand very well.

[pelson]

it's not a part of the code that I personally understand very well.

Likewise. I wonder who does?

[WeatherGod]

On Thursday, October 18, 2012, Phil Elson wrote:

it's not a part of the code that I personally understand very well.

Likewise. I wonder who does?

Sadly, I think it was John, but I don't think he implemented it. I know it
was added to address needs from NASA for the MSL lander (or was that the
spline filter for paths?). There was a email in the past six months where
he discusses the history of various parts of mpl. In fact, it might have
been in response to my email awhile back about how mpl got me a job -- in
case anyone wants to go searching.

Ben Root

[pwuertz]

When I got a little more time I'd like to work on these layout managing ideas and possibly write a MEP for that. As pointed out, this would also include support for units. The question is whether to wait for that layout management project (which might be a really long time) or to implement an unit aware figsize option as a more "short term" solution.

[smithsp]

+1 for quantities integration

[WeatherGod]

-1 on quantities integration. The promise is there, but it (and other
similar projects all have short-comings) See this very informative and
illuminating presentation at SciPy 2013

http://bekolay.org/scipy2013-quantities (hit S to see notes)
http://conference.scipy.org/scipy2013/presentation_detail.php?id=174

[andreas-h]

I also think quantities are out of scope.
But being able to give lengths in centimeters would be really helpful.

Benjamin Root notifications@github.com schrieb:

-1 on quantities integration. The promise is there, but it (and other
similar projects all have short-comings) See this very informative and
illuminating presentation at SciPy 2013

http://bekolay.org/scipy2013-quantities (hit S to see notes)
http://conference.scipy.org/scipy2013/presentation_detail.php?id=174

---

Reply to this email directly or view it on GitHub:
#1369 (comment)

[smithsp]

@WeatherGod thanks for the reference. I came across this page because I remember reading in the documentation some time ago about units in matplotlib, but then couldn't find anything that jumped out at me, only to realize that unit support had not been fully integrated in matplotlib.

[mdboom]

What matplotlib calls "unit support" is really the automatic conversion of complex datatypes (specifically datetime objects at this time) into floating point for plotting. It could become the basis for handling any of the available unit/quantity packages available for matplotlib, but it doesn't address any of those at this time.

[Globegitter]

👍 I think just adding support for cm (at least as a short term fix) would make life a bit easier.

[tacaswell]

See #5104 for a possible implementation of this.

[oscarbranson]

Another +1 for implementing this in rcparams. Would be great to be able to 'set and forget' metric units.

[jklymak]

There is even a semi-abandoned MEP: #9226

I think the easiest least-painful idea would be a new method that was able to parse strings for width and height: fig.set_size(width='15cm', height='2in'). Some will complain about hokey parsing, but...

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

[oscargus]

This would still be useful in quite a lot of situations. The most progressed PR seems to be #12415 with quite a lot of discussions about the API.

[jklymak]

I came away from that process convinced this is just they way it is. Figure size is one thing, but points and dpi are deeply embedded in the library.