[SciPy-Dev] update on 0.11.0 status
Jake Vanderplas
vanderplas at astro.washington.edu
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>
More information about the SciPy-Dev
mailing list