[Matplotlib-devel] 2017-11-20 notes

Jody Klymak jklymak at uvic.ca
Mon Nov 20 16:58:28 EST 2017

First, thanks so much for the careful notes and the useful examples!

> *** 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])
> 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.

I don’t think there are *many* places in the unit framework where plain numbers are assumed to be OK to pass through.  

https://github.com/matplotlib/matplotlib/pull/9776 <https://github.com/matplotlib/matplotlib/pull/9776>
locks out changing converters, even if the first converter is for floats (I defined a DefaultConverter for numbers).  So you can’t plot a date object on a float axis, or vice versa.  

It only fails 14 tests where the test tried to pass a hard-coded already-converted value to the axis.  i.e. in some `dates` tests and some `jpl` tests:

 def test_single_date():
        time1 = [721964.0]
        data1 = [-65.54]
        fig = plt.figure()
        plt.plot_date(time1, data1, 'o', color='r’)

But it otherwise passes everything.  I’d need to look at the JPL tests more carefully, but the date tests could easily be rewritten to actually pass date objects if thats the way we want to go.  

The point is that being able to pass plain numbers after the converter is set is *not* widely *needed*.  The only place I had to change the code was `cla` where the x/y-limits are reset to (0,1) which we didn’t want triggering the converter lock.    However, I can appreciate the argument that it may be *desired* to pass floats.

> 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')
> 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.  

An alternative to locking the converter is just letting the first real call to the axis *set* the converter, and then let the converter to decide if it will deal with arbitrary values.  i.e. the first call above would set the converter to “CategoricalConverter” and the second call would be sent to CategoricalConverter.  Of course calling in the opposite order would send to the DefaultConverter, and it would TypeError on the second call.  

If we went this route, then the DateConverter could allow plain floats and those would be treated as converted datenums. 

Cheers,   Jody  

> *** 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

Jody Klymak    

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

More information about the Matplotlib-devel mailing list