[SciPy-Dev] update on 0.11.0 status

[Ralf Gommers]

On Tue, Jul 10, 2012 at 11:33 PM, Jake Vanderplas <
vanderplas at astro.washington.edu> wrote:

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

It's clean, some noise related to Python itself but nothing related to
csgraph.

This was 32-bit python 2.6, numpy 1.8-dev by the way. I haven't yet checked
if I get the same when running in 64-bit mode on the same machine yet.

Ralf


   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> 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> 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 listSciPy-Dev at scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing listSciPy-Dev at scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
>
> _______________________________________________
> SciPy-Dev mailing listSciPy-Dev at scipy.orghttp://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/20120711/41ba8097/attachment.html>