[Matplotlib-devel] 2017-11-20 notes

[Thomas Caswell]

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!

Tom

On Mon, Nov 20, 2017 at 3:25 PM vincent.adrien at gmail.com <
vincent.adrien at gmail.com> wrote:

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