<div dir="ltr">Improved 3D support has been an ask as long as I have been involved with Matplotlib (and I suspect for as long as the 3D support has existed) and was discussed at scipy 2 years ago, but I don't think there is a specific MEP for it. That note was more meant as "Eric suggested that a thing to ask for money to do would be..." rather than any sort of formal plan or commitment!<div><br></div><div>Tom</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 20, 2017 at 3:25 PM <a href="mailto:vincent.adrien@gmail.com">vincent.adrien@gmail.com</a> <<a href="mailto:vincent.adrien@gmail.com">vincent.adrien@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you Tom for the summary (a well as Ryan and Eric for the meeting<br>
of course).<br>
<br>
Just being curious, does the following point (at the very end of your<br>
email) mean that there is some plan to perform kind of a big overhaul of<br>
mplot3d?<br>
<br>
> ** major funding<br>
> - get mplot3D 'right'<br>
> - same interface<br>
> - uses real 3D tools<br>
<br>
I am asking mainly because I cannot find a MEP about that in the<br>
documentation, even though it seems like a rather major goal/news to me<br>
:). But I may have misunderstood something about what is stated above...<br>
<br>
Best,<br>
Adrien<br>
<br>
<br>
On 11/20/2017 12:06 PM, Thomas Caswell wrote:<br>
> Folks,<br>
><br>
> Notes from today's phone call. There are 3 things left for 2.1.1:<br>
> categorical changes, 'fuzzy' images when mostly invalid, and the<br>
> appevyor cleanup<br>
><br>
> Tom<br>
><br>
> Ryan May, Eric Firing, Thomas Caswell<br>
><br>
> ** categorical<br>
><br>
> - everyone on board with not sorting categorical values<br>
> - everyone on board with only accepting strings as categories<br>
> - some concern about supporting `np.nan`<br>
> - if the first entry in `nan`, will miss units<br>
> - do not want a python loop that chceks until it finds a not-nan<br>
> - defer nan handling<br>
><br>
> Tom's job to get all of the PRs collected an into one<br>
><br>
> Plan going forward to support mixed types, missing data, and explicit<br>
> ordering between categories:<br>
> - write a category class<br>
> - write a handler for pandas categorical<br>
><br>
> ** Tom's pre-meeting notes<br>
><br>
> *** do not sort values<br>
><br>
> On one hand, sorting the values make sense as<br>
><br>
> #+BEGIN_SRC python<br>
> fig, (ax1, ax2) = plt.subplots(2, 1)<br>
> ax1.scatter([1, 2], [1, 2])<br>
> ax2.scatter([2, 1], [2, 1])<br>
><br>
> #+END_SRC<br>
><br>
> should produce visually identical plots so Tom thinks<br>
><br>
><br>
> #+BEGIN_SRC python<br>
> fig, (ax1, ax2) = plt.subplots(2, 1)<br>
> ax1.scatter(['a', 'b'], [1, 2])<br>
> ax2.scatter(['b', 'a'], [2, 1])<br>
><br>
> #+END_SRC<br>
><br>
> should as well (but Tom is wrong).<br>
><br>
> On the other hand, user may expect that there is some semantics in the<br>
> order they pass the data in in<br>
><br>
> #+BEGIN_SRC python<br>
> plt.bar(['first', 'second', 'third'], [1, 2, 3])<br>
><br>
> #+END_SRC<br>
><br>
> and blindly sorting alphabetically gives them no escape hatch.<br>
><br>
> practicality over purity, drop the sorting.<br>
><br>
> *** supporting non-string values<br>
><br>
> In the original implementation a cast through numpy was used which<br>
> converted all non-string values to strings so things like<br>
><br>
> #+BEGIN_SRC python<br>
> plt.bar([1, 2, 'apple'], [1, 2, 3])<br>
><br>
> #+END_SRC<br>
><br>
> would work. However this lead to the =2= and ='2'= being treated as<br>
> the same (which seems less than great). Supporting them as different<br>
> is possible, but is a fair bit of work because a number of places the<br>
> unit framework assumes that 'plain' numbers will pass through<br>
> un-changed.<br>
><br>
> A more worrying concern is that<br>
><br>
> #+BEGIN_SRC python<br>
> x = [52, 32, 'a', 'b']<br>
> y = [0, 1, 2, 3]<br>
><br>
> fig, (ax1, ax2) = plt.subplots()<br>
> ax1.plot(x, y, 'o')<br>
> ax2.plot(x[:2], y[:2], 'x')<br>
><br>
> #+END_SRC<br>
><br>
> in the first case the ints are treated as categoricals and in the<br>
> second they are not. If we want to support mixed types like this then<br>
> we need to make a special class (or use pandas categorical) which does<br>
> not have to guess the type on the fly.<br>
><br>
> requiring if the categorical unit handling is triggered, then all of the<br>
> values<br>
> must be string-like seems like the safest approach.<br>
><br>
> *** support for nan<br>
><br>
> Most of matptollib accepts `np.nan` as 'missing' data which is then<br>
> dropped as part of the draw process. This makes less sense with `bar`<br>
> but makes<br>
> lots of sense with `scatter`.<br>
><br>
> We should special-case allowing `np.nan` in as a 'string' and map it<br>
> map it to it's self.<br>
><br>
> *** special containers<br>
><br>
> It was proposed to look for objects arrays as a marker for catagorical<br>
> instead of the type of the data. Do not think we should do this as we<br>
> try to<br>
> be as agnostic about the container as possible everywhere else.<br>
><br>
><br>
> ** appveyor<br>
> - drop building conda package<br>
> - remove conda recipe from the repo<br>
><br>
> Ryan is taking care of this<br>
><br>
> ** set_theta_grid(frac)<br>
> - merged, improvement over current behavior, raising seems too<br>
> aggressive<br>
><br>
> ** #8947<br>
> - ringing with lots of nans<br>
><br>
> this is Tom's job to investigate<br>
><br>
> ** talked about traits / traitlets and friends<br>
><br>
> ** major funding<br>
> - get mplot3D 'right'<br>
> - same interface<br>
> - uses real 3D tools<br>
><br>
><br>
> _______________________________________________<br>
> Matplotlib-devel mailing list<br>
> <a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
><br>
<br>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div>