Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use custom RNG for sketch path #5728

Merged
merged 6 commits into from Dec 29, 2015
Merged

Conversation

mdboom
Copy link
Member

@mdboom mdboom commented Dec 23, 2015

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

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

@mdboom
Copy link
Member Author

mdboom commented Dec 23, 2015

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

double get_double()
{
m_seed = (a * m_seed + c);
return (double)m_seed / (double)(1L << 32);
Copy link
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
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
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
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
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
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
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.

None yet

4 participants