From antony.lee at berkeley.edu  Thu Nov  2 13:47:19 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 2 Nov 2017 10:47:19 -0700
Subject: [Matplotlib-devel] feature request
In-Reply-To: <CAPAMuMcUyQVMa60m5F5rMZevS2cKtdxv4PaS+Z6qJNEondo3ew@mail.gmail.com>
References: <CAPAMuMcWgZdfQhgW0F0X1Kv65qbDdY4Xgt5HXA7z7m-XZu7Xpg@mail.gmail.com>
 <82B4C2EE-90F3-4E14-A4AF-7DED20A30DE6@uvic.ca>
 <CAGRr6BH_TKe-OduRoarXwOKpphYYW=UivuEX0sFN7s8oC9-92g@mail.gmail.com>
 <CAPAMuMct-BAuc6w9z6cBvhzCO3P5gjh_OM3VXsM40WR1AGyWdQ@mail.gmail.com>
 <CAPAMuMcUyQVMa60m5F5rMZevS2cKtdxv4PaS+Z6qJNEondo3ew@mail.gmail.com>
Message-ID: <CAGRr6BFm7ugm=UHLubvpy_HugTuaMjS6R8dcm-YuFTiaytWzxw@mail.gmail.com>

Hi,

mplcursors should work just fine with a custom pyqt widget (I often write
pyqt apps as well).

To pin the bottom right text, e.g. the following works:

from matplotlib import pyplot as plt
import mplcursors

fig, ax = plt.subplots()
ax.plot([1, 2])
# By default, keep the status bar text cleared.
fig.canvas.mpl_connect(
    "motion_notify_event",
    lambda event: fig.canvas.toolbar.set_message(""))
# If the cursor matches, update the status bar text.
mplcursors.cursor(hover=True).connect(
    "add",
    lambda sel: fig.canvas.toolbar.set_message(
        sel.annotation.get_text().replace("\n", "  ")))
plt.show()


I will probably add a similar example to the mplcursors doc.

Antony

2017-11-02 5:50 GMT-07:00 Rogier Delporte <rogier.delporte at gmail.com>:

> Hi
>
> I had a quick look at mplcursors and it's very close to what I want. I'm
> not sure I'll be able to use it in combination with a custom pyqt
> matplotlib widget.
>
> I think it would be a very nice feature if this could be integrated right
> into matplotlib in such a way that the cursor readout in the bottom right
> corner snaps(of course it would be made optional) to the nearest data
> point. Unfortunately, I'm too much of a noob to implement this myself, but
> I'd like to request this feature be put on one of the todo-lists.
>
> Thanks for the great library!
>
> Rogier Delporte
>
>
>
> On Sat, Sep 30, 2017 at 8:45 AM, Rogier Delporte <
> rogier.delporte at gmail.com> wrote:
>
>> Thanks, I'll check it out.
>>
>> Op 29 sep. 2017 11:35 p.m. schreef "Antony Lee" <antony.lee at berkeley.edu
>> >:
>>
>> Hi,
>>> You may also want to look at mplcursors's hover mode (
>>> https://mplcursors.readthedocs.io/en/latest/examples/hover.
>>> html#sphx-glr-examples-hover-py).
>>> Antony
>>>
>>> 2017-09-29 14:24 GMT-07:00 Jody Klymak <jklymak at uvic.ca>:
>>>
>>>> Hi Rogier,
>>>>
>>>> You can already do this by writing a format_coord function and setting
>>>> ax.format_coord property of the axis with your data in it.
>>>>
>>>> http://matplotlib.org/examples/api/image_zcoord.html
>>>>
>>>> Cheers, Jody
>>>>
>>>> On 29 Sep 2017, at 6:57, Rogier Delporte wrote:
>>>>
>>>> Dear maintainer(s)
>>>> Dear developpers
>>>>
>>>> I would like to request a new matplotlib feature. The current version of
>>>> matplotlib shows the coordinates of the cursor in the bottom right
>>>> corner.
>>>> It would be great if some option or mode could be added which snaps the
>>>> cursor to data points. This would take some guesswork out of reading a
>>>> plot
>>>> with a lot of points.
>>>>
>>>> I know this feature is similar to the mpldatacursor toolkit, but
>>>> mpldatacursor does not provide a smooth and fast way to pinpoint a data
>>>> point.
>>>>
>>>> I hope someone would like to implement this feature, because I don't
>>>> have
>>>> sufficient programming skills to implement this myself.
>>>>
>>>> Thanks for the awesomeness that is matplotlib!
>>>>
>>>> Rogier
>>>> _______________________________________________
>>>> 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/20171102/044e0649/attachment.html>

From A.G.Grozin at inp.nsk.su  Thu Nov  9 08:47:43 2017
From: A.G.Grozin at inp.nsk.su (Andrey G. Grozin)
Date: Thu, 9 Nov 2017 20:47:43 +0700 (+07)
Subject: [Matplotlib-devel] 2.1.0: trying to build documentation
Message-ID: <alpine.LRH.2.21.1711091953160.34626@star.inp.nsk.su>

Hello *,

running ./make.py in doc/ I got

Traceback (most recent call last):
   File "./make.py", line 200, in <module>
     copy_if_out_of_date('../INSTALL.rst', 'users/installing.rst')
   File "./make.py", line 21, in copy_if_out_of_date
     shutil.copyfile(original, derived)
   File "/usr/lib/python2.7/shutil.py", line 96, in copyfile
     with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '../INSTALL.rst'

Right, there's no ../INSTALL.rst. Removed the line
copy_if_out_of_date('../INSTALL.rst', 'users/installing.rst')
from make.py. Then I got

Exception occurred:
   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/gen_gallery.py", 
line 217, in generate_gallery_rst
     .format(examples_dir))
IOError: Main example directory 
/var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib-2.1.0-python2_7/doc/../tutorials 
does not have a README.txt file. Please write one to introduce your 
gallery.

Right,there's no ../tutorials. make.py effectively calls

python -msphinx . build/html -j1 -bhtml -dbuild/doctrees 
-Dplot_formats=png:100 -W

which produces this error message. Removed all traces of tutorials from 
conf.py. Then I got

Warning, treated as error:
/var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib-2.1.0-python2_7/doc/users/index.rst:12:toctree 
contains reference to nonexisting document u'users/installing'

Right, now there's no installing. Removed it from users/index.rst. Then I 
got some warning treated as an error about some docsttring in matplotlib. 
I don't want to edit matplotlib code, so I removed '-W' from options in 
the function html in make.py. Now building documentation proceeds rather 
far. But at the end I get

copying static files... done
copying extra files... done
dumping search index in English (code: en) ... done
dumping object inventory... done
build succeeded, 63 warnings.
Embedding documentation hyperlinks in examples ...
gallery[  0%] index.html
gallery[  0%] 2dcollections3d.html

Exception occurred:
   File "/usr/lib64/python2.7/anydbm.py", line 85, in open
     return mod.open(file, flag, mode)
error: (11, 'Resource temporarily unavailable')
The full traceback has been saved in 
/var/tmp/portage/dev-python/matplotlib-2.1.0/temp/sphinx-err-KYVDSp.log, 
if you want to report the issue to the developers.

And I don't know what to do next. The log file is:

# Sphinx version: 1.6.3
# Python version: 2.7.14 (CPython)
# Docutils version: 0.14
# Jinja2 version: 2.9.6
# Last messages:
#   copying extra files...
#   done
#   dumping search index in English (code: en) ...
#   done
#   dumping object inventory...
#   done
#   build succeeded, 63 warnings.
#   Embedding documentation hyperlinks in examples ...
#   gallery[  0%] index.html
#   gallery[  0%] 2dcollections3d.html
# Loaded extensions:
#   sphinx.ext.inheritance_diagram (1.6.3) from 
/usr/lib64/python2.7/site-packages/sphinx/ext/inheritance_diagram.pyc
#   matplotlib.sphinxext.mathmpl (unknown version) from 
/var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib-2.1.0-python2_7/build/lib/matplotlib/sphinxext/mathmpl.py
#   matplotlib.sphinxext.only_directives (unknown version) from 
/var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib-2.1.0-python2_7/build/lib/matplotlib/sphinxext/only_directives.py
#   IPython.sphinxext.ipython_console_highlighting (unknown version) from 
/usr/lib64/python2.7/site-packages/IPython/sphinxext/ipython_console_highlighting.pyc
#   sphinx_gallery.gen_gallery (unknown version) from 
/usr/lib64/python2.7/site-packages/sphinx_gallery/gen_gallery.pyc
#   sphinx.ext.autodoc (1.6.3) from 
/usr/lib64/python2.7/site-packages/sphinx/ext/autodoc.pyc
#   sphinx.ext.intersphinx (1.6.3) from 
/usr/lib64/python2.7/site-packages/sphinx/ext/intersphinx.pyc
#   sphinx.ext.doctest (1.6.3) from 
/usr/lib64/python2.7/site-packages/sphinx/ext/doctest.pyc
#   matplotlib.sphinxext.plot_directive (unknown version) from 
/var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib-2.1.0-python2_7/build/lib/matplotlib/sphinxext/plot_directive.py
#   alabaster (0.7.10) from 
/usr/lib64/python2.7/site-packages/alabaster/__init__.pyc
#   IPython.sphinxext.ipython_directive (unknown version) from 
/usr/lib64/python2.7/site-packages/IPython/sphinxext/ipython_directive.pyc
#   sphinxext.math_symbol_table (unknown version) from 
sphinxext/math_symbol_table.py
#   sphinxext.github (unknown version) from sphinxext/github.py
#   sphinx.ext.graphviz (1.6.3) from 
/usr/lib64/python2.7/site-packages/sphinx/ext/graphviz.pyc
#   numpydoc (unknown version) from 
/usr/lib64/python2.7/site-packages/numpydoc/__init__.pyc
#   sphinx.ext.autosummary (1.6.3) from 
/usr/lib64/python2.7/site-packages/sphinx/ext/autosummary/__init__.pyc
Traceback (most recent call last):
   File "/usr/lib64/python2.7/site-packages/sphinx/cmdline.py", line 306, 
in main
     app.build(opts.force_all, filenames)
   File "/usr/lib64/python2.7/site-packages/sphinx/application.py", line 
357, in build
     self.emit('build-finished', None)
   File "/usr/lib64/python2.7/site-packages/sphinx/application.py", line 
489, in emit
     return self.events.emit(event, self, *args)
   File "/usr/lib64/python2.7/site-packages/sphinx/events.py", line 79, in 
emit
     results.append(callback(*args))
   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py", 
line 455, in embed_code_links
     _embed_code_links(app, gallery_conf, gallery_dir)
   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py", 
line 388, in _embed_code_links
     full_fname)
   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py", 
line 306, in resolve
     link = self._get_link(cobj)
   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py", 
line 258, in _get_link
     html = get_data(link, self.gallery_dir)
   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py", 
line 67, in get_data
     search_index = shelve.open(cached_file)
   File "/usr/lib64/python2.7/shelve.py", line 243, in open
     return DbfilenameShelf(filename, flag, protocol, writeback)
   File "/usr/lib64/python2.7/shelve.py", line 227, in __init__
     Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
   File "/usr/lib64/python2.7/anydbm.py", line 85, in open
     return mod.open(file, flag, mode)
error: (11, 'Resource temporarily unavailable')

Any ideas how to proceed?

Does anybody check documentation generation before releases?

Andrey

From antony.lee at berkeley.edu  Thu Nov  9 14:26:28 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 9 Nov 2017 11:26:28 -0800
Subject: [Matplotlib-devel] 2.1.0: trying to build documentation
In-Reply-To: <alpine.LRH.2.21.1711091953160.34626@star.inp.nsk.su>
References: <alpine.LRH.2.21.1711091953160.34626@star.inp.nsk.su>
Message-ID: <CAGRr6BGc1WvcSuxF1j9dXX+bOad_EU5NPkwgiKmxHdz4rT5KJQ@mail.gmail.com>

Hi,
Indeed the source distribution on PyPI is broken.  I have added the issue
to the tracker: https://github.com/matplotlib/matplotlib/issues/9735
In the mean time, your best option is probably to build the docs from a git
checkout (from https://github.com/matplotlib/matplotlib).
Antony

2017-11-09 5:47 GMT-08:00 Andrey G. Grozin <A.G.Grozin at inp.nsk.su>:

> Hello *,
>
> running ./make.py in doc/ I got
>
> Traceback (most recent call last):
>   File "./make.py", line 200, in <module>
>     copy_if_out_of_date('../INSTALL.rst', 'users/installing.rst')
>   File "./make.py", line 21, in copy_if_out_of_date
>     shutil.copyfile(original, derived)
>   File "/usr/lib/python2.7/shutil.py", line 96, in copyfile
>     with open(src, 'rb') as fsrc:
> IOError: [Errno 2] No such file or directory: '../INSTALL.rst'
>
> Right, there's no ../INSTALL.rst. Removed the line
> copy_if_out_of_date('../INSTALL.rst', 'users/installing.rst')
> from make.py. Then I got
>
> Exception occurred:
>   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/gen_gallery.py",
> line 217, in generate_gallery_rst
>     .format(examples_dir))
> IOError: Main example directory /var/tmp/portage/dev-python/ma
> tplotlib-2.1.0/work/matplotlib-2.1.0-python2_7/doc/../tutorials does not
> have a README.txt file. Please write one to introduce your gallery.
>
> Right,there's no ../tutorials. make.py effectively calls
>
> python -msphinx . build/html -j1 -bhtml -dbuild/doctrees
> -Dplot_formats=png:100 -W
>
> which produces this error message. Removed all traces of tutorials from
> conf.py. Then I got
>
> Warning, treated as error:
> /var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib
> -2.1.0-python2_7/doc/users/index.rst:12:toctree contains reference to
> nonexisting document u'users/installing'
>
> Right, now there's no installing. Removed it from users/index.rst. Then I
> got some warning treated as an error about some docsttring in matplotlib. I
> don't want to edit matplotlib code, so I removed '-W' from options in the
> function html in make.py. Now building documentation proceeds rather far.
> But at the end I get
>
> copying static files... done
> copying extra files... done
> dumping search index in English (code: en) ... done
> dumping object inventory... done
> build succeeded, 63 warnings.
> Embedding documentation hyperlinks in examples ...
> gallery[  0%] index.html
> gallery[  0%] 2dcollections3d.html
>
> Exception occurred:
>   File "/usr/lib64/python2.7/anydbm.py", line 85, in open
>     return mod.open(file, flag, mode)
> error: (11, 'Resource temporarily unavailable')
> The full traceback has been saved in /var/tmp/portage/dev-python/ma
> tplotlib-2.1.0/temp/sphinx-err-KYVDSp.log, if you want to report the
> issue to the developers.
>
> And I don't know what to do next. The log file is:
>
> # Sphinx version: 1.6.3
> # Python version: 2.7.14 (CPython)
> # Docutils version: 0.14
> # Jinja2 version: 2.9.6
> # Last messages:
> #   copying extra files...
> #   done
> #   dumping search index in English (code: en) ...
> #   done
> #   dumping object inventory...
> #   done
> #   build succeeded, 63 warnings.
> #   Embedding documentation hyperlinks in examples ...
> #   gallery[  0%] index.html
> #   gallery[  0%] 2dcollections3d.html
> # Loaded extensions:
> #   sphinx.ext.inheritance_diagram (1.6.3) from
> /usr/lib64/python2.7/site-packages/sphinx/ext/inheritance_diagram.pyc
> #   matplotlib.sphinxext.mathmpl (unknown version) from
> /var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib
> -2.1.0-python2_7/build/lib/matplotlib/sphinxext/mathmpl.py
> #   matplotlib.sphinxext.only_directives (unknown version) from
> /var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib
> -2.1.0-python2_7/build/lib/matplotlib/sphinxext/only_directives.py
> #   IPython.sphinxext.ipython_console_highlighting (unknown version) from
> /usr/lib64/python2.7/site-packages/IPython/sphinxext/ipython
> _console_highlighting.pyc
> #   sphinx_gallery.gen_gallery (unknown version) from
> /usr/lib64/python2.7/site-packages/sphinx_gallery/gen_gallery.pyc
> #   sphinx.ext.autodoc (1.6.3) from /usr/lib64/python2.7/site-pack
> ages/sphinx/ext/autodoc.pyc
> #   sphinx.ext.intersphinx (1.6.3) from /usr/lib64/python2.7/site-pack
> ages/sphinx/ext/intersphinx.pyc
> #   sphinx.ext.doctest (1.6.3) from /usr/lib64/python2.7/site-pack
> ages/sphinx/ext/doctest.pyc
> #   matplotlib.sphinxext.plot_directive (unknown version) from
> /var/tmp/portage/dev-python/matplotlib-2.1.0/work/matplotlib
> -2.1.0-python2_7/build/lib/matplotlib/sphinxext/plot_directive.py
> #   alabaster (0.7.10) from /usr/lib64/python2.7/site-pack
> ages/alabaster/__init__.pyc
> #   IPython.sphinxext.ipython_directive (unknown version) from
> /usr/lib64/python2.7/site-packages/IPython/sphinxext/ipython_directive.pyc
> #   sphinxext.math_symbol_table (unknown version) from
> sphinxext/math_symbol_table.py
> #   sphinxext.github (unknown version) from sphinxext/github.py
> #   sphinx.ext.graphviz (1.6.3) from /usr/lib64/python2.7/site-pack
> ages/sphinx/ext/graphviz.pyc
> #   numpydoc (unknown version) from /usr/lib64/python2.7/site-pack
> ages/numpydoc/__init__.pyc
> #   sphinx.ext.autosummary (1.6.3) from /usr/lib64/python2.7/site-pack
> ages/sphinx/ext/autosummary/__init__.pyc
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/site-packages/sphinx/cmdline.py", line 306,
> in main
>     app.build(opts.force_all, filenames)
>   File "/usr/lib64/python2.7/site-packages/sphinx/application.py", line
> 357, in build
>     self.emit('build-finished', None)
>   File "/usr/lib64/python2.7/site-packages/sphinx/application.py", line
> 489, in emit
>     return self.events.emit(event, self, *args)
>   File "/usr/lib64/python2.7/site-packages/sphinx/events.py", line 79, in
> emit
>     results.append(callback(*args))
>   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py",
> line 455, in embed_code_links
>     _embed_code_links(app, gallery_conf, gallery_dir)
>   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py",
> line 388, in _embed_code_links
>     full_fname)
>   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py",
> line 306, in resolve
>     link = self._get_link(cobj)
>   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py",
> line 258, in _get_link
>     html = get_data(link, self.gallery_dir)
>   File "/usr/lib64/python2.7/site-packages/sphinx_gallery/docs_resolv.py",
> line 67, in get_data
>     search_index = shelve.open(cached_file)
>   File "/usr/lib64/python2.7/shelve.py", line 243, in open
>     return DbfilenameShelf(filename, flag, protocol, writeback)
>   File "/usr/lib64/python2.7/shelve.py", line 227, in __init__
>     Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
>   File "/usr/lib64/python2.7/anydbm.py", line 85, in open
>     return mod.open(file, flag, mode)
> error: (11, 'Resource temporarily unavailable')
>
> Any ideas how to proceed?
>
> Does anybody check documentation generation before releases?
>
> Andrey
> _______________________________________________
> 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/20171109/8f9146f7/attachment.html>

From tcaswell at gmail.com  Sun Nov 12 21:45:32 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 13 Nov 2017 02:45:32 +0000
Subject: [Matplotlib-devel] Weekly call re-scheduled
Message-ID: <CAA48SF-sFwwDNHy9uvdbNdqyxVcYRyWBBMg2Ej0rZ9795HEPSA@mail.gmail.com>

Folks,

We are going move the weekly call up an hour to 1400 Eastern.

If anyone is interested in joining me know and I'll send you an gchat
invitation.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20171113/d3da35ab/attachment.html>

From tcaswell at gmail.com  Mon Nov 20 15:06:36 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 20 Nov 2017 20:06:36 +0000
Subject: [Matplotlib-devel] 2017-11-20 notes
Message-ID: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20171120/4e61b48a/attachment.html>

From vincent.adrien at gmail.com  Mon Nov 20 15:25:13 2017
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Mon, 20 Nov 2017 12:25:13 -0800
Subject: [Matplotlib-devel] 2017-11-20 notes
In-Reply-To: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
References: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
Message-ID: <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@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
> 


From tcaswell at gmail.com  Mon Nov 20 15:42:39 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 20 Nov 2017 20:42:39 +0000
Subject: [Matplotlib-devel] 2017-11-20 notes
In-Reply-To: <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@gmail.com>
References: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
 <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@gmail.com>
Message-ID: <CAA48SF-WfXfk6f_-FtgBDPTmvKcoiu+o1y9NZ4jzyPUGQTCJTg@mail.gmail.com>

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>

From vincent.adrien at gmail.com  Mon Nov 20 15:47:01 2017
From: vincent.adrien at gmail.com (vincent.adrien at gmail.com)
Date: Mon, 20 Nov 2017 12:47:01 -0800
Subject: [Matplotlib-devel] 2017-11-20 notes
In-Reply-To: <CAA48SF-WfXfk6f_-FtgBDPTmvKcoiu+o1y9NZ4jzyPUGQTCJTg@mail.gmail.com>
References: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
 <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@gmail.com>
 <CAA48SF-WfXfk6f_-FtgBDPTmvKcoiu+o1y9NZ4jzyPUGQTCJTg@mail.gmail.com>
Message-ID: <0d4ca5af-4f29-a6a9-060c-fe4345a046de@gmail.com>

Thanks Tom for clarifying this.

Fair enough :).

Adrien

On 11/20/2017 12:42 PM, Thomas Caswell wrote:
> 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 
> <mailto:vincent.adrien at gmail.com> <vincent.adrien at gmail.com 
> <mailto: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 <mailto:Matplotlib-devel at python.org>
>      > https://mail.python.org/mailman/listinfo/matplotlib-devel
>      >
> 
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
> 


From jklymak at uvic.ca  Mon Nov 20 16:58:28 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Mon, 20 Nov 2017 13:58:28 -0800
Subject: [Matplotlib-devel] 2017-11-20 notes
In-Reply-To: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
References: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
Message-ID: <B7427332-479D-4CEE-A9C6-FB2A08A94723@uvic.ca>

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])
> 
> #+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.

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:

```python
 def test_single_date():
        time1 = [721964.0]
        data1 = [-65.54]
    
        fig = plt.figure()
        plt.subplot(211)
        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')
> 
> #+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.  

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    
http://web.uvic.ca/~jklymak/





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

From efiring at hawaii.edu  Mon Nov 27 14:58:48 2017
From: efiring at hawaii.edu (Eric Firing)
Date: Mon, 27 Nov 2017 09:58:48 -1000
Subject: [Matplotlib-devel] Strategy for 2.1.1 and 2.2
Message-ID: <6ffbce23-285a-f75b-80f5-3f3e3779dfce@hawaii.edu>

All,

There are outstanding bugs related to categoricals and to images, but 
fixes are not trivial and may involve code and behavior changes that go 
beyond what is ideal for a bug-fix release.  Therefore I recommend that 
we release 2.1.1 based on what we have now, and try to get a 2.2 out 
soon after.

Eric

From ben.v.root at gmail.com  Mon Nov 27 17:38:16 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Mon, 27 Nov 2017 17:38:16 -0500
Subject: [Matplotlib-devel] Strategy for 2.1.1 and 2.2
In-Reply-To: <6ffbce23-285a-f75b-80f5-3f3e3779dfce@hawaii.edu>
References: <6ffbce23-285a-f75b-80f5-3f3e3779dfce@hawaii.edu>
Message-ID: <CANNq6FmvpFAkg0nsGwDfo_uSANcdLfuWGHtx1C-TiNDt56nkNw@mail.gmail.com>

Perhaps put in warnings for those bad situations for v2.1.1 so that users
know that they might be doing something ambiguous and the behavior may
change?

On Mon, Nov 27, 2017 at 2:58 PM, Eric Firing <efiring at hawaii.edu> wrote:

> All,
>
> There are outstanding bugs related to categoricals and to images, but
> fixes are not trivial and may involve code and behavior changes that go
> beyond what is ideal for a bug-fix release.  Therefore I recommend that we
> release 2.1.1 based on what we have now, and try to get a 2.2 out soon
> after.
>
> Eric
> _______________________________________________
> 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/20171127/f1eb1211/attachment.html>

From antony.lee at berkeley.edu  Mon Nov 27 22:02:09 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Mon, 27 Nov 2017 19:02:09 -0800
Subject: [Matplotlib-devel] 2017-11-20 notes
In-Reply-To: <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@gmail.com>
References: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
 <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@gmail.com>
Message-ID: <CAGRr6BHM83KcQU+xsTB-MzTvDX2ae10MtB6gGZAgcrx3BqpAGQ@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20171127/6ac5f44e/attachment-0001.html>

From rmay31 at gmail.com  Tue Nov 28 06:16:12 2017
From: rmay31 at gmail.com (Ryan May)
Date: Tue, 28 Nov 2017 11:16:12 +0000
Subject: [Matplotlib-devel] 2017-11-20 notes
In-Reply-To: <CAGRr6BHM83KcQU+xsTB-MzTvDX2ae10MtB6gGZAgcrx3BqpAGQ@mail.gmail.com>
References: <CAA48SF_W-anvELt=i3306ftZiRBxAPaBXWZdtTvSfMRho+FT6w@mail.gmail.com>
 <ab4e1722-82d6-6c45-a989-bb89e0b7bd32@gmail.com>
 <CAGRr6BHM83KcQU+xsTB-MzTvDX2ae10MtB6gGZAgcrx3BqpAGQ@mail.gmail.com>
Message-ID: <CAKH0P+Vnz7FBJ3cV_nP=ygFQqRTSvVSxOu-8K41PCTSG6tF-9Q@mail.gmail.com>

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>

From abdaoui.brahim at hotmail.fr  Thu Nov 30 11:06:19 2017
From: abdaoui.brahim at hotmail.fr (A.Brahim)
Date: Thu, 30 Nov 2017 09:06:19 -0700 (MST)
Subject: [Matplotlib-devel] Getting MultiCursor Subplots values (coordinates)
Message-ID: <1512057979130-0.post@n5.nabble.com>

I'm using this code to generate subplots with multiCursor crossing plots, and
I want to get values (cursor coordinates) for all existing plots at the same
time to show them in labels (on mouse motion).


import numpy as np
import matplotlib.pyplot as plt
from matplotlib.widgets import MultiCursor

t = np.arange(0.0, 2.0, 0.01)
s1 = np.sin(2*np.pi*t)
s2 = np.sin(4*np.pi*t)
fig = plt.figure()
ax1 = fig.add_subplot(211)
ax1.plot(t, s1)


ax2 = fig.add_subplot(212, sharex=ax1)
ax2.plot(t, s2)

multi = MultiCursor(fig.canvas, (ax1, ax2), color='r', lw=1)
plt.show()



<http://matplotlib.1069221.n5.nabble.com/file/t5115/U16Dl.png> 



--
Sent from: http://matplotlib.1069221.n5.nabble.com/matplotlib-devel-f28077.html