[SciPy-User] ANN: SciPy 0.11.0 beta 1 released

[josef.pktd at gmail.com]

On Thu, Jun 14, 2012 at 2:33 PM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>
>
> On 6/13/2012 10:56 AM, Ralf Gommers wrote:
>> Hi,
>>
>> I am pleased to announce the availability of the first beta release of
>> SciPy 0.11.0. For this release over 120 tickets and pull requests have
>> been closed, and many new features have been added. Also noteworthy is
>> that the number of contributors for this release has risen to over 50.
>> Some of the highlights are:
>>
>>    - A new module, sparse.csgraph, has been added which provides a
>> number of common sparse graph algorithms.
>>    - New unified interfaces to the existing optimization and root
>> finding functions have been added.
>>
>> Sources and binaries can be found at
>> http://sourceforge.net/projects/scipy/files/scipy/0.11.0b1/, release
>> notes are copied below.
>>
>> Please try this release and report any problems on the mailing list.
>>
>> Cheers,
>> Ralf
>>
>
> Hi Ralf,
>
> Using msvc9/MKL builds and numpy 1.6.2:
>
> All tests pass on win-amd64-py2.7 and win32-py2.7 (except for the known
> ndimage.test_datatypes.test_uint64_max failure on win32).
>
> test_smoke_bisplrep_bisplev fails on win-amd64-py3.2 and win32-py3.2.
>
> test_shortest_path.test_shortest_path_indices fails on win-amd64-py3.2.
>
> Christoph
>
>
> ======================================================================
> ERROR: test_smoke_bisplrep_bisplev (test_fitpack.TestSmokeTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "X:\Python32-x32\lib\site-packages\scipy\interpolate\tests\test_fitpack.py",
> line 219, in test_smoke_bisplrep_bisplev
>     self.check_5()
>   File
> "X:\Python32-x32\lib\site-packages\scipy\interpolate\tests\test_fitpack.py",
> line 180, in check_5
>     xy=makepairs(x,y)
>   File
> "X:\Python32-x32\lib\site-packages\scipy\interpolate\tests\test_fitpack.py",
> line 32, in makepairs
>     xy.shape=sh[0]*sh[1],sh[2]
> IndexError: tuple index out of range
>
> ======================================================================
> FAIL: test_shortest_path.test_shortest_path_indices(array([[ 0.   ,  3.
>   ,  3.   ,  1.   ,  2.858],
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "X:\Python32\lib\site-packages\nose\case.py", line 198, in runTest
>     self.test(*self.arg)
>   File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 800, in assert_array_almost_equal
>     header=('Arrays are not almost equal to %d decimals' % decimal))
>   File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 636, in assert_array_compare
>     raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 6 decimals
>
> (mismatch 15.0%)
>  x: array([[ 0.        ,  3.        ,  3.        ,  1.        ,
> 2.85772861],
>        [ 3.        ,  0.        ,  6.        ,  2.        ,  4.        ],
>        [ 3.        ,  6.        ,  0.        ,  4.        ,  5.85772861],
>        [ 1.        ,  2.        ,  4.        ,  0.        ,  2.85772861]])
>  y: array([[ 0.,  3.,  3.,  1.,  2.],
>        [ 3.,  0.,  6.,  2.,  4.],
>        [ 3.,  6.,  0.,  4.,  5.],
>        [ 1.,  2.,  4.,  0.,  2.]])
>
> ----------------------------------------------------------------------
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user

A late bug:

During Debian testing of statsmodels on various machines, we found
http://projects.scipy.org/scipy/ticket/1680

>From what I have found, dtypes like np.dtype('<f8') don't work
correctly on Big Endian machines.

The umfpack wrapper uses '<' at the two places in the ticket.

>From fixing similar bugs in statsmodels, the change would be just to
drop the '<' from the dtype string.

My current solution for statsmodels is to use spsolve with
use_umfpack=False on Big Endian machines.

Would be good if this could still be changed for 0.11.

I don't know much about exotic machines, but dropping '<' looks
innocent enough to me.

I also don't understand the globals for useUmfpack enought to figure
out whether the tests in
scipy\sparse\linalg\dsolve\tests\test_linsolve.py  actually test the
umfpack version.

Josef