[Matplotlib-devel] 2017-11-20 notes

Tue Nov 28 06:16:12 EST 2017

Doing #2 properly requires passing depth information fully down into the
rasterizer (e.g. Agg), and having it compute z for each pixel (fragment).
That’s a ton of work, and GPUs already do this.

Ryan

On Tue, Nov 28, 2017 at 3:02 AM Antony Lee <antony.lee at berkeley.edu> wrote:

> A bit late to the party, but here are some (not very deep) thoughts
> regarding 3D support.
>
> 1. I believe that writing a new 3D projection class from scratch, properly
> integrated with the transforms system (so with support for log-scale,
> etc.), should be a "relatively easy" (if somewhat tedious and lengthy...)
> task, for someone who knows Matplotlib's internals well (probably easier
> than trying to forcefully modernize mplot3d).  All the machinery is already
> there.  Given the way projections work, this can be started as a
> third-party project (requiring explicit registration by import, just like
> mplot3d does now) and later be integrated into matplotlib's core.
>
> 2. More difficult to resolve is z-buffering (i.e., support for overlapping
> polygons that cannot be sorted unambiguously using a single z-value).  As
> far as I can tell, this would require adding a new method on the renderer
> classes (because there is simply no way to pass z-information to the
> renderer right now -- z-sorting occurs before data reaches the renderer),
> and, well, implementing it.
>
> Antony
>
>
> 2017-11-20 12:25 GMT-08:00 vincent.adrien at gmail.com <
> vincent.adrien at gmail.com>:
>
>> 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
>>
>
> _______________________________________________
> 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/20171128/62de6d71/attachment.html>