[SciPy-Dev] update on 0.11.0 status

Tue Jul 10 17:33:41 EDT 2012

Ralf,
I tried running valgrind on the offending code.  I don't see anything 
out of the ordinary come up on my system (for reference, the 
scikit-learn developer documentation has some tips on using valgrind for 
cython code [1]).  This makes me suspect that the error you're seeing 
may be a system-specific issue (i.e. 32 bit/64 bit mismatch), or perhaps 
something related to the numpy version (I'm using the current numpy 
1.8.0-dev).

Could you run valgrind on your system with test_shortest_path.py and see 
if anything obvious comes up?  Thanks
    Jake

[1] http://scikit-learn.org/stable/developers/debugging.html

On 07/10/2012 02:00 PM, Ralf Gommers wrote:
>
>
> On Tue, Jul 10, 2012 at 10:52 PM, Jake Vanderplas 
> <vanderplas at astro.washington.edu 
> <mailto:vanderplas at astro.washington.edu>> wrote:
>
>     On 07/10/2012 01:34 PM, Ralf Gommers wrote:
>>
>>
>>     On Tue, Jul 10, 2012 at 6:25 PM, Jake Vanderplas
>>     <vanderplas at astro.washington.edu
>>     <mailto:vanderplas at astro.washington.edu>> wrote:
>>
>>         Hi,
>>         The graph_laplacian issue is fixed in PR 266, which I just
>>         opened [1].  There is still the related but larger issue of
>>         errant fancy indexing in LIL matrix, discussed in ticket 1681
>>         [2].  The LIL issue is more complicated, as it has potential
>>         for breaking backward compatibility.
>>
>>     Great. If that is fixed, I'm not sure if the LIL issue is still a
>>     blocker.
>>
>>         I have still been unable to reproduce the
>>         csgraph.shortest_path failure.
>>
>>
>>     I can reproduce this for about 1 in 10 runs, which is really
>>     weird because I can't find any randomness in the test or code.
>>     Plus, it once again shows how annoying generator tests are; can't
>>     see which method is failing. Failures are also not always the same:
>>
>>     <failure 1>
>>     x and y nan location mismatch:
>>      x: array([[  0.,  nan,   3.,   2.,   4.],
>>            [ nan,  nan,  nan,  nan,  nan],
>>            [  1.,  nan,   0.,   3.,   5.],
>>            [  1.,  nan,   4.,   0.,   3.]])
>>      y: array([[ 0.,  3.,  3.,  1.,  2.],
>>            [ 3.,  0.,  6.,  2.,  4.],
>>            [ 3.,  6.,  0.,  4.,  5.],
>>            [ 1.,  2.,  4.,  0.,  2.]])
>>
>>
>>     <failure 2>
>>     (mismatch 30.0%)
>>      x: array([[ 0.,  3.,  3.,  2.,  4.],
>>            [ 3.,  0.,  6.,  2.,  4.],
>>            [ 3.,  6.,  0.,  5.,  7.],
>>            [ 1.,  1.,  4.,  0.,  3.]])
>>      y: array([[ 0.,  3.,  3.,  1.,  2.],
>>            [ 3.,  0.,  6.,  2.,  4.],
>>            [ 3.,  6.,  0.,  4.,  5.],
>>            [ 1.,  2.,  4.,  0.,  2.]])
>>
>>
>>     Any idea where to look?
>
>     I just ran the test_shortest_path.py code a few dozen times, and
>     didn't have any failures.  Both these cases above seem to be from
>     the `test_shortest_path_indices()` function, for indshape=(4,). 
>     Is that the only test you get errors from? Is the y array the same
>     in each failure?
>
>
> Seems to be the same each time.
>
> Ralf
>
>
>     The fact that it's not happening every time for you makes it sound
>     like a memory issue.  If that's the case, I suspect some variable
>     is uninitialized in the Fibonacci heap code, as that's the only
>     part of the code that uses raw pointers.
>
>     I'll try running valgrind to see if I can find the culprit.
>        Jake
>
>
>>
>>     Ralf
>>
>>
>>            Jake
>>
>>         [1] https://github.com/scipy/scipy/pull/266
>>         [2] http://projects.scipy.org/scipy/ticket/1681
>>
>>
>>         On 07/10/2012 07:13 AM, Ralf Gommers wrote:
>>>         Hi all,
>>>
>>>         Here's a short update on the status of the 0.11.0 release.
>>>         Some of the reported issues for the beta release have been
>>>         fixed or PRs for them are waiting to be merged. There is one
>>>         failure not yet fixed (sparse.csgrapg.shortest_path failure)
>>>         and one blocker also in the sparse.csgraph module:
>>>         http://projects.scipy.org/scipy/ticket/1681. Once the
>>>         csgraph issues are fixed we're ready to release the first RC.
>>>
>>>         To be merged and backported:
>>>         Umfpack failure: https://github.com/scipy/scipy/pull/257
>>>         Interpolate failure under Python 3.x:
>>>         https://github.com/scipy/scipy/pull/258
>>>
>>>         To not fix: weave error when running the tests under Python
>>>         3.x. It's not easy to avoid the printed error, because
>>>         importing the whole module fails. And in the end the result
>>>         is the same, weave doesn't work at all for 3.x.
>>>
>>>         Cheers,
>>>         Ralf
>>>
>>>
>>>
>>>         _______________________________________________
>>>         SciPy-Dev mailing list
>>>         SciPy-Dev at scipy.org  <mailto:SciPy-Dev at scipy.org>
>>>         http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>         _______________________________________________
>>         SciPy-Dev mailing list
>>         SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>>         http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     SciPy-Dev mailing list
>>     SciPy-Dev at scipy.org  <mailto:SciPy-Dev at scipy.org>
>>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>     _______________________________________________
>     SciPy-Dev mailing list
>     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20120710/c71e46d8/attachment.html>