Skip to content

Use custom RNG for sketch path - #5728

Merged
tacaswell merged 6 commits into
matplotlib:masterfrom
mdboom:local-random
Dec 29, 2015
Merged

tacaswell merged 6 commits into
matplotlib:masterfrom
mdboom:local-random

Conversation

@mdboom

@mdboom mdboom commented Dec 23, 2015

Copy link
Copy Markdown
Member

This is an alternative to #5725.

@mdboom mdboom added this to the Critical bugfix release (1.5.1) milestone Dec 23, 2015
@jenshnielsen

Copy link
Copy Markdown
Member

👍 once we can use C++11 I would prefer to use stl random lib but this seems like a suitable solution at the moment

@tacaswell

Copy link
Copy Markdown
Member

looks like xkcd tests are failing (as we changed the random number generator).

@mdboom

mdboom commented Dec 23, 2015

Copy link
Copy Markdown
Member Author

Ah, of course. I'm not going to try to make it backward compatible, and just update the images :) Honestly, it's probably a good thing -- the C stdlib RNG doesn't guarantee any consistency across compilers anyway, but this should.

@jenshnielsen

Copy link
Copy Markdown
Member

The xkcd test have always been failing for me on OSX so that seems likely. Would be great if this fixes that too.

@tacaswell

Copy link
Copy Markdown
Member

👍 to not worrying about back compatibility here. I really really hope no one is relying on the details of the sketch path!

@tacaswell

Copy link
Copy Markdown
Member

appveyor is not failing when it fails, but this is showing up, it used to just fail on pixel errors.

======================================================================
ERROR: matplotlib.tests.test_path.test_xkcd.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python34_64\envs\test-environment\lib\site-packages\nose\case.py", line 198, in runTest
    self.test(*self.arg)
  File "c:\projects\matplotlib\lib\matplotlib\testing\decorators.py", line 54, in failer
    result = f(*args, **kwargs)
  File "c:\projects\matplotlib\lib\matplotlib\testing\decorators.py", line 232, in do_test
    figure.savefig(actual_fname, **self._savefig_kwarg)
  File "c:\projects\matplotlib\lib\matplotlib\figure.py", line 1698, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "c:\projects\matplotlib\lib\matplotlib\backend_bases.py", line 2230, in print_figure
    **kwargs)
  File "c:\projects\matplotlib\lib\matplotlib\backends\backend_agg.py", line 520, in print_png
    FigureCanvasAgg.draw(self)
  File "c:\projects\matplotlib\lib\matplotlib\backends\backend_agg.py", line 467, in draw
    self.figure.draw(self.renderer)
  File "c:\projects\matplotlib\lib\matplotlib\artist.py", line 62, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "c:\projects\matplotlib\lib\matplotlib\figure.py", line 1230, in draw
    self.patch.draw(renderer)
  File "c:\projects\matplotlib\lib\matplotlib\artist.py", line 62, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "c:\projects\matplotlib\lib\matplotlib\patches.py", line 536, in draw
    renderer.draw_path(gc, tpath, affine, rgbFace)
  File "c:\projects\matplotlib\lib\matplotlib\patheffects.py", line 110, in draw_path
    rgbFace)
  File "c:\projects\matplotlib\lib\matplotlib\patheffects.py", line 211, in draw_path
    Stroke.draw_path(self, renderer, gc, tpath, affine, rgbFace)
  File "c:\projects\matplotlib\lib\matplotlib\patheffects.py", line 200, in draw_path
    renderer.draw_path(gc0, tpath, trans, rgbFace)
  File "c:\projects\matplotlib\lib\matplotlib\backends\backend_agg.py", line 166, in draw_path
    self._renderer.draw_path(gc, path, transform, rgbFace)
OverflowError: In draw_path: Exceeded cell block limit

@tacaswell

Copy link
Copy Markdown
Member

ex

FAIL: matplotlib.tests.test_path.test_xkcd.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python34_64\envs\test-environment\lib\site-packages\nose\case.py", line 198, in runTest
    self.test(*self.arg)
  File "c:\projects\matplotlib\lib\matplotlib\testing\decorators.py", line 54, in failer
    result = f(*args, **kwargs)
  File "c:\projects\matplotlib\lib\matplotlib\testing\decorators.py", line 245, in do_test
    '(RMS %(rms).3f)'%err)
matplotlib.testing.exceptions.ImageComparisonFailure: images not close: C:\projects\matplotlib\result_images\test_path\xkcd.png vs. C:\projects\matplotlib\result_images\test_path\xkcd-expected.png (RMS 9.607)

from https://ci.appveyor.com/project/mdboom/matplotlib/build/1.0.338/job/nl9a32g98n9o9rov

Comment thread src/path_converters.h Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is double 32 or 64bits? I wonder if this is what is causing the test failure on windows (in that this is no longer scaled [-1, 1] on all platforms?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

double is 64 bits, so it looks to me like this should yield numbers from 0 to (2^32-1)/2^32. I can imagine the result of the division could differ depending on whether it is done using plain double-precision, or using extra-width floating point registers. Use of denormalized numbers is another option. There are compiler switches that can affect floating point results, so the same code on the same hardware can yield different results depending on the compiler and its options. Maybe this is what is happening here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the 1L needs to be 1LL to ensure it is 64 bits.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be scaled [0, 1) on all platforms, since the seed is an unsigned int. I think @efiring is right here, that it should be 1LL. Let's try that and run it over the Windows tests.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would certainly be consistent with a Linux vs. Windows problem. On a 64-bit machine, 1L is 64-bits on Linux and 32-bits on Windows. 1LL is 64 bits on both.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to spam -- reading further, however, the test failures on Windows are prior to this change, right? That could easily be explained by using the C stdlib RNG which varies entirely from platform to platform. This should (and seemingly does) address that problem by using exactly one RNG implementation everywhere.

tacaswell added a commit that referenced this pull request Dec 29, 2015
Use custom RNG for sketch path
@tacaswell
tacaswell merged commit 1446c69 into matplotlib:master Dec 29, 2015
tacaswell added a commit that referenced this pull request Dec 29, 2015
Use custom RNG for sketch path
Conflicts:
	lib/matplotlib/tests/baseline_images/test_path/xkcd.pdf
	lib/matplotlib/tests/baseline_images/test_path/xkcd.png
	lib/matplotlib/tests/baseline_images/test_path/xkcd.svg

Resolved all by copying binaries from master branch
@tacaswell

Copy link
Copy Markdown
Member

backported as 3be4490

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants