TST: unit tests fail after MPL 1.4 update

bryan@laptop (git:master) ~/work/bokeh/bokeh/mplexporter $ conda list matplotlib
# packages in environment at /Users/bryan/anaconda:
#
matplotlib                1.4.0                np18py27_0

bryan@laptop (git:master) ~/work/bokeh/bokeh/mplexporter $ nosetests 
..E.....F..
======================================================================
ERROR: bokeh.mplexporter.tests.test_basic.test_path_collection
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bryan/anaconda/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/tests/test_basic.py", line 75, in test_path_collection
    _assert_output_equal(fake_renderer_output(fig, FakeRenderer),
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/tests/test_basic.py", line 15, in fake_renderer_output
    exporter.run(fig)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/exporter.py", line 49, in run
    self.crawl_fig(fig)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/exporter.py", line 116, in crawl_fig
    self.crawl_ax(ax)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/exporter.py", line 138, in crawl_ax
    self.draw_collection(ax, collection)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/exporter.py", line 267, in draw_collection
    mplobj=collection)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/renderers/base.py", line 255, in draw_path_collection
    offsets, styles):
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/renderers/base.py", line 192, in _iter_path_collection
    if not path_transforms:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

======================================================================
FAIL: bokeh.mplexporter.tests.test_basic.test_legend_dots
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bryan/anaconda/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/tests/test_basic.py", line 201, in test_legend_dots
    """)
  File "/Users/bryan/work/bokeh/bokeh/mplexporter/tests/test_basic.py", line 21, in _assert_output_equal
    assert line1 == line2
AssertionError

----------------------------------------------------------------------
Ran 11 tests in 1.233s

FAILED (errors=1, failures=1)

Thanks. I'll try to look into this...

It's the problem with using matplotlib for stuff it was not designed to do. Any new release will likely cause these kinds of issues, as we use private/undocumented parts of the API.

Do you know if there has been any movement on a native JSON importer/exporter?

@mdboom

I haven't heard anything since our chat at SciPy. Probably @mdboom would know the status of that...

@tacaswell

@tacaswell?

On Tuesday, August 26, 2014, Jake Vanderplas [email protected]
wrote:

I haven't heard anything since our chat at SciPy. Probably @mdboom
https://github.com/mdboom would know the status of that...

—
Reply to this email directly or view it on GitHub
#29 (comment).

@theengineear

Most of the available mpl dev bandwidth has been going to getting 1.4.0 out the door.

@theengineear wrote up a MEP and I have a very rough draft of a Controller class that I will probably throw up some time this week.

https://github.com/tacaswell/matplotlib/tree/data_view is the relevant branch, but this is at the stage of 'I hacked at this on an airplane for an hour'. The code is non-functional, but I think the class-level doc string is the useful thing here.

Thanks for the update! Pretty hammered here as well, but let me know if I can help with anything.

@theengineear

As I told @theengineear in an email, where I think we need to start is a list of semantic plot types, the kind of data they take, and the kind of styling they know about.

Both Bokeh and plotly (and d3?) have these things already (I think?) but we need to bring those sets in to agreement. Given that mpl has not much in this regard, the other two should be sorted out before mpl also starts inventing a third (http://xkcd.com/927/).

We also need to come up with a better way to collaborate on this. Editing the gh wikis does not work super well and launching into a design activity in a bug report thread is probably not a great idea either.

d3 doesn't have anything like this. The state of the art in this space is vega, which is a high-level JSON grammar for representing plots, and a script which interprets these in D3. When I wrote mpld3, I initially considered Vega's grammar, but it's so high-level that many matplotlib features could not be represented. I ended up creating an ad-hoc JSON specification that largely mirrors the SVG specification, as that's what matplotlib uses internally.

You might ask why I didn't just use matplotlib's SVG output directly: the problem is that matplotlib's output converts everything to screen coordinates, so there's no way to determine what the input data was and how it interacts with the axes.

To do this JSON serialization well, we'll need something in the middle: lower-level than Vega, and higher-level than screen-coordinate SVG. Bokeh or plotly might provide this, but my suspicion is that Bokeh's grammar was designed for Bokeh, and plotly's grammar was designed for plotly, and you'll find corner cases where they don't work as-is with matplotlib. If you can find one uber-grammar that works for everyone's needs, then more power to you. I personally doubt that it exists, though.

This is why I chose the approach used in mplexporter: it doesn't specify a grammar, it just specifies a class interface where each plot element calls a method which can be overloaded to output any grammar you choose (much like matplotlib's backend framework, except it actually maintains the relationship between plots & their data). That way, with a bit of work, the same code architecture can be used to output any current or future specification. The problem is that by neccessity, it's all based on undocumented & private APIs in matplotlib, and so will likely break every time there's a new release.

All that said, I don't think we should worry right now about defining a visualization grammar that will cover all use-cases now and in the future. Just give people reasonable and stable access to the plot elements, data, and styles within a figure, and let them implement their own specifications.

🚢 (that is a pirate ship as we hijack this bug report)

I think we are talking past each other a bit, I don't think I am looking far an uber-grammar, I am looking for a list of those classes that can output themselves to arbitrary grammars.

I am not sure that we want to shoe-horn

line plots (2 lists of data, maker style {shape, edge_color, face_color, edged_width, size, mark_every}, line style {color, dashing, line_width})
scatter plots (min 2, max 5 (x, y, size, face_color, edge_color) lists of data, color_map, normalization {function, min, max}, marker_style {...}) in to the same interface
histogram which has a good deal of processing involved
imshow where the spatial location of the data is encoded in the data structures.

all into the same interface.

I could also be way off in left field here and what I am describing is a grammar.

Disagreeing with my self above, is what we want to have a base class for the Controllers which has a visitor pattern and takes a function with the signature:

def out_put_visitor_function(semantic_label, raw_data, displayed_data, process_info, style, raw_artists):
    """
    semantic_label : str
        What mpl thinks this type of graph element is.  This might just be the name of
        the controller class
    raw_data : dict
        dict keyed on something sensible with the raw data passed in by the user, 
        can be empty if no processing is done
    displayed_data : dict
        The data that is used to draw to the screen.
        In the case of a historgram this would be the bin heights and edges, for
        contours this is the lines.  For 2D lines this would be the x, y values
    process_info : dict
        keyed on sensible strings, information about / parameters for turning raw data into
        the processed data
   style : dict
       keyed on strings naming what is being styled. 
    raw_artists : dict
        keyed on sensible strings, access to the artists managed by the Contoller
    """
    pass

And something similar for axes (to specify the non-plotting mark up (like axvline, ...), ticks, limits, title, axis labels, and such) and figures which manage the recursion.

Yeah! Happening. I'm going to move this pirate ship to here: matplotlib/matplotlib#3424

I think if we can sort out a solid list of specs that we need to meet for everyone's needs and document that in the wiki, then we'll have a solid place to start from.

Three tests are failing on mpl 1.5.0rc1:

test_path_collection -- resolved, PR forthcoming
test_image -- new size of rendered image is 1220, was formerly 1240
test_legend_dots -- path has 4 vertices; 5 are expected, see below

Actual:
opening figure
opening axes
draw line with 3 points
draw 3 markers
opening legend
draw text 'None' None
draw line with 2 points
draw text 'label' None
draw 2 markers
draw text 'dots' None
draw path with 4 vertices
closing legend
losing axes
closing figure

Expected:
opening figure
opening axes
draw line with 3 points
draw 3 markers
opening legend
draw line with 2 points
draw text 'label' None
draw 2 markers
draw text 'dots' None
draw path with 5 vertices
closing legend
closing axes
closing figure

mpl fixed a bug where we were not emitting close-path codes on some paths
and instead were just moving back to where the path started which gets the
join at the start/end point wrong.

On Fri, Oct 9, 2015 at 10:41 AM Dan Allan [email protected] wrote:

Three tests are failing on mpl 1.5.0rc1:

test_path_collection -- resolved, PR forthcoming

test_image -- new size of rendered image is 1220, was formerly 1240

test_legend_dots -- path has 4 vertices; 5 are expected, see below

Actual:
opening figure
opening axes
draw line with 3 points
draw 3 markers
opening legend
draw text 'None' None
draw line with 2 points
draw text 'label' None
draw 2 markers
draw text 'dots' None
draw path with 4 vertices
closing legend
losing axes
closing figure

Expected:
opening figure
opening axes
draw line with 3 points
draw 3 markers
opening legend
draw line with 2 points
draw text 'label' None
draw 2 markers
draw text 'dots' None
draw path with 5 vertices
closing legend
closing axes
closing figure

—
Reply to this email directly or view it on GitHub
#29 (comment).

@jakevdp

@jakevdp That leaves one test left that we don't understand: the slight change in the image size. I suggest we release mpld3 and let this be a known issue. I think our goal is to keep mpld3 alive/relevant on a modern stack until matplotlib traitlets is ready, at which time most or all of this code will be moot.

bump

Sounds good

Fix legend dots test

Navigation Menu

Repository navigation

TST: unit tests fail after MPL 1.4 update #29

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TST: unit tests fail after MPL 1.4 update #29

Description

Activity

jakevdp commented on Aug 26, 2014

bryevdv commented on Aug 27, 2014

jakevdp commented on Aug 27, 2014

danielballan commented on Aug 27, 2014

tacaswell commented on Aug 27, 2014

tacaswell commented on Aug 27, 2014

bryevdv commented on Aug 27, 2014

tacaswell commented on Aug 27, 2014

jakevdp commented on Aug 27, 2014

tacaswell commented on Aug 27, 2014

theengineear commented on Aug 27, 2014

danielballan commented on Oct 9, 2015

tacaswell commented on Oct 9, 2015

danielballan commented on Oct 12, 2015

danielballan commented on Oct 26, 2015

jakevdp commented on Oct 27, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions