[SciPy-Dev] update on 0.11.0 status
Ralf Gommers
ralf.gommers@googlemail....
Wed Jul 11 16:45:45 CDT 2012
On Tue, Jul 10, 2012 at 11:33 PM, Jake Vanderplas <
vanderplas@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@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@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@scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing listSciPy-Dev@scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
>
> _______________________________________________
> SciPy-Dev mailing listSciPy-Dev@scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20120711/41ba8097/attachment.html
More information about the SciPy-Dev
mailing list