Use custom RNG for sketch path

[mdboom]

This is an alternative to #5725.

[jenshnielsen]

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

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

[mdboom]

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]

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

[tacaswell]

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

[tacaswell]

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]

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

[tacaswell]

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?

[efiring]

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?

[efiring]

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

[mdboom]

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.

[mdboom]

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.

[mdboom]

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]

backported as 3be4490