From davidmenhur at gmail.com  Tue Oct  1 06:11:12 2013
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Tue, 1 Oct 2013 12:11:12 +0200
Subject: [SciPy-Dev] [Numpy-discussion] 1.8.0rc1
In-Reply-To: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
Message-ID: <CAJhcF=3CSuMWrJzMH4H=_7nC4h1bg=11H5R_vdcxdb+cFqCHBQ@mail.gmail.com>

On 30 September 2013 17:17, Charles R Harris <charlesr.harris at gmail.com>wrote:

> NumPy 1.8.0rc1 is up now on sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc1/>.The binary builds are included except for Python 3.3 on windows, which
> will arrive later. Many thanks to Ralf for the binaries, and to those who
> found and fixed the bugs in the last beta. Any remaining bugs are all my
> fault ;) I hope this will be the last release before final, so please test
> it thoroughly.
>

I installed it with

# python setup.py install

But something is wrong there:

>>> import numpy as np
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/numpy/__init__.py", line 137, in
<module>
    import add_newdocs
  File "/usr/lib64/python2.7/site-packages/numpy/add_newdocs.py", line 13,
in <module>
    from numpy.lib import add_newdoc
  File "/usr/lib64/python2.7/site-packages/numpy/lib/__init__.py", line 4,
in <module>
    from type_check import *
  File "/usr/lib64/python2.7/site-packages/numpy/lib/type_check.py", line
8, in <module>
    import numpy.core.numeric as _nx
  File "/usr/lib64/python2.7/site-packages/numpy/core/__init__.py", line
45, in <module>
    from numpy.testing import Tester
  File "/usr/lib64/python2.7/site-packages/numpy/testing/__init__.py", line
10, in <module>
    import decorators as dec
  File "/usr/lib64/python2.7/site-packages/numpy/testing/decorators.py",
line 19, in <module>
    from numpy.testing.utils import \
  File "/usr/lib64/python2.7/site-packages/numpy/testing/utils.py", line
12, in <module>
    from .nosetester import import_nose
  File "/usr/lib64/python2.7/site-packages/numpy/testing/nosetester.py",
line 12, in <module>
    from numpy.compat import basestring
ImportError: cannot import name basestring


I am using Python27 on Fedora 19.

$ gcc --version
gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/d188a454/attachment.html>

From davidmenhur at gmail.com  Tue Oct  1 06:18:03 2013
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Tue, 1 Oct 2013 12:18:03 +0200
Subject: [SciPy-Dev] [Numpy-discussion] 1.8.0rc1
In-Reply-To: <CAJhcF=3CSuMWrJzMH4H=_7nC4h1bg=11H5R_vdcxdb+cFqCHBQ@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<CAJhcF=3CSuMWrJzMH4H=_7nC4h1bg=11H5R_vdcxdb+cFqCHBQ@mail.gmail.com>
Message-ID: <CAJhcF=0zRSEMGkgOANv2o_42eMKGYa3scqVRMxeU5Rm_C793Rg@mail.gmail.com>

Disregard that, I had not cleaned the previous installation properly.

Sorry for the noise.


On 1 October 2013 12:11, Da?id <davidmenhur at gmail.com> wrote:

>
> On 30 September 2013 17:17, Charles R Harris <charlesr.harris at gmail.com>wrote:
>
>> NumPy 1.8.0rc1 is up now on sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc1/>.The binary builds are included except for Python 3.3 on windows, which
>> will arrive later. Many thanks to Ralf for the binaries, and to those who
>> found and fixed the bugs in the last beta. Any remaining bugs are all my
>> fault ;) I hope this will be the last release before final, so please test
>> it thoroughly.
>>
>
> I installed it with
>
> # python setup.py install
>
> But something is wrong there:
>
> >>> import numpy as np
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/lib64/python2.7/site-packages/numpy/__init__.py", line 137,
> in <module>
>     import add_newdocs
>   File "/usr/lib64/python2.7/site-packages/numpy/add_newdocs.py", line 13,
> in <module>
>     from numpy.lib import add_newdoc
>   File "/usr/lib64/python2.7/site-packages/numpy/lib/__init__.py", line 4,
> in <module>
>     from type_check import *
>   File "/usr/lib64/python2.7/site-packages/numpy/lib/type_check.py", line
> 8, in <module>
>     import numpy.core.numeric as _nx
>   File "/usr/lib64/python2.7/site-packages/numpy/core/__init__.py", line
> 45, in <module>
>     from numpy.testing import Tester
>   File "/usr/lib64/python2.7/site-packages/numpy/testing/__init__.py",
> line 10, in <module>
>     import decorators as dec
>   File "/usr/lib64/python2.7/site-packages/numpy/testing/decorators.py",
> line 19, in <module>
>     from numpy.testing.utils import \
>   File "/usr/lib64/python2.7/site-packages/numpy/testing/utils.py", line
> 12, in <module>
>     from .nosetester import import_nose
>   File "/usr/lib64/python2.7/site-packages/numpy/testing/nosetester.py",
> line 12, in <module>
>     from numpy.compat import basestring
> ImportError: cannot import name basestring
>
>
> I am using Python27 on Fedora 19.
>
> $ gcc --version
> gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/a6e513ac/attachment.html>

From howarth at bromo.med.uc.edu  Tue Oct  1 09:28:47 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Tue, 1 Oct 2013 09:28:47 -0400
Subject: [SciPy-Dev] 1.8.0rc1
In-Reply-To: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
Message-ID: <20131001132847.GA14614@bromo.med.uc.edu>

On Mon, Sep 30, 2013 at 09:17:14AM -0600, Charles R Harris wrote:
> Hi All,
> 
> NumPy 1.8.0rc1 is up now on
> sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc1/>.The
> binary builds are included except for Python 3.3 on windows, which
> will arrive later. Many thanks to Ralf for the binaries, and to those who
> found and fixed the bugs in the last beta. Any remaining bugs are all my
> fault ;) I hope this will be the last release before final, so please test
> it thoroughly.
> 
> Chuck

Chuck,
   The NumPy 1.8.0rc1 release fails to build on Mac OS X 10.6.8 under fink using the
build command...

/sw/bin/python2.7 setup.py build

which fails at...

/sw/bin/gfortran -Wall -L/sw/lib build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1 -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lgfortran -o build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o
  "_PyOS_snprintf", referenced from:
      _xerbla_ in python_xerbla.o
  "_PyGILState_Ensure", referenced from:
      _xerbla_ in python_xerbla.o
  "_PyExc_ValueError", referenced from:
      _xerbla_ in python_xerbla.o
etc

The full build log is attached.
        Jack
ps The same build approach works fine for the current numpy 1.7.1 release.

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: numpy-py27-10.6.log.bz2
Type: application/x-bzip2
Size: 12159 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/4f0dbf12/attachment.bin>

From ttomecek at redhat.com  Tue Oct  1 11:07:41 2013
From: ttomecek at redhat.com (Tomas Tomecek)
Date: Tue, 01 Oct 2013 17:07:41 +0200
Subject: [SciPy-Dev] scipy.weave uses md5 -- can't run in FIPS mode
Message-ID: <1380640061.10286.24.camel@localhost>

Hello everyone,

since weave uses md5, it can't run in FIPS mode.

Have you been asked about this in a past? Would it be possible to use
some NIST approved hash function?

Regards,
-- 
Tomas Tomecek
---------------------------
* Software Engineer       *
* Developer Experience    *
* Red Hat Czech, s. r. o. *
* UTC+2 (CEST), ttomecek  *







From pav at iki.fi  Tue Oct  1 11:36:00 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 01 Oct 2013 18:36:00 +0300
Subject: [SciPy-Dev] scipy.weave uses md5 -- can't run in FIPS mode
In-Reply-To: <1380640061.10286.24.camel@localhost>
References: <1380640061.10286.24.camel@localhost>
Message-ID: <l2eq4n$qcd$1@ger.gmane.org>

01.10.2013 18:07, Tomas Tomecek kirjoitti:
[clip]
> since weave uses md5, it can't run in FIPS mode.
> 
> Have you been asked about this in a past? Would it be possible to use
> some NIST approved hash function?

The hash is only used for caching compilation results AFAIK, so it could
be substituted with SHA1 or something else. Patches accepted, I think.

-- 
Pauli Virtanen



From robert.kern at gmail.com  Tue Oct  1 11:40:15 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 1 Oct 2013 16:40:15 +0100
Subject: [SciPy-Dev] scipy.weave uses md5 -- can't run in FIPS mode
In-Reply-To: <1380640061.10286.24.camel@localhost>
References: <1380640061.10286.24.camel@localhost>
Message-ID: <CAF6FJisinwKuQhUmPiqr+JjD2jadc4uBSqotbDCf+ogbWwirkg@mail.gmail.com>

On Tue, Oct 1, 2013 at 4:07 PM, Tomas Tomecek <ttomecek at redhat.com> wrote:
>
> Hello everyone,
>
> since weave uses md5, it can't run in FIPS mode.
>
> Have you been asked about this in a past? Would it be possible to use
> some NIST approved hash function?

To my knowledge, no one has asked about it.

The specific hash is not critical, as the hash is not used for any security
purpose whatsoever. It's just a key for a cache of code for recompilation
(similar to ccache). If FIPS mode really requires that MD5 is not used
anywhere for any purpose, then you can patch scipy.weave to use a different
hash. However, I do reiterate that scipy.weave has no security guarantees
whatsoever, the MD5 hash is not used for any security purpose, and the
cryptographic security properties of the hash have no effect on the
operation of scipy.weave in the slightest. scipy.weave will be just as
insecure with SHA-whatever as it is with MD5.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/501754b0/attachment.html>

From pav at iki.fi  Tue Oct  1 11:41:27 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 01 Oct 2013 18:41:27 +0300
Subject: [SciPy-Dev] 1.8.0rc1
In-Reply-To: <20131001132847.GA14614@bromo.med.uc.edu>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<20131001132847.GA14614@bromo.med.uc.edu>
Message-ID: <l2eqeu$1l2$1@ger.gmane.org>

Hi,

01.10.2013 16:28, Jack Howarth kirjoitti:
[clip]
> /sw/bin/python2.7 setup.py build
> 
> which fails at...
> 
> /sw/bin/gfortran -Wall -L/sw/lib build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1 -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lgfortran -o build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so
> Undefined symbols for architecture x86_64:
>   "_main", referenced from:
>       start in crt1.10.6.o
[clip]

Something is screwed up in your build environment: the `-shared` flag is
missing from the link command.

Perhaps you have set one of the the environment variables FFLAGS,
CFLAGS, LDFLAGS?

-- 
Pauli Virtanen



From robert.kern at gmail.com  Tue Oct  1 11:52:06 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 1 Oct 2013 16:52:06 +0100
Subject: [SciPy-Dev] 1.8.0rc1
In-Reply-To: <l2eqeu$1l2$1@ger.gmane.org>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<20131001132847.GA14614@bromo.med.uc.edu> <l2eqeu$1l2$1@ger.gmane.org>
Message-ID: <CAF6FJis0YBNitUmt67A9M=95FCzj=QXADgDGmz1VnfRS=0+1+Q@mail.gmail.com>

On Tue, Oct 1, 2013 at 4:41 PM, Pauli Virtanen <pav at iki.fi> wrote:
>
> Hi,
>
> 01.10.2013 16:28, Jack Howarth kirjoitti:
> [clip]
> > /sw/bin/python2.7 setup.py build
> >
> > which fails at...
> >
> > /sw/bin/gfortran -Wall -L/sw/lib
build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o
build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o
-L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1
-Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas
-lgfortran -o build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so
> > Undefined symbols for architecture x86_64:
> >   "_main", referenced from:
> >       start in crt1.10.6.o
> [clip]
>
> Something is screwed up in your build environment: the `-shared` flag is
> missing from the link command.
>
> Perhaps you have set one of the the environment variables FFLAGS,
> CFLAGS, LDFLAGS?

Also the `-undefined dynamic_lookup` flag.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/7190cc5b/attachment.html>

From mingarelli at gmail.com  Tue Oct  1 11:54:50 2013
From: mingarelli at gmail.com (Chiara Mingarelli)
Date: Tue, 1 Oct 2013 16:54:50 +0100
Subject: [SciPy-Dev] Broken example links on Front Page
Message-ID: <CAMBQnBB5GqKifYmdwUTwA3-n_MwF0Oxd6ju2sumcSEup1RHRBQ@mail.gmail.com>

Dear all,
I am new to the scipy developer group and wanted to make sure I knew
exactly what I was doing before touching anything. I therefore tried to
look at the examples provided in the "Before you start" section, however
the links are broken.
Specifically, in "Before you start" item 2-- the "this template" link (
http://projects.scipy.org/numpy/browser/trunk/doc/example.py) is broken, as
is "the example here" (
http://projects.scipy.org/numpy/browser/trunk/doc/EXAMPLE_DOCSTRING.txt).
Thank you for looking into this. I look forward to contributing to scipy!
Cheers
Chiara


-- 
*Chiara Mingarelli*
twitter @gravitate_to_me
www.chiaramingarelli.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/c3beb956/attachment.html>

From howarth at bromo.med.uc.edu  Tue Oct  1 12:02:21 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Tue, 1 Oct 2013 12:02:21 -0400
Subject: [SciPy-Dev] 1.8.0rc1
In-Reply-To: <CAF6FJis0YBNitUmt67A9M=95FCzj=QXADgDGmz1VnfRS=0+1+Q@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<20131001132847.GA14614@bromo.med.uc.edu>
	<l2eqeu$1l2$1@ger.gmane.org>
	<CAF6FJis0YBNitUmt67A9M=95FCzj=QXADgDGmz1VnfRS=0+1+Q@mail.gmail.com>
Message-ID: <20131001160221.GA15735@bromo.med.uc.edu>

On Tue, Oct 01, 2013 at 04:52:06PM +0100, Robert Kern wrote:
> On Tue, Oct 1, 2013 at 4:41 PM, Pauli Virtanen <pav at iki.fi> wrote:
> >
> > Hi,
> >
> > 01.10.2013 16:28, Jack Howarth kirjoitti:
> > [clip]
> > > /sw/bin/python2.7 setup.py build
> > >
> > > which fails at...
> > >
> > > /sw/bin/gfortran -Wall -L/sw/lib
> build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o
> build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o
> -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1
> -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas
> -lgfortran -o build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so
> > > Undefined symbols for architecture x86_64:
> > >   "_main", referenced from:
> > >       start in crt1.10.6.o
> > [clip]
> >
> > Something is screwed up in your build environment: the `-shared` flag is
> > missing from the link command.
> >
> > Perhaps you have set one of the the environment variables FFLAGS,
> > CFLAGS, LDFLAGS?
> 
> Also the `-undefined dynamic_lookup` flag.

The consensus of the fink developers is that you are introducing a bug in both
scipy and numpy. The build should be able to pass additional flags on these
variables and the scipy/numpy build should be able to append any additional
flags required. In particular, both MacPorts and fink will want to be able to
pass -L/opt/local/lib or -L/sw/lib via LDFLAGS. The changes added to scipy and
numpy have broken this and now require that these additional flags be manually
patched into the Makefiles of numpy and scipy rather than just passing them
on LDFLAGS as has always worked in the past.
         Jack

> 
> --
> Robert Kern

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From robert.kern at gmail.com  Tue Oct  1 12:03:46 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 1 Oct 2013 17:03:46 +0100
Subject: [SciPy-Dev] Broken example links on Front Page
In-Reply-To: <CAMBQnBB5GqKifYmdwUTwA3-n_MwF0Oxd6ju2sumcSEup1RHRBQ@mail.gmail.com>
References: <CAMBQnBB5GqKifYmdwUTwA3-n_MwF0Oxd6ju2sumcSEup1RHRBQ@mail.gmail.com>
Message-ID: <CAF6FJisEfvzxOftpfCq6zZ9ak+ngjUOBv6VcCGfgKx92iYKQeg@mail.gmail.com>

On Tue, Oct 1, 2013 at 4:54 PM, Chiara Mingarelli <mingarelli at gmail.com>
wrote:
>
> Dear all,
> I am new to the scipy developer group and wanted to make sure I knew
exactly what I was doing before touching anything. I therefore tried to
look at the examples provided in the "Before you start" section, however
the links are broken.
> Specifically, in "Before you start" item 2-- the "this template" link (
http://projects.scipy.org/numpy/browser/trunk/doc/example.py) is broken, as
is "the example here" (
http://projects.scipy.org/numpy/browser/trunk/doc/EXAMPLE_DOCSTRING.txt).
> Thank you for looking into this. I look forward to contributing to scipy!

Indeed, the correct URLs are the following:

  https://github.com/numpy/numpy/blob/master/doc/example.py
  https://raw.github.com/numpy/numpy/master/doc/EXAMPLE_DOCSTRING.rst.txt

Where are you seeing these links? I'm not familiar with a document that has
a "Before you start" section.

Thanks!

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/2dbfe5f8/attachment.html>

From mingarelli at gmail.com  Tue Oct  1 12:05:18 2013
From: mingarelli at gmail.com (Chiara Mingarelli)
Date: Tue, 1 Oct 2013 17:05:18 +0100
Subject: [SciPy-Dev] Broken example links on Front Page
In-Reply-To: <CAF6FJisEfvzxOftpfCq6zZ9ak+ngjUOBv6VcCGfgKx92iYKQeg@mail.gmail.com>
References: <CAMBQnBB5GqKifYmdwUTwA3-n_MwF0Oxd6ju2sumcSEup1RHRBQ@mail.gmail.com>
	<CAF6FJisEfvzxOftpfCq6zZ9ak+ngjUOBv6VcCGfgKx92iYKQeg@mail.gmail.com>
Message-ID: <CAMBQnBD+exsRwj+eOSOFQYUAQ8NESD5OwngfFptxqGUn1Ws05g@mail.gmail.com>

Hi Robert,
This is the first page that I saw after I logged in  ->
http://docs.scipy.org/numpy/Front%20Page/#before-you-start
Hope this helps, and thanks for the correct links!
Chiara


On Tue, Oct 1, 2013 at 5:03 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Tue, Oct 1, 2013 at 4:54 PM, Chiara Mingarelli <mingarelli at gmail.com>
> wrote:
> >
> > Dear all,
> > I am new to the scipy developer group and wanted to make sure I knew
> exactly what I was doing before touching anything. I therefore tried to
> look at the examples provided in the "Before you start" section, however
> the links are broken.
> > Specifically, in "Before you start" item 2-- the "this template" link (
> http://projects.scipy.org/numpy/browser/trunk/doc/example.py) is broken,
> as is "the example here" (
> http://projects.scipy.org/numpy/browser/trunk/doc/EXAMPLE_DOCSTRING.txt).
> > Thank you for looking into this. I look forward to contributing to scipy!
>
> Indeed, the correct URLs are the following:
>
>   https://github.com/numpy/numpy/blob/master/doc/example.py
>   https://raw.github.com/numpy/numpy/master/doc/EXAMPLE_DOCSTRING.rst.txt
>
> Where are you seeing these links? I'm not familiar with a document that
> has a "Before you start" section.
>
> Thanks!
>
> --
> Robert Kern
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
*Chiara Mingarelli*
twitter @gravitate_to_me
www.chiaramingarelli.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/f4fd9f1f/attachment.html>

From robert.kern at gmail.com  Tue Oct  1 12:10:39 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 1 Oct 2013 17:10:39 +0100
Subject: [SciPy-Dev] 1.8.0rc1
In-Reply-To: <20131001160221.GA15735@bromo.med.uc.edu>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<20131001132847.GA14614@bromo.med.uc.edu> <l2eqeu$1l2$1@ger.gmane.org>
	<CAF6FJis0YBNitUmt67A9M=95FCzj=QXADgDGmz1VnfRS=0+1+Q@mail.gmail.com>
	<20131001160221.GA15735@bromo.med.uc.edu>
Message-ID: <CAF6FJisSxJHOTLNOKPd64Qus-8A4n_EKpWnhWAM=Vz-V0q-Hwg@mail.gmail.com>

On Tue, Oct 1, 2013 at 5:02 PM, Jack Howarth <howarth at bromo.med.uc.edu>
wrote:
>
> On Tue, Oct 01, 2013 at 04:52:06PM +0100, Robert Kern wrote:
> > On Tue, Oct 1, 2013 at 4:41 PM, Pauli Virtanen <pav at iki.fi> wrote:
> > >
> > > Hi,
> > >
> > > 01.10.2013 16:28, Jack Howarth kirjoitti:
> > > [clip]
> > > > /sw/bin/python2.7 setup.py build
> > > >
> > > > which fails at...
> > > >
> > > > /sw/bin/gfortran -Wall -L/sw/lib
> > build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o
> >
build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o
> > -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1
> > -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas
-latlas
> > -lgfortran -o
build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so
> > > > Undefined symbols for architecture x86_64:
> > > >   "_main", referenced from:
> > > >       start in crt1.10.6.o
> > > [clip]
> > >
> > > Something is screwed up in your build environment: the `-shared` flag
is
> > > missing from the link command.
> > >
> > > Perhaps you have set one of the the environment variables FFLAGS,
> > > CFLAGS, LDFLAGS?
> >
> > Also the `-undefined dynamic_lookup` flag.
>
> The consensus of the fink developers is that you are introducing a bug in
both
> scipy and numpy. The build should be able to pass additional flags on
these
> variables and the scipy/numpy build should be able to append any
additional
> flags required. In particular, both MacPorts and fink will want to be
able to
> pass -L/opt/local/lib or -L/sw/lib via LDFLAGS. The changes added to
scipy and
> numpy have broken this and now require that these additional flags be
manually
> patched into the Makefiles of numpy and scipy rather than just passing
them
> on LDFLAGS as has always worked in the past.

Oh no it hasn't. It has been a consistent thorn in our side for a very long
time. In the case of Fortran modules built by numpy.distutils, $LDFLAGS has
replaced rather than appended flags since time immemorial. It is a
compromise solution to work around the fact that the wide variety of
Fortran compilers are very finicky about their flags, and distutils is not
very accommodating about letting users change the flags to suit their local
environments. If you think you have a better solution to this problem that
does not degrade the existing flexibility, your PR will be cheerfully
accepted. No one thinks this is desirable behavior, but it is most
certainly not *new* behavior.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/a9797d0d/attachment.html>

From robert.kern at gmail.com  Tue Oct  1 12:14:17 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 1 Oct 2013 17:14:17 +0100
Subject: [SciPy-Dev] Broken example links on Front Page
In-Reply-To: <CAMBQnBD+exsRwj+eOSOFQYUAQ8NESD5OwngfFptxqGUn1Ws05g@mail.gmail.com>
References: <CAMBQnBB5GqKifYmdwUTwA3-n_MwF0Oxd6ju2sumcSEup1RHRBQ@mail.gmail.com>
	<CAF6FJisEfvzxOftpfCq6zZ9ak+ngjUOBv6VcCGfgKx92iYKQeg@mail.gmail.com>
	<CAMBQnBD+exsRwj+eOSOFQYUAQ8NESD5OwngfFptxqGUn1Ws05g@mail.gmail.com>
Message-ID: <CAF6FJit2QkUKmg0aj8ck0tnibD6HeLgH91jyOS3ULJvu0UHoFQ@mail.gmail.com>

On Tue, Oct 1, 2013 at 5:05 PM, Chiara Mingarelli <mingarelli at gmail.com>
wrote:
>
> Hi Robert,
> This is the first page that I saw after I logged in  ->
http://docs.scipy.org/numpy/Front%20Page/#before-you-start
> Hope this helps, and thanks for the correct links!

Excellent, thank you! I will go edit that page to fix the links.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131001/4255f63c/attachment.html>

From howarth at bromo.med.uc.edu  Tue Oct  1 14:43:40 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Tue, 1 Oct 2013 14:43:40 -0400
Subject: [SciPy-Dev] 1.8.0rc1
In-Reply-To: <CAF6FJisSxJHOTLNOKPd64Qus-8A4n_EKpWnhWAM=Vz-V0q-Hwg@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<20131001132847.GA14614@bromo.med.uc.edu>
	<l2eqeu$1l2$1@ger.gmane.org>
	<CAF6FJis0YBNitUmt67A9M=95FCzj=QXADgDGmz1VnfRS=0+1+Q@mail.gmail.com>
	<20131001160221.GA15735@bromo.med.uc.edu>
	<CAF6FJisSxJHOTLNOKPd64Qus-8A4n_EKpWnhWAM=Vz-V0q-Hwg@mail.gmail.com>
Message-ID: <20131001184340.GA16151@bromo.med.uc.edu>

On Tue, Oct 01, 2013 at 05:10:39PM +0100, Robert Kern wrote:
> On Tue, Oct 1, 2013 at 5:02 PM, Jack Howarth <howarth at bromo.med.uc.edu>
> wrote:
> >
> > On Tue, Oct 01, 2013 at 04:52:06PM +0100, Robert Kern wrote:
> > > On Tue, Oct 1, 2013 at 4:41 PM, Pauli Virtanen <pav at iki.fi> wrote:
> > > >
> > > > Hi,
> > > >
> > > > 01.10.2013 16:28, Jack Howarth kirjoitti:
> > > > [clip]
> > > > > /sw/bin/python2.7 setup.py build
> > > > >
> > > > > which fails at...
> > > > >
> > > > > /sw/bin/gfortran -Wall -L/sw/lib
> > > build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o
> > >
> build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o
> > > -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1
> > > -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas
> -latlas
> > > -lgfortran -o
> build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so
> > > > > Undefined symbols for architecture x86_64:
> > > > >   "_main", referenced from:
> > > > >       start in crt1.10.6.o
> > > > [clip]
> > > >
> > > > Something is screwed up in your build environment: the `-shared` flag
> is
> > > > missing from the link command.
> > > >
> > > > Perhaps you have set one of the the environment variables FFLAGS,
> > > > CFLAGS, LDFLAGS?
> > >
> > > Also the `-undefined dynamic_lookup` flag.
> >
> > The consensus of the fink developers is that you are introducing a bug in
> both
> > scipy and numpy. The build should be able to pass additional flags on
> these
> > variables and the scipy/numpy build should be able to append any
> additional
> > flags required. In particular, both MacPorts and fink will want to be
> able to
> > pass -L/opt/local/lib or -L/sw/lib via LDFLAGS. The changes added to
> scipy and
> > numpy have broken this and now require that these additional flags be
> manually
> > patched into the Makefiles of numpy and scipy rather than just passing
> them
> > on LDFLAGS as has always worked in the past.
> 
> Oh no it hasn't. It has been a consistent thorn in our side for a very long
> time. In the case of Fortran modules built by numpy.distutils, $LDFLAGS has
> replaced rather than appended flags since time immemorial. It is a
> compromise solution to work around the fact that the wide variety of
> Fortran compilers are very finicky about their flags, and distutils is not
> very accommodating about letting users change the flags to suit their local
> environments. If you think you have a better solution to this problem that
> does not degrade the existing flexibility, your PR will be cheerfully
> accepted. No one thinks this is desirable behavior, but it is most
> certainly not *new* behavior.

Robert,
  Okay. Good news, bad news. The good news is that on fink for both darwin12 and darwin13,
using 'NoSetLDFLAGS: true' is sufficient to solve the linkage problems while retaining the
passing of -L/sw/lib for both numpy 1.8.0rc1 and current git of scipy 0.13.0. The resulting
numpy 1.8.0rc1, against python 2.7.5, on both darwin12 and darwin13 shows....

OK (KNOWNFAIL=5, SKIP=19)

The bad news is that while the scipy 0.13.0 git builds fine on darwin12 and darwin13 without
testsuite regressions against numpy 1.7.1, scipy 0.13.0 git shows failures against numpy 1.8.0rc1.
On darwin12, I get...

======================================================================
ERROR: Test that bode() finds a reasonable frequency range.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_ltisys.py", line 473, in test_05
    w, mag, phase = bode(system, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 1015, in bode
    w, y = freqresp(system, w=w, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 1085, in freqresp
    w, h = freqs(sys.num.ravel(), sys.den, worN=worN)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 142, in freqs
    w = findfreqs(b, a, N)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 70, in findfreqs
    1.5 * ez.imag)) + 0.5)
  File "/sw/lib/python2.7/site-packages/numpy/core/fromnumeric.py", line 2130, in amax
    out=out, keepdims=keepdims)
  File "/sw/lib/python2.7/site-packages/numpy/core/_methods.py", line 17, in _amax
    out=out, keepdims=keepdims)
ValueError: zero-size array to reduction operation maximum which has no identity

======================================================================
FAIL: test_cases (test_solvers.TestSolveDiscreteARE)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 132, in test_cases
    self.check_case(case[0], case[1], case[2], case[3])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 128, in check_case
    a.getH()*x*a-(a.getH()*x*b)*inv(r+b.getH()*x*b)*(b.getH()*x*a)+q-x, 0.0)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 100.0%)
 x: matrix([[ 101.68132940 +8.47322212e-13j, -149.17526406 -1.74130113e+02j],
        [-149.17526406 +1.74130113e+02j,  517.05220513 +3.88311605e-12j]])
 y: array(0.0)

======================================================================
FAIL: Test method='gbt' with alpha=0.25 for tf and zpk cases.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_cont2discrete.py", line 218, in test_gbt_with_sio_tf_and_zpk
    assert_allclose(dnum, c2dnum)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 1181, in assert_allclose
    verbose=verbose, header=header)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=1e-07, atol=0

(mismatch 100.0%)
 x: array([[ 0.7,  0. ]])
 y: array([[ 0. +0.00000000e+00j,  0. -2.32036388e+77j]])

======================================================================
FAIL: test_dimpulse (test_dltisys.TestDLTI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_dltisys.py", line 172, in test_dimpulse
    assert_array_almost_equal(yout[0].flatten(), yout_tfimpulse)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 33.3333333333%)
 x: array([ 0.,  1.,  0.])
 y: array([ 0.,  1., -1.])

======================================================================
FAIL: test_dstep (test_dltisys.TestDLTI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_dltisys.py", line 132, in test_dstep
    assert_array_almost_equal(yout[0].flatten(), yout_tfstep)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 33.3333333333%)
 x: array([ 0.,  1.,  1.])
 y: array([ 0.,  1.,  0.])

----------------------------------------------------------------------
Ran 9659 tests in 157.525s

FAILED (KNOWNFAIL=119, SKIP=444, errors=1, failures=4)

and on darwin13, I get...

======================================================================
ERROR: Test that bode() finds a reasonable frequency range.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_ltisys.py", line 473, in test_05
    w, mag, phase = bode(system, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 1015, in bode
    w, y = freqresp(system, w=w, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 1085, in freqresp
    w, h = freqs(sys.num.ravel(), sys.den, worN=worN)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 142, in freqs
    w = findfreqs(b, a, N)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 70, in findfreqs
    1.5 * ez.imag)) + 0.5)
  File "/sw/lib/python2.7/site-packages/numpy/core/fromnumeric.py", line 2130, in amax
    out=out, keepdims=keepdims)
  File "/sw/lib/python2.7/site-packages/numpy/core/_methods.py", line 17, in _amax
    out=out, keepdims=keepdims)
ValueError: zero-size array to reduction operation maximum which has no identity

======================================================================
ERROR: test_ltisys.Test_freqresp.test_freq_range
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_ltisys.py", line 570, in test_freq_range
    w, H = freqresp(system, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 1085, in freqresp
    w, h = freqs(sys.num.ravel(), sys.den, worN=worN)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 142, in freqs
    w = findfreqs(b, a, N)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 70, in findfreqs
    1.5 * ez.imag)) + 0.5)
  File "/sw/lib/python2.7/site-packages/numpy/core/fromnumeric.py", line 2130, in amax
    out=out, keepdims=keepdims)
  File "/sw/lib/python2.7/site-packages/numpy/core/_methods.py", line 17, in _amax
    out=out, keepdims=keepdims)
ValueError: zero-size array to reduction operation maximum which has no identity

======================================================================
FAIL: test_cases (test_solvers.TestSolveDiscreteARE)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 132, in test_cases
    self.check_case(case[0], case[1], case[2], case[3])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 128, in check_case
    a.getH()*x*a-(a.getH()*x*b)*inv(r+b.getH()*x*b)*(b.getH()*x*a)+q-x, 0.0)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 100.0%)
 x: matrix([[ -2.42159197e+221 +1.62702106e+235j,
           2.78628694e+235 -2.38697996e+235j],
        [ -2.78628694e+235 -2.38697996e+235j,
          -1.06747728e+222 +8.27344440e+235j]])
 y: array(0.0)

======================================================================
FAIL: Test method='gbt' with alpha=0.25 for tf and zpk cases.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_cont2discrete.py", line 218, in test_gbt_with_sio_tf_and_zpk
    assert_allclose(dnum, c2dnum)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 1181, in assert_allclose
    verbose=verbose, header=header)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=1e-07, atol=0

(mismatch 100.0%)
 x: array([[ 0.7,  1.4]])
 y: array([[ 0.5 +1.07561885e-232j,  1.0 -2.00390128e+000j]])

======================================================================
FAIL: test_dimpulse (test_dltisys.TestDLTI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_dltisys.py", line 172, in test_dimpulse
    assert_array_almost_equal(yout[0].flatten(), yout_tfimpulse)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 33.3333333333%)
 x: array([ 0.,  1., -2.])
 y: array([ 0.,  1., -1.])

======================================================================
FAIL: test_dstep (test_dltisys.TestDLTI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0b1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_dltisys.py", line 132, in test_dstep
    assert_array_almost_equal(yout[0].flatten(), yout_tfstep)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 33.3333333333%)
 x: array([ 0.,  1., -1.])
 y: array([ 0.,  1.,  0.])

----------------------------------------------------------------------
Ran 9659 tests in 148.120s

FAILED (KNOWNFAIL=119, SKIP=444, errors=2, failures=4)

FYI.


> 
> --
> Robert Kern

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From piet at vanoostrum.org  Wed Oct  2 16:31:46 2013
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Wed, 02 Oct 2013 16:31:46 -0400
Subject: [SciPy-Dev] 1.8.0rc1
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
Message-ID: <m2siwjjtxp.fsf@cochabamba.vanoostrum.org>

Charles R Harris <charlesr.harris at gmail.com> writes:

> Hi All,
>
> NumPy 1.8.0rc1 is up now on sourceforge .The binary builds are included except for Python 3.3 on
> windows, which will arrive later. Many thanks to Ralf for the binaries, and to those who found and
> fixed the bugs in the last beta. Any remaining bugs are all my fault ;) I hope this will be the
> last release before final, so please test it thoroughly.

I have installed 1.0.8rc1 on Python 3.3.2 on Mac OS X Snow Leopard (10.6.8) from the binary installer http://ufpr.dl.sourceforge.net/project/numpy/NumPy/1.8.0rc1/numpy-1.8.0rc1-py3.3-python.org-macosx10.6.dmg an the test fails with 20 errors. I have tried it also with installing from source but it also gives these erros (I haven't checked if the errors are the same bit for bit, but they were also 20). Here is the output of the test run.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: numpy.test
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131002/62957027/attachment.ksh>
-------------- next part --------------

-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

From mrocklin at gmail.com  Thu Oct  3 16:01:44 2013
From: mrocklin at gmail.com (Matthew Rocklin)
Date: Thu, 3 Oct 2013 13:01:44 -0700
Subject: [SciPy-Dev] Tensor decompositions
Message-ID: <CAJ8oX-F_z8bPOd26LfRVgv6Med-ij64zyN8B_X54YHdf2hgaMQ@mail.gmail.com>

Are tensor decompositions implemented anywhere in the scipy ecosystem?  I'm
looking for something similar to Matlab's Tensor
Toolbox.<http://www.sandia.gov/~tgkolda/TensorToolbox/index-2.5.html>

By tensor I mean multilinear algebra.  By decomposition I mean algorithms
like CP decomposition <http://en.wikipedia.org/wiki/CP_decomposition> or Tucker
decomposition <http://en.wikipedia.org/wiki/Tucker_decomposition> and, in
particular, their sparse and non-negative variants.

If they don't exist does anyone have suggestions for starting points for
development?

Best,
-Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131003/0420865d/attachment.html>

From nickel at dbs.ifi.lmu.de  Thu Oct  3 18:35:44 2013
From: nickel at dbs.ifi.lmu.de (Maximilian Nickel)
Date: Fri, 4 Oct 2013 00:35:44 +0200
Subject: [SciPy-Dev] Tensor decompositions
In-Reply-To: <CAJ8oX-F_z8bPOd26LfRVgv6Med-ij64zyN8B_X54YHdf2hgaMQ@mail.gmail.com>
References: <CAJ8oX-F_z8bPOd26LfRVgv6Med-ij64zyN8B_X54YHdf2hgaMQ@mail.gmail.com>
Message-ID: <CA+n+DyvJa9FD+8uY1Hu+S2mVW1WMjePFS_pnvnZ3BQ1WUAjg5g@mail.gmail.com>

Hi,
I have started working on a scikit for multilinear algebra and tensor
decompositions. It is available from

https://github.com/mnick/scikit-tensor

Currently it supports dense and sparse tensors, basic operations like
folding/unfolding, tensor times matrix, tensor times vector, CP-ALS and
higher-order iterations for Tucker. Right now the code is quite messy at
places but usable. I've planned to refactor it, clean it up and write some
docs over the next weeks and do a proper first release. Of course you would
be welcome to contribute!

Best,
Max


On Thu, Oct 3, 2013 at 10:01 PM, Matthew Rocklin <mrocklin at gmail.com> wrote:

> Are tensor decompositions implemented anywhere in the scipy ecosystem?
> I'm looking for something similar to Matlab's Tensor Toolbox.<http://www.sandia.gov/~tgkolda/TensorToolbox/index-2.5.html>
>
> By tensor I mean multilinear algebra.  By decomposition I mean algorithms
> like CP decomposition <http://en.wikipedia.org/wiki/CP_decomposition> or Tucker
> decomposition <http://en.wikipedia.org/wiki/Tucker_decomposition> and, in
> particular, their sparse and non-negative variants.
>
> If they don't exist does anyone have suggestions for starting points for
> development?
>
> Best,
> -Matthew
>
> _______________________________________________
> 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/20131004/c1f1c631/attachment.html>

From josef.pktd at gmail.com  Thu Oct  3 20:44:27 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 3 Oct 2013 20:44:27 -0400
Subject: [SciPy-Dev] special cephes versus cdflib
Message-ID: <CAMMTP+D3p3kQMGUWxG=aBTnHc2R67J5mBR6T5SeR4CFuHVDb_w@mail.gmail.com>

looking for the source for the cdf of the f-distribution

it's in cephes not in cdflib
https://github.com/scipy/scipy/issues/2958#issuecomment-25668797
(after reading 3 fortran files to see where df>= 1 is imposed. It's
not, in cdflib)


Is there a pattern whether a `special` function is from cephes or cdflib?
If a function exists in cephes, is it used instead of the one from the cdflib?

Is there a backdoor to access the (duplicate) cdflib function from python?

Josef


From robert.kern at gmail.com  Fri Oct  4 07:26:36 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 4 Oct 2013 12:26:36 +0100
Subject: [SciPy-Dev] special cephes versus cdflib
In-Reply-To: <CAMMTP+D3p3kQMGUWxG=aBTnHc2R67J5mBR6T5SeR4CFuHVDb_w@mail.gmail.com>
References: <CAMMTP+D3p3kQMGUWxG=aBTnHc2R67J5mBR6T5SeR4CFuHVDb_w@mail.gmail.com>
Message-ID: <CAF6FJisT_Q0T8WC5mRojEUdfJBqNySYysJCbXvuxGFSex=W9-Q@mail.gmail.com>

On Fri, Oct 4, 2013 at 1:44 AM, <josef.pktd at gmail.com> wrote:
>
> looking for the source for the cdf of the f-distribution
>
> it's in cephes not in cdflib
> https://github.com/scipy/scipy/issues/2958#issuecomment-25668797
> (after reading 3 fortran files to see where df>= 1 is imposed. It's
> not, in cdflib)
>
>
> Is there a pattern whether a `special` function is from cephes or cdflib?
> If a function exists in cephes, is it used instead of the one from the
cdflib?

I believe that CDFLIB was added to scipy later than cephes, so I expect
that for most of the duplicates, the cephes one would be the one exposed in
scipy.special. But there is no firm guideline here, since some of the
CDFLIB versions may have been chosen for better behavior (like perhaps
should be the case here). You always need to check generate_ufuncs.py to
track down the implementation.

> Is there a backdoor to access the (duplicate) cdflib function from python?

No. You will have to wrap it yourself if you want it. Switching the
implementation used in scipy.special.fdtr() should be straightforward if
you want to do so. The wrapper cdff1_wrap() is there in cdf_wrappers.c,
just commented out.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131004/fe89d2c6/attachment.html>

From josef.pktd at gmail.com  Fri Oct  4 08:05:31 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 4 Oct 2013 08:05:31 -0400
Subject: [SciPy-Dev] special cephes versus cdflib
In-Reply-To: <CAF6FJisT_Q0T8WC5mRojEUdfJBqNySYysJCbXvuxGFSex=W9-Q@mail.gmail.com>
References: <CAMMTP+D3p3kQMGUWxG=aBTnHc2R67J5mBR6T5SeR4CFuHVDb_w@mail.gmail.com>
	<CAF6FJisT_Q0T8WC5mRojEUdfJBqNySYysJCbXvuxGFSex=W9-Q@mail.gmail.com>
Message-ID: <CAMMTP+BJBFShPbvBEuzuXe6WN92b1NXf5S38jA0C1cgk-3h7dw@mail.gmail.com>

On Fri, Oct 4, 2013 at 7:26 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Fri, Oct 4, 2013 at 1:44 AM, <josef.pktd at gmail.com> wrote:
>>
>> looking for the source for the cdf of the f-distribution
>>
>> it's in cephes not in cdflib
>> https://github.com/scipy/scipy/issues/2958#issuecomment-25668797
>> (after reading 3 fortran files to see where df>= 1 is imposed. It's
>> not, in cdflib)
>>
>>
>> Is there a pattern whether a `special` function is from cephes or cdflib?
>> If a function exists in cephes, is it used instead of the one from the
>> cdflib?
>
> I believe that CDFLIB was added to scipy later than cephes, so I expect that
> for most of the duplicates, the cephes one would be the one exposed in
> scipy.special. But there is no firm guideline here, since some of the CDFLIB
> versions may have been chosen for better behavior (like perhaps should be
> the case here). You always need to check generate_ufuncs.py to track down
> the implementation.
>
>> Is there a backdoor to access the (duplicate) cdflib function from python?
>
> No. You will have to wrap it yourself if you want it. Switching the
> implementation used in scipy.special.fdtr() should be straightforward if you
> want to do so. The wrapper cdff1_wrap() is there in cdf_wrappers.c, just
> commented out.

Thanks for the clarification.

In this case it's difficult to tell what might be better.
cephes uses `incbet` and
cdflib uses `bratio` for evaluating the incomplete beta function.
No idea which would be better over a larger range of values.

However, cum.f also swaps internally between calculating cdf and isf
which should give better values in the tails.

```
C     XX is such that the incomplete beta with parameters
C     DFD/2 and DFN/2 evaluated at XX is 1 - CUM or CCUM
C
C     YY is 1 - XX
C
C     Calculate the smaller of XX and YY accurately
```

Josef

>
> --
> Robert Kern
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From ralf.gommers at gmail.com  Mon Oct  7 15:38:24 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 7 Oct 2013 21:38:24 +0200
Subject: [SciPy-Dev] planning 0.13.0 release
Message-ID: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>

Hi all,

This has taken a while, but we're now about ready for the first release
candidate of 0.13.0. I plan to cut that on Thursday. Please don't commit to
the 0.13.x branch on Wed or Thu anymore but ping me if anything needs to go
in there at the last minute.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131007/73a7cdde/attachment.html>

From Brian.Newsom at Colorado.EDU  Mon Oct  7 23:19:11 2013
From: Brian.Newsom at Colorado.EDU (Brian Lee Newsom)
Date: Mon, 7 Oct 2013 21:19:11 -0600
Subject: [SciPy-Dev] Integrate.Quad w/ Ctypes Function - Linux Error
Message-ID: <CAEpsjT7aTMY9x_YHq2FvOY3o4n1LB_FDk8T2_d-R_BJ8xyZMBA@mail.gmail.com>

Hi all,

I believe I have found a bug in Integrate.Quad's handling of ctypes
functions (at least on linux systems)  It seems to throw the following
error for functions of dimensions higher than 1.  The following code works
on OSX but not on either of two ubuntu systems I've tested.

  File "test.py", line 10, in <module>
    print quad(testlib.twoD,-1,1,(0,))
  File
"/usr/local/lib/python2.7/dist-packages/scipy/integrate/quadpack.py", line
252, in quad
    retval = _quad(func,a,b,args,full_output,epsabs,epsrel,limit,points)
  File
"/usr/local/lib/python2.7/dist-packages/scipy/integrate/quadpack.py", line
317, in _quad
    return _quadpack._qagse(func,a,b,args,full_output,epsabs,epsrel,limit)
quadpack.error: quad: first argument is a ctypes function pointer with
incorrect signature

To reproduce:
create c function test.c

///////////////////////////test.c\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
#include <stdio.h>
double oneD(double* x);
double twoD(double* x, double* y);
int main(){
    return 0;
}
double oneD(double* x){
  return *x+2.0;
}
double twoD(double* x, double* y){
  return (*x)*(*x) + (*y)*(*y);
}
///////////////////////////test.c\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Compile to a library in same directory with gcc:
OSX: gcc -dynamiclib -o testlib.dylib
Linux: gcc -shared -o testlib.so -fPIC test.c

Then we run the following python file:
///////////////////////////test.py\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
from ctypes import *
from scipy.integrate import quad
testlib = CDLL('./testlib.so') #use .dylib for osx
testlib.oneD.restype = c_double
testlib.oneD.argtypes = (c_double,)
testlib.twoD.restype = c_double
testlib.twoD.argtypes = (c_double, c_double)
#import pdb;pdb.set_trace()
print quad(testlib.oneD,-1,1)
print quad(testlib.twoD,-1,1,(0,))
///////////////////////////test.py\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

oneD works fine, but moving to twoD on ubuntu throws the above error for
whatever reason, while it runs fine on OSX.

If anyone has suggestions or requires any further info, let me know.  It
would also be helpful if someone could confirm this on other systems.

If nothing is immediately evident I plan to submit it to the git issues,
and was curious - what info specifically should I include with that formal
bug report?

Thanks,

Brian Newsom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131007/6c272f66/attachment.html>

From Brian.Newsom at Colorado.EDU  Tue Oct  8 01:17:07 2013
From: Brian.Newsom at Colorado.EDU (Brian Lee Newsom)
Date: Mon, 7 Oct 2013 23:17:07 -0600
Subject: [SciPy-Dev] Quick update to earlier post
Message-ID: <CAEpsjT5vfFwh2hRKOcbcfwJMQyS9XXSWyxoP4cEH7+5ivMLwBg@mail.gmail.com>

Hello,

Just in case it was a source of confusion, somehow I managed to post an
outdated version of my test.c file using pointers that could be cause for
errors in certain situations.  The one I am actually testing with is as
follows:

//////////////test.c\\\\\\\\\\\\\\\\\\\\

#include <stdio.h>
double oneD(double x);
double twoD(double x, double y);
int main(){
  return 0;
}
double oneD(double x){
  return x+2.0;
}
double twoD(double x, double y){
  return x*x + y*y;
}

//////////////test.c\\\\\\\\\\\\\\\\\\\\
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131007/88674140/attachment.html>

From ttomecek at redhat.com  Tue Oct  8 07:41:36 2013
From: ttomecek at redhat.com (Tomas Tomecek)
Date: Tue, 08 Oct 2013 13:41:36 +0200
Subject: [SciPy-Dev] scipy.weave uses md5 -- can't run in FIPS mode
In-Reply-To: <l2eq4n$qcd$1@ger.gmane.org>
References: <1380640061.10286.24.camel@localhost> <l2eq4n$qcd$1@ger.gmane.org>
Message-ID: <1381232496.10286.59.camel@localhost>

On Ut, 2013-10-01 at 18:36 +0300, Pauli Virtanen wrote:
> 01.10.2013 18:07, Tomas Tomecek kirjoitti:
> [clip]
> > since weave uses md5, it can't run in FIPS mode.
> > 
> > Have you been asked about this in a past? Would it be possible to use
> > some NIST approved hash function?
> 
> The hash is only used for caching compilation results AFAIK, so it could
> be substituted with SHA1 or something else. Patches accepted, I think.
> 

So I'm finally looking into this.

I've been advised to use SHA-256 [1]. Unfortunately, it looks like that
on python 2.4 it is hard to use this hash algorithm.

Is this a problem?

[1]
https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Coding/chap-Defensive_Coding-Tasks-Cryptography.html

Regards,
-- 
Tomas Tomecek
---------------------------
* Software Engineer       *
* Developer Experience    *
* Red Hat Czech, s. r. o. *
* UTC+2 (CEST), ttomecek  *







From pav at iki.fi  Tue Oct  8 07:50:23 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 8 Oct 2013 11:50:23 +0000 (UTC)
Subject: [SciPy-Dev] Integrate.Quad w/ Ctypes Function - Linux Error
References: <CAEpsjT7aTMY9x_YHq2FvOY3o4n1LB_FDk8T2_d-R_BJ8xyZMBA@mail.gmail.com>
Message-ID: <loom.20131008T134436-325@post.gmane.org>

Brian Lee Newsom <Brian.Newsom <at> Colorado.EDU> writes:
> [clip: ctypes function to quad]

Correct, the quad() ctypes handler does not currently know
how to pass extra arguments to the function.

This is probably possible to support only to some degree.
The general case of arbitrary argument lists probably won't
work out.

This part of the code probably should also be refactored
somewhat, so that it would be possible to reuse it in other
parts of Scipy, where passing a low-level function directly
to a routine would be useful to avoid call overheads.

[clip]
> If nothing is immediately evident I plan to submit
> it to the git issues, and was curious - what info
> specifically should I include with that formal bug report?

Enough information so that the issue can be understood and
reproduced by someone else. What you wrote in your mail here
is quite sufficient.

-- 
Pauli Virtanen



From pav at iki.fi  Tue Oct  8 07:51:35 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 8 Oct 2013 11:51:35 +0000 (UTC)
Subject: [SciPy-Dev] scipy.weave uses md5 -- can't run in FIPS mode
References: <1380640061.10286.24.camel@localhost> <l2eq4n$qcd$1@ger.gmane.org>
	<1381232496.10286.59.camel@localhost>
Message-ID: <loom.20131008T135055-106@post.gmane.org>

Tomas Tomecek <ttomecek <at> redhat.com> writes:
[clip]
> I've been advised to use SHA-256 [1]. Unfortunately, it looks like that
> on python 2.4 it is hard to use this hash algorithm.
> 
> Is this a problem?

Scipy supports only Python versions >= 2.6

-- 
Pauli Virtanen



From charlesnwoods at gmail.com  Wed Oct  9 13:33:57 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Wed, 9 Oct 2013 11:33:57 -0600
Subject: [SciPy-Dev] Quadpack conversion to Fortran
In-Reply-To: <l0ikjh$9i8$1@ger.gmane.org>
References: <CAEpsjT50wBtMsQp4FCoP0fkSUxh4ECF-P9GKAeiZLjyB_LNduQ@mail.gmail.com>
	<l0ikjh$9i8$1@ger.gmane.org>
Message-ID: <CAAYHtCR8qgPvH3G57AFKceW_wrQf4Gi6GmPdyy93q_=d4L6u3w@mail.gmail.com>

I took a look at the quad routine, and it appears that its ctypes
integration is limited to single-variable functions. I'm not totally sure
why that would be, but it's a bit crippling for anything that includes
extra args, as well as any attempt at multidimensional integrals. Can
anyone confirm this? I'm pretty new at the guts of SciPy and C in general.

Nathan Woods


On Sun, Sep 8, 2013 at 1:53 PM, Pauli Virtanen <pav at iki.fi> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 08.09.2013 07:43, Brian Lee Newsom kirjoitti:
> > My name is Brian Newsom and I am just beginning to use/work on the
> > scipy library, specifically the quadpack within the integration
> > pack. Because of the recursion and wrapping methods used now,
> > running nquad (scipy 0.13) function is slow-the fortran and python
> > are nested in a way that requires switching back and forth between
> > the two often.  Ideally this inefficiency could be overcome by
> > translating the main interface (quadpack.py) into fortran and just
> > having a minimal python wrapper that is not used in the recursion.
>
> The first question: did you measure the overhead involved in the
> Python code, and determined that it dominates the computation time? If
> not, that would be the first thing to do, otherwise it's possible to
> end up with a wild goose chase.
>
> On the face of it, it does not sound likely to me that much will be
> gained by writing the recursion in a lower-level language. Suppose
> that each level requires N >> 1 evaluations of the function. The
> innermost function will be called in total N^3 times, the next level
> N^2 times and the outer level N times. The inner level involves N^3
> calls back to Python, which are not removed by writing the recursion
> in Fortran. Since N^3 >> N^2, the innermost callback overhead
> dominates the run time. Of course, the N^2 term has a bigger prefactor
> than N^3, so this argument is not fully convincing, but it would be
> best to measure first.
>
> IIRC, the `quad` integration routine can directly call ctypes function
> pointers, skipping Python overhead. (See the Python ctypes module
> documentation for details on how to define them.) This requires Scipy
> > = 0.11.0, however.
>
> There have been plans to improve the interoperability further (with
> Cython, f2py, and other ways) to interact directly with low-level code
> in Scipy's computational routines. Putting effort into this direction
> and trying to speed up the innermost part would seem to me the most
> sensible direction of further work.
>
> Of course, the above is written assuming your benchmarks don't show me
> wrong.
>
> I don't believe anyone is currently working on `nquad`, so go ahead.
> However, note that due to the current situation with Mingw Gfortran
> compiler on Windows, there may be issues in accepting Fortran 90 code.
>
>
> Best regards,
>
> - --
> Pauli Virtanen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlIs1a8ACgkQ6BQxb7O0pWBYtwCdHrXw+wXD4UMf9CLzHHe3hkpM
> V6QAniW2X6HeC4YWDHnDJwEZ5suxnXvi
> =3ptO
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20131009/1433e668/attachment.html>

From pav at iki.fi  Wed Oct  9 14:23:48 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 09 Oct 2013 21:23:48 +0300
Subject: [SciPy-Dev] Quadpack conversion to Fortran
In-Reply-To: <CAAYHtCR8qgPvH3G57AFKceW_wrQf4Gi6GmPdyy93q_=d4L6u3w@mail.gmail.com>
References: <CAEpsjT50wBtMsQp4FCoP0fkSUxh4ECF-P9GKAeiZLjyB_LNduQ@mail.gmail.com>
	<l0ikjh$9i8$1@ger.gmane.org>
	<CAAYHtCR8qgPvH3G57AFKceW_wrQf4Gi6GmPdyy93q_=d4L6u3w@mail.gmail.com>
Message-ID: <l346vb$coj$1@ger.gmane.org>

09.10.2013 20:33, Nathan Woods kirjoitti:
> I took a look at the quad routine, and it appears that its ctypes
> integration is limited to single-variable functions. I'm not totally sure
> why that would be, but it's a bit crippling for anything that includes
> extra args, as well as any attempt at multidimensional integrals. Can
> anyone confirm this? I'm pretty new at the guts of SciPy and C in general.

See
http://article.gmane.org/gmane.comp.python.scientific.devel/18285



From charlesnwoods at gmail.com  Wed Oct  9 14:35:04 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Wed, 9 Oct 2013 12:35:04 -0600
Subject: [SciPy-Dev] Quadpack conversion to Fortran
In-Reply-To: <l346vb$coj$1@ger.gmane.org>
References: <CAEpsjT50wBtMsQp4FCoP0fkSUxh4ECF-P9GKAeiZLjyB_LNduQ@mail.gmail.com>
	<l0ikjh$9i8$1@ger.gmane.org>
	<CAAYHtCR8qgPvH3G57AFKceW_wrQf4Gi6GmPdyy93q_=d4L6u3w@mail.gmail.com>
	<l346vb$coj$1@ger.gmane.org>
Message-ID: <CAAYHtCSK9yxTZnPzxCATHtxTk7z4nK3THY6s1QZSxyEydijpvg@mail.gmail.com>

I gather that there's not an established template for how to do this sort
of thing?

For instance, is there some other part of SciPy where someone has
integrated Cython (say) with low-level libraries such that callbacks to
python are avoided?

Nathan Woods


On Wed, Oct 9, 2013 at 12:23 PM, Pauli Virtanen <pav at iki.fi> wrote:

> 09.10.2013 20:33, Nathan Woods kirjoitti:
> > I took a look at the quad routine, and it appears that its ctypes
> > integration is limited to single-variable functions. I'm not totally sure
> > why that would be, but it's a bit crippling for anything that includes
> > extra args, as well as any attempt at multidimensional integrals. Can
> > anyone confirm this? I'm pretty new at the guts of SciPy and C in
> general.
>
> See
> http://article.gmane.org/gmane.comp.python.scientific.devel/18285
>
> _______________________________________________
> 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/20131009/34fbf7fe/attachment.html>

From pav at iki.fi  Wed Oct  9 14:43:31 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 09 Oct 2013 21:43:31 +0300
Subject: [SciPy-Dev] Quadpack conversion to Fortran
In-Reply-To: <CAAYHtCSK9yxTZnPzxCATHtxTk7z4nK3THY6s1QZSxyEydijpvg@mail.gmail.com>
References: <CAEpsjT50wBtMsQp4FCoP0fkSUxh4ECF-P9GKAeiZLjyB_LNduQ@mail.gmail.com>
	<l0ikjh$9i8$1@ger.gmane.org>
	<CAAYHtCR8qgPvH3G57AFKceW_wrQf4Gi6GmPdyy93q_=d4L6u3w@mail.gmail.com>
	<l346vb$coj$1@ger.gmane.org>
	<CAAYHtCSK9yxTZnPzxCATHtxTk7z4nK3THY6s1QZSxyEydijpvg@mail.gmail.com>
Message-ID: <l3484b$qu1$1@ger.gmane.org>

09.10.2013 21:35, Nathan Woods kirjoitti:
> I gather that there's not an established template for how to do this sort
> of thing?
> 
> For instance, is there some other part of SciPy where someone has
> integrated Cython (say) with low-level libraries such that callbacks to
> python are avoided?

No, this thing was added as a quick hack. As I wrote in my other mail,
this should be generalized to a form where the same mechanism can be
reused also in different places.

It might also be desirable to not tie it in with Ctypes at all; [*] we
might just want to have a scipy.CFunction which would provide the
restricted subset of arbitrary parameter passing we want to support, and
in a form that it easy to deal with in C. As you can see from the `quad`
C code, Ctypes is a bit painful here.

[*] Of course, conversion from Ctypes function pointers could be
    provided.

-- 
Pauli Virtanen




From cournape at gmail.com  Thu Oct 10 06:55:38 2013
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 10 Oct 2013 11:55:38 +0100
Subject: [SciPy-Dev] planning 0.13.0 release
In-Reply-To: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
Message-ID: <CAGY4rcXhNGU6SxeqA2Y6GXNPONhoxwH0oHBn5ougaJ0mh4ALtA@mail.gmail.com>

I have tested the current 0.13.x branch on both rh5 and windows with the
MKL, and am happy to report it works perfectly.

We may want to mention in the notes that we can't compile scipy with gcc
4.1.* anymore (at least the rh5 version). Is it ok to make a PR to add
those to the release notes ?

David


On Mon, Oct 7, 2013 at 8:38 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi all,
>
> This has taken a while, but we're now about ready for the first release
> candidate of 0.13.0. I plan to cut that on Thursday. Please don't commit to
> the 0.13.x branch on Wed or Thu anymore but ping me if anything needs to go
> in there at the last minute.
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> 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/20131010/57319541/attachment.html>

From andy.terrel at gmail.com  Thu Oct 10 11:08:27 2013
From: andy.terrel at gmail.com (Andy Ray Terrel)
Date: Thu, 10 Oct 2013 10:08:27 -0500
Subject: [SciPy-Dev] Sources to conference.scipy.org
Message-ID: <CA+WonSRH464_xucnUzBy4yaUQuA80Dzv-s6+Z4pmfGVe1S=Q9A@mail.gmail.com>

Hello all,

In effort to support the providence of our website and conference
technologies, I've started putting everything in the github org:
https://github.com/scipy-conference

To that end, it has become apparent that in moving servers and other
rearranging of the conference in the last few years, the sphinx source that
generates the conference.scipy.org landing page has been lost (at least to
me and the Enthought staff I've been in touch with).

Does anyone have these sources somewhere know where to get them?

-- Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131010/68cfe4a6/attachment.html>

From Brian.Newsom at Colorado.EDU  Thu Oct 10 14:27:24 2013
From: Brian.Newsom at Colorado.EDU (Brian Lee Newsom)
Date: Thu, 10 Oct 2013 12:27:24 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function pointers
	in integrate - quad
Message-ID: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>

Hello,

Thanks for all your replies on this matter.  After consideration it seems
that a reasonable place for work would be on allowing integrate.quad to
robustly accept function pointers from a compiled language, so that they
may bypass the underlying callbacks to python.  The current implementation
does not support additional arguments and because of this cannot be used
with higher dimensions of integration using dblquad/tplquad/nquad when it
is needed most.

It seems a reasonable avenue would be to tackle this issue with Cython,
although I am by no means an expert and if CTypes or the C/Python API is
preferred, I could work with that instead.

Furthermore, is anyone willing to tackle this issue with me? I am still
fairly new to scipy in general and will surely encounter issues in every
stage of development. Any sort of advisory would be very helpful.

I would love to hear any concerns, advice, or just general feedback on this
project. I have not started anything and would like to go about this with
all the help I can get - I believe it will be significantly useful for more
robust integration over any number of dimensions.

Thanks,
Brian Newsom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131010/d75bd42a/attachment.html>

From ralf.gommers at gmail.com  Thu Oct 10 15:35:31 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 10 Oct 2013 21:35:31 +0200
Subject: [SciPy-Dev] planning 0.13.0 release
In-Reply-To: <CAGY4rcXhNGU6SxeqA2Y6GXNPONhoxwH0oHBn5ougaJ0mh4ALtA@mail.gmail.com>
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
	<CAGY4rcXhNGU6SxeqA2Y6GXNPONhoxwH0oHBn5ougaJ0mh4ALtA@mail.gmail.com>
Message-ID: <CABL7CQjghj5yiprmXkZpt_JC1yGQ+y7f6S6S5_+=M6m7gh4tsA@mail.gmail.com>

On Thu, Oct 10, 2013 at 12:55 PM, David Cournapeau <cournape at gmail.com>wrote:

> I have tested the current 0.13.x branch on both rh5 and windows with the
> MKL, and am happy to report it works perfectly.
>
> We may want to mention in the notes that we can't compile scipy with gcc
> 4.1.* anymore (at least the rh5 version). Is it ok to make a PR to add
> those to the release notes ?
>

Sure, makes sense to add that. What's the reason by the way? I don't
remember we broke things on purpose.

Ralf



>
> David
>
>
> On Mon, Oct 7, 2013 at 8:38 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>
>> Hi all,
>>
>> This has taken a while, but we're now about ready for the first release
>> candidate of 0.13.0. I plan to cut that on Thursday. Please don't commit to
>> the 0.13.x branch on Wed or Thu anymore but ping me if anything needs to go
>> in there at the last minute.
>>
>> Cheers,
>> Ralf
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> 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/20131010/77318074/attachment.html>

From pav at iki.fi  Thu Oct 10 15:47:50 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 10 Oct 2013 22:47:50 +0300
Subject: [SciPy-Dev] planning 0.13.0 release
In-Reply-To: <CABL7CQjghj5yiprmXkZpt_JC1yGQ+y7f6S6S5_+=M6m7gh4tsA@mail.gmail.com>
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>	<CAGY4rcXhNGU6SxeqA2Y6GXNPONhoxwH0oHBn5ougaJ0mh4ALtA@mail.gmail.com>
	<CABL7CQjghj5yiprmXkZpt_JC1yGQ+y7f6S6S5_+=M6m7gh4tsA@mail.gmail.com>
Message-ID: <l3708t$kdb$1@ger.gmane.org>

10.10.2013 22:35, Ralf Gommers kirjoitti:
> On Thu, Oct 10, 2013 at 12:55 PM, David Cournapeau
> <cournape at gmail.com>wrote:
>> I have tested the current 0.13.x branch on both rh5 and windows
>> with the MKL, and am happy to report it works perfectly.
>> 
>> We may want to mention in the notes that we can't compile scipy
>> with gcc 4.1.* anymore (at least the rh5 version). Is it ok to
>> make a PR to add those to the release notes ?
>> 
> 
> Sure, makes sense to add that. What's the reason by the way? I
> don't remember we broke things on purpose.

ISTR the reason was compiler bugs in gcc 4.1.* that are fixed only in
newer versions.

-- 
Pauli Virtanen



From piet at vanoostrum.org  Thu Oct 10 16:32:38 2013
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Thu, 10 Oct 2013 16:32:38 -0400
Subject: [SciPy-Dev] planning 0.13.0 release
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
Message-ID: <m2wqlkx3x5.fsf@cochabamba.vanoostrum.org>

Ralf Gommers <ralf.gommers at gmail.com> writes:

> Hi all,
>
> This has taken a while, but we're now about ready for the first release candidate of 0.13.0. I
> plan to cut that on Thursday. Please don't commit to the 0.13.x branch on Wed or Thu anymore but
> ping me if anything needs to go in there at the last minute.
>

I tested the 0.13.x branch (SciPy version 0.13.0b2.dev-db186c3) yesterday on my OS X 10.6.8 together with NumPy version 1.8.0rc1 and all tests were successful.

-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]



From ralf.gommers at gmail.com  Thu Oct 10 16:39:14 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 10 Oct 2013 22:39:14 +0200
Subject: [SciPy-Dev] planning 0.13.0 release
In-Reply-To: <m2wqlkx3x5.fsf@cochabamba.vanoostrum.org>
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
	<m2wqlkx3x5.fsf@cochabamba.vanoostrum.org>
Message-ID: <CABL7CQg+2kwJ0efmRQhiFr9CBkx6M92espd0Hp4smqH23j021Q@mail.gmail.com>

On Thu, Oct 10, 2013 at 10:32 PM, Piet van Oostrum <piet at vanoostrum.org>wrote:

> Ralf Gommers <ralf.gommers at gmail.com> writes:
>
> > Hi all,
> >
> > This has taken a while, but we're now about ready for the first release
> candidate of 0.13.0. I
> > plan to cut that on Thursday. Please don't commit to the 0.13.x branch
> on Wed or Thu anymore but
> > ping me if anything needs to go in there at the last minute.
> >
>
> I tested the 0.13.x branch (SciPy version 0.13.0b2.dev-db186c3) yesterday
> on my OS X 10.6.8 together with NumPy version 1.8.0rc1 and all tests were
> successful.
>

Thanks Piet. Looks like we will need fewer RCs than usual (just one I
hope).

I just tagged 0.13.0rc1 and 0.12.1 by the way. Will send out proper
announcements shortly.

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

From ralf.gommers at gmail.com  Thu Oct 10 16:43:57 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 10 Oct 2013 22:43:57 +0200
Subject: [SciPy-Dev] another milestone
Message-ID: <CABL7CQi=RphUERizO7wLoF4s3YCOBiDzF2Mj5LC8jXFKwq0s4g@mail.gmail.com>

The Scipy SourceForge download counter hit 1 million about two weeks ago:
http://sourceforge.net/projects/scipy/files/scipy/stats/timeline?dates=2001-05-21+to+2013-10-10

Not sure why the stats from before 2007 say 0; I guess the real number is
higher still.

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

From pav at iki.fi  Thu Oct 10 17:16:59 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 11 Oct 2013 00:16:59 +0300
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
Message-ID: <l375g2$hkp$1@ger.gmane.org>

Hi,

10.10.2013 21:27, Brian Lee Newsom kirjoitti:
> Thanks for all your replies on this matter.  After consideration it seems
> that a reasonable place for work would be on allowing integrate.quad to
> robustly accept function pointers from a compiled language, so that they
> may bypass the underlying callbacks to python.  The current implementation
> does not support additional arguments and because of this cannot be used
> with higher dimensions of integration using dblquad/tplquad/nquad when it
> is needed most.

This would certainly be an useful addition. Other places where this
could come useful are in optimization, ODEs, f2py, and 3rd party
packages, and this should be kept in mind while designing the
implementation.


There are a couple of problems that need to be solved:

(i) Converting arguments from Python objects to something generally
usable for a C/Fortran/etc. routine and actually constructing the
C-level call.

(ii) How to pass the raw function + data pointers in to the low-level
computational routines?

(iii) Stashing and retrieving the arguments somewhere.

I didn't yet think this through well, so what's below is just some
first-order thoughts. What perhaps should first be done is to just write
down a proposal of how this should work, before starting coding.

***

In detail:

(i)

What sort of C/Fortran signatures should be accepted? The simplest
option is probably to just support user functions of the form

	return_t func(..., void *params)

where `...` are the arguments as they are passed in by the Fortran/C
algorithm code, and `*params` is then tacked on by indirection. This
removes the need for multiple trampoline routines.

As `params`, we could support e.g. the contents of any Python buffer
objects. The user would then be able to pack the parameters then as
necessary into the array, and interpret them as they see fit in the
objective function.


(ii)

This would need to involve some additions to the code in quad(); for
instance it should check the type of function pointer passed in. Ctypes
makes this possible, but it may be useful to have our own representation
for it (which can be constructed from the ctypes one) that's easier to
deal with.

There are also a couple of different types of ways to integrate with
lower-level code in Scipy: Cython, raw C, f2py.

f2py can take raw function pointers with some trickery.
The C code varies, possible to make to work (e.g. PyCapsules and so on).
Cython code is also reasonably easy to make to work.

Because of this, it may be best to keep the type checks etc. on the
Python side, and just pass the verified function pointer to the
low-level routine.


(iii)

Many of the algorithms we currently have is ancient Fortran code, which
does not accept any "additional arguments" for the functions it calls.

To work around this, there a couple of options. One option is to patch
the codes in Scipy so that an additional pointer argument is always
passed along. This is the simplest solution, but makes the computational
codes to diverge from the originals.

The second option is to generate a new low-level function on the fly
that calls the routine with the correct extra parameters. Difficult to
make portable, so doesn't seem feasible.

The third option is to store the extra data to a global variable / TLS
and be careful with re-entrancy when handling it. quad() currently does
this, so extra args could be added easily in the same mechanism. It may
be possible to refactor some of this a component that can be reused.


-- 
Pauli Virtanen



From charlesnwoods at gmail.com  Thu Oct 10 17:44:33 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Thu, 10 Oct 2013 15:44:33 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <l375g2$hkp$1@ger.gmane.org>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
Message-ID: <CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>

On Thu, Oct 10, 2013 at 3:16 PM, Pauli Virtanen <pav at iki.fi> wrote:

> Hi,
>
> 10.10.2013 21:27, Brian Lee Newsom kirjoitti:
> > Thanks for all your replies on this matter.  After consideration it seems
> > that a reasonable place for work would be on allowing integrate.quad to
> > robustly accept function pointers from a compiled language, so that they
> > may bypass the underlying callbacks to python.  The current
> implementation
> > does not support additional arguments and because of this cannot be used
> > with higher dimensions of integration using dblquad/tplquad/nquad when it
> > is needed most.
>
> This would certainly be an useful addition. Other places where this
> could come useful are in optimization, ODEs, f2py, and 3rd party
> packages, and this should be kept in mind while designing the
> implementation.
>


> There are a couple of problems that need to be solved:
>
> (i) Converting arguments from Python objects to something generally
> usable for a C/Fortran/etc. routine and actually constructing the
> C-level call.
>
> (ii) How to pass the raw function + data pointers in to the low-level
> computational routines?
>
> (iii) Stashing and retrieving the arguments somewhere.
>
> I didn't yet think this through well, so what's below is just some
> first-order thoughts. What perhaps should first be done is to just write
> down a proposal of how this should work, before starting coding.
>
>
I agree fully with this thought. I think that we're essentially talking
about creating a new template for interaction between SciPy and C/Fortran
code. That's not something that you can just throw together.


> ***
>
> In detail:
>
> (i)
>
> What sort of C/Fortran signatures should be accepted? The simplest
> option is probably to just support user functions of the form
>
>         return_t func(..., void *params)
>
> where `...` are the arguments as they are passed in by the Fortran/C
> algorithm code, and `*params` is then tacked on by indirection. This
> removes the need for multiple trampoline routines.
>

I'm not sure I follow you here. I think you're referring to only accepting
user functions that return a single argument, with a pointer to some
additional parameters? Can you give an example of such a parameter as it
would be used in, say, integrate?


>
> As `params`, we could support e.g. the contents of any Python buffer
> objects. The user would then be able to pack the parameters then as
> necessary into the array, and interpret them as they see fit in the
> objective function.
>
>
> (ii)
>
> This would need to involve some additions to the code in quad(); for
> instance it should check the type of function pointer passed in. Ctypes
> makes this possible, but it may be useful to have our own representation
> for it (which can be constructed from the ctypes one) that's easier to
> deal with.
>
>
I guess I thought that we were talking about replacing most of the code in
quad(). As far as I can tell, the integrate library uses the C/Python API
to communicate with the underlying Quadpack code. One of the main
difficulties I see is that the C/Python API is fairly complex, and
therefore the wrapper code is difficult to modify. I'd be a lot happier if
this could be done with one of the simpler tools (probably Cython, since
that seems to be the way the community is leaning), so that the interface
doesn't become a magic black box. It helps that the Fortran community seems
to support this approach:
http://fortran90.org/src/best-practices.html#interfacing-with-python


> There are also a couple of different types of ways to integrate with
> lower-level code in Scipy: Cython, raw C, f2py.
>
> f2py can take raw function pointers with some trickery.
> The C code varies, possible to make to work (e.g. PyCapsules and so on).
> Cython code is also reasonably easy to make to work.
>
> Because of this, it may be best to keep the type checks etc. on the
> Python side, and just pass the verified function pointer to the
> low-level routine.
>
>
> (iii)
>
> Many of the algorithms we currently have is ancient Fortran code, which
> does not accept any "additional arguments" for the functions it calls.
>

I hadn't noticed this. It's kind of a major difficulty.


>
> To work around this, there a couple of options. One option is to patch
> the codes in Scipy so that an additional pointer argument is always
> passed along. This is the simplest solution, but makes the computational
> codes to diverge from the originals.
>
>
Yeah, one of the best things about SLATEC is that it's a standard. Don't
really want to mess with that.


> The second option is to generate a new low-level function on the fly
> that calls the routine with the correct extra parameters. Difficult to
> make portable, so doesn't seem feasible.
>

On-the-fly code generation? Yeah, I can see difficulties there. I ran into
the Python version of this when I wrote nquad, and I dealt with it by using
callable objects instead of functions to store the extra data I needed.
Perhaps something similar can be done here?


>
> The third option is to store the extra data to a global variable / TLS
> and be careful with re-entrancy when handling it. quad() currently does
> this, so extra args could be added easily in the same mechanism. It may
> be possible to refactor some of this a component that can be reused.
>
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


Nathan Woods
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131010/c9e2e74d/attachment.html>

From ralf.gommers at gmail.com  Fri Oct 11 02:57:53 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 11 Oct 2013 08:57:53 +0200
Subject: [SciPy-Dev] ANN: Scipy 0.12.1 release
Message-ID: <CABL7CQiUxdTZaw5v-fFrwUJLJh9yYiBrv0pzcCM8KHpT7ERO7w@mail.gmail.com>

Hi,

I'm happy to announce the availability of the scipy 0.12.1 release. This is
a bugfix only release; it contains a fix for a security issue in the weave
module.

Source tarballs, binaries and release notes can be found at
http://sourceforge.net/projects/scipy/files/scipy/0.12.1/.

Cheers,
Ralf



==========================
SciPy 0.12.1 Release Notes
==========================

SciPy 0.12.1 is a bug-fix release with no new features compared to 0.12.0.
The single issue fixed by this release is a security issue in
``scipy.weave``,
which was previously using temporary directories in an insecure manner
under
certain circumstances.


Checksums
=========

464a7da15804638b4c272e7305200c0b
release/installers/scipy-0.12.1-py2.7-python.org-macosx10.6.dmg
64951c17cfd79f86eb22d1e0a7c7f8fd
release/installers/scipy-0.12.1-win32-superpack-python2.6.exe
81f80077871d7355ac0f659b5b617a34
release/installers/scipy-0.12.1-win32-superpack-python2.7.exe
b45a398cc8702389caaf2feabeef5875
release/installers/scipy-0.12.1-win32-superpack-python3.2.exe
906278290152fedfe79029371ca584a5  release/installers/scipy-0.12.1.tar.gz
3f23065fc45152c92c3588dad2f20c62  release/installers/scipy-0.12.1.zip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131011/a8afd8c5/attachment.html>

From cournape at gmail.com  Fri Oct 11 05:09:53 2013
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 11 Oct 2013 10:09:53 +0100
Subject: [SciPy-Dev] planning 0.13.0 release
In-Reply-To: <CABL7CQjghj5yiprmXkZpt_JC1yGQ+y7f6S6S5_+=M6m7gh4tsA@mail.gmail.com>
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
	<CAGY4rcXhNGU6SxeqA2Y6GXNPONhoxwH0oHBn5ougaJ0mh4ALtA@mail.gmail.com>
	<CABL7CQjghj5yiprmXkZpt_JC1yGQ+y7f6S6S5_+=M6m7gh4tsA@mail.gmail.com>
Message-ID: <CAGY4rcWasL7+xOeGKjPwDfwj4mcQYv1qvdmHT4C54LXQSqszVw@mail.gmail.com>

On Thu, Oct 10, 2013 at 8:35 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

>
>
>
> On Thu, Oct 10, 2013 at 12:55 PM, David Cournapeau <cournape at gmail.com>wrote:
>
>> I have tested the current 0.13.x branch on both rh5 and windows with the
>> MKL, and am happy to report it works perfectly.
>>
>> We may want to mention in the notes that we can't compile scipy with gcc
>> 4.1.* anymore (at least the rh5 version). Is it ok to make a PR to add
>> those to the release notes ?
>>
>
> Sure, makes sense to add that. What's the reason by the way? I don't
> remember we broke things on purpose.
>

No, and I don't know for sure it is a compiler bug: could be a bug on our
end.

Two problems with gcc 4.1* (on rh5, those are often heavily patched):

 - the entry construct in scipy.linalg.interpolative. As soon as you go
there, it crashes. Since that's the only entry construct used in scipy, I
suspect this is just not well supported in gfortran 4.1.
https://github.com/scipy/scipy/issues/2939. We may want to avoid the entry
construct ? Don't know how realistic that is. I certainly would not
consider this a killer for the release, since it can be worked around.
 - gcc 4.4 is more aggressive in optimizing potentially aliased pointers:
not using the -fno-strict-aliasing is not an option anymore, it breaks
cython fused types (lambert is completely broken without it, for example).
I would argue the latter is a cython bug (I think we should be able to
compile scipy and numpy wo -fno-strict-aliasing).

cheers,
David


> Ralf
>
>
>
>>
>> David
>>
>>
>> On Mon, Oct 7, 2013 at 8:38 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> This has taken a while, but we're now about ready for the first release
>>> candidate of 0.13.0. I plan to cut that on Thursday. Please don't commit to
>>> the 0.13.x branch on Wed or Thu anymore but ping me if anything needs to go
>>> in there at the last minute.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> 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
>>
>>
>
> _______________________________________________
> 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/20131011/fb396ddd/attachment.html>

From pav at iki.fi  Fri Oct 11 05:38:20 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 11 Oct 2013 09:38:20 +0000 (UTC)
Subject: [SciPy-Dev] Beginning work on robustly allowing function
	pointers in integrate - quad
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
Message-ID: <loom.20131011T112317-488@post.gmane.org>

Nathan Woods <charlesnwoods <at> gmail.com> writes:
> On Thu, Oct 10, 2013 at 3:16 PM, Pauli Virtanen <pav <at> iki.fi> wrote:
[clip]
> > What sort of C/Fortran signatures should be accepted? The simplest
> > option is probably to just support user functions of the form
> > ? ? ? ? return_t func(..., void *params)
> > where `...` are the arguments as they are passed in by the Fortran/C
> > algorithm code, and `*params` is then tacked on by indirection. This
> > removes the need for multiple trampoline routines.
> 
> I'm not sure I follow you here. I think you're referring to only
> accepting user functions that return a single argument, with a pointer
> to some additional parameters? Can you give an example of such a parameter
> as it would be used in, say, integrate?

The quad callback would be `double f(double *a, void *params)`.
The call signatures of course depends on the routine. Perhaps it should
also be standardized.

What I mean here is that while in Python, you can do `f(arg1, arg2, *a, **kw)`
there's no way in C to make calls with `*a` and `**kw` without on-the-fly
code generation. Which we don't want to do --- too complicated.
The best option is to keep it simple.

[clip]
> I guess I thought that we were talking about replacing most of the
> code in quad(). As far as I can tell, the integrate library uses the
> C/Python API to communicate with the underlying Quadpack code. One of
> the main difficulties I see is that the C/Python API is fairly complex,
> and therefore the wrapper code is difficult to modify. I'd be a lot
> happier if this could be done with one of the simpler tools
> (probably Cython, since that seems to be the way the community is
> leaning), so that the interface doesn't become a magic black box.

The quadpack wrappers could probably be done with f2py without too
many problems.

-- 
Pauli Virtanen



From pav at iki.fi  Fri Oct 11 05:41:53 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 11 Oct 2013 09:41:53 +0000 (UTC)
Subject: [SciPy-Dev] Sources to conference.scipy.org
References: <CA+WonSRH464_xucnUzBy4yaUQuA80Dzv-s6+Z4pmfGVe1S=Q9A@mail.gmail.com>
Message-ID: <loom.20131011T113919-219@post.gmane.org>

Andy Ray Terrel <andy.terrel <at> gmail.com> writes:
[clip]
> To that end, it has become apparent that in moving
> servers and other rearranging of the conference
> in the last few years, the sphinx source that generates
> the conference.scipy.org landing page has been lost
> (at least to me and the Enthought staff I've been in touch with).
> 
> Does anyone have these sources somewhere know where to get them?

I think it's just the one HTML page, so it's probably not worth
spending time on trying to find the sources.

A better solution would be to just scrap the conferences.scipy.org
front page completely, and add a new "Conferences" page to the
http://scipy.org/ site.

(Also, please update the Euroscipy part, too.)

-- 
Pauli Virtanen



From andy.terrel at gmail.com  Fri Oct 11 10:09:08 2013
From: andy.terrel at gmail.com (Andy Ray Terrel)
Date: Fri, 11 Oct 2013 09:09:08 -0500
Subject: [SciPy-Dev] Sources to conference.scipy.org
In-Reply-To: <loom.20131011T113919-219@post.gmane.org>
References: <CA+WonSRH464_xucnUzBy4yaUQuA80Dzv-s6+Z4pmfGVe1S=Q9A@mail.gmail.com>
	<loom.20131011T113919-219@post.gmane.org>
Message-ID: <CA+WonSQfYhsA59gNfO2JsUXUSkOQnWCgkDn-5EXYr5raX0bnUg@mail.gmail.com>

On Fri, Oct 11, 2013 at 4:41 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Andy Ray Terrel <andy.terrel <at> gmail.com> writes:
> [clip]
> > To that end, it has become apparent that in moving
> > servers and other rearranging of the conference
> > in the last few years, the sphinx source that generates
> > the conference.scipy.org landing page has been lost
> > (at least to me and the Enthought staff I've been in touch with).
> >
> > Does anyone have these sources somewhere know where to get them?
>
> I think it's just the one HTML page, so it's probably not worth
> spending time on trying to find the sources.
>

It's more than just one page.  It's all the links to the old coferences and
other things on the server.


>
> A better solution would be to just scrap the conferences.scipy.org
> front page completely, and add a new "Conferences" page to the
> http://scipy.org/ site.


> (Also, please update the Euroscipy part, too.)
>
>
That's a possibility, at least there the source would be maintained better
and folks could just submit pull requests for their own conference.  Who do
I talk to about EuroSciPy updates?


-- Andy

--
> Pauli Virtanen
>
> _______________________________________________
> 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/20131011/1b9a46c9/attachment.html>

From ognen at enthought.com  Fri Oct 11 11:41:17 2013
From: ognen at enthought.com (Ognen Duzlevski)
Date: Fri, 11 Oct 2013 10:41:17 -0500
Subject: [SciPy-Dev] Sources to conference.scipy.org
In-Reply-To: <CA+WonSRH464_xucnUzBy4yaUQuA80Dzv-s6+Z4pmfGVe1S=Q9A@mail.gmail.com>
References: <CA+WonSRH464_xucnUzBy4yaUQuA80Dzv-s6+Z4pmfGVe1S=Q9A@mail.gmail.com>
Message-ID: <CAA6U3WB4Sba4LncCZ=Bf2RihB0dg7yqcYC7_cCgHHosz-m8LKA@mail.gmail.com>

The "old" conference.scipy.org machine is still online. What am I looking
for? :-)
Ognen


On Thu, Oct 10, 2013 at 10:08 AM, Andy Ray Terrel <andy.terrel at gmail.com>wrote:

> Hello all,
>
> In effort to support the providence of our website and conference
> technologies, I've started putting everything in the github org:
> https://github.com/scipy-conference
>
> To that end, it has become apparent that in moving servers and other
> rearranging of the conference in the last few years, the sphinx source that
> generates the conference.scipy.org landing page has been lost (at least
> to me and the Enthought staff I've been in touch with).
>
> Does anyone have these sources somewhere know where to get them?
>
> -- Andy
>
> _______________________________________________
> 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/20131011/08564964/attachment.html>

From charlesnwoods at gmail.com  Fri Oct 11 11:41:53 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 11 Oct 2013 09:41:53 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <loom.20131011T112317-488@post.gmane.org>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
Message-ID: <CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>

On Fri, Oct 11, 2013 at 3:38 AM, Pauli Virtanen <pav at iki.fi> wrote:

> The quad callback would be `double f(double *a, void *params)`.
> The call signatures of course depends on the routine. Perhaps it should
> also be standardized.
>
> What I mean here is that while in Python, you can do `f(arg1, arg2, *a,
> **kw)`
> there's no way in C to make calls with `*a` and `**kw` without on-the-fly
> code generation. Which we don't want to do --- too complicated.
> The best option is to keep it simple.
>

All right, I have a better handle on what you're describing now.


> [clip]
> > I guess I thought that we were talking about replacing most of the
> > code in quad(). As far as I can tell, the integrate library uses the
> > C/Python API to communicate with the underlying Quadpack code. One of
> > the main difficulties I see is that the C/Python API is fairly complex,
> > and therefore the wrapper code is difficult to modify. I'd be a lot
> > happier if this could be done with one of the simpler tools
> > (probably Cython, since that seems to be the way the community is
> > leaning), so that the interface doesn't become a magic black box.
>
> The quadpack wrappers could probably be done with f2py without too
> many problems.
>

It was mentioned on here a few weeks ago that there were problems
associated with using new Fortran code, particularly with  mingw. Looking
over the build instructions for mingw, I would assume that the difficulty
is the g77 compiler, which would limit all new fortran code to Fortran77.
Is that correct? Are there any other difficulties to be aware of?

Nathan Woods
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131011/5d411ceb/attachment.html>

From larson.eric.d at gmail.com  Fri Oct 11 13:06:12 2013
From: larson.eric.d at gmail.com (Eric Larson)
Date: Fri, 11 Oct 2013 10:06:12 -0700
Subject: [SciPy-Dev] Dijkstra distances with limit
Message-ID: <CAGu2niXPFMzDDJwDNR6_ZayFUFCXAzv3ZHCuteXcGkq3HvWjWA@mail.gmail.com>

Hello,

I'm doing some calculations of Dijkstra distances on a large surface
(>100,000 nodes) between a certain subset of nodes of interest (~10,000).
Moreover, I'm only interested in finding pairs of points that are within a
certain (relatively small) distance of one another.

The current `sparse.csgraph.dijkstra` implementation allows me to get the
distances between all 10,000 points of interest, which is helpful. However,
this is many orders of magnitude slower than it would be if I limited the
search to just those distances within my small limit of interest (which is
a couple orders of magnitude smaller than the longest distance). While the
package `networkx` has this feature using the argument `cutoff`, it is not
written in C and suffers performance-wise compared to the Cython
implementation in Scipy.

It seems like it would be fairly straightforward to modify `dijkstra` and
the Cython code (`_dijkstra_directed` and `_dijkstra_undirected`) in
`_shortest_path.pyx` to take an argument like `max_dist` that limits how
large a distance may be used. I'd be happy to do this, assuming this is an
acceptable new feature. Thoughts?

Cheers,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131011/259d5557/attachment.html>

From charlesnwoods at gmail.com  Fri Oct 11 19:52:19 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 11 Oct 2013 17:52:19 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
Message-ID: <CAAYHtCQgkCnYZ6j2x6FSthgMOMHPk7sUQdRP0V0Nyokx8ozrXg@mail.gmail.com>

I wanted to put together some of my ideas about this topic in a way that I
hope makes sense. I'm most familiar with the scipy.integrate library, but I
suspect that the same ideas will hold true with any part of scipy that
wraps any part of SLATEC or another F77 library. Please chime in with
comments about this.

The original question was, "How can a scipy user reduce the number of
Python callbacks in evaluating a scipy library function?" The motivation
for such a question is, naturally, improved performance, especially in a
recursive function such as scipy.integrate.nquad.

One approach, prototyped a few years ago, is to allow the user to provide a
Ctypes pointer instead of a Python function, which can then be called
directly by the underlying code without any need for callbacks. This idea
seems quite sound, yet it was limited by the underlying structure of the
Quadpack library, which does not allow for multivariate functions. It was
also added long after the original interface to Quadpack was written, and
seems to have been somewhat brittle and difficult to extend, and it was not
easy for the user to access.

It seems that the issue has to main parts. First, what is the best way to
expand the capabilities of the library within the constraints of the
underlying SLATEC code? For scipy.integrate, this means, "How can I write a
multivariate function, and still make it fit through Quadpack's interface?"
Second, what can the user do to bypass the translation layer to avoid
Python callbacks?

In my opinion, the best way to solve the first problem is to take advantage
of the OOP programming style. Functional programming, as used in SLATEC and
much of SciPy, is expressly designed to prevent the passing of information
around the program through anything other than the functional interface. In
FP, f(x) cannot depend on anything other than x, and if it depends on x and
y, then it absolutely must be written f(x,y). The current implementation
uses global variables to cheat around this restriction, and pass y in
through the back door, as it were. A perhaps safer alternative is to define
f as a bound method to an object, and use object variables instead of
global variables to pass the y,z,... to the function, leaving the interface
as f(x), just as Quadpack wants it. There's an example of this in
scipy.integrate.nquad, if anyone is interested. This could be fairly easily
and safely implemented in Fortran 2003, but that is not as widely supported
as I think scipy needs. That leaves either C, or C++.

The second problem is much more tricky, because it's a user-facing problem.
What do we want a user to do, when he/she wants to speed up the
(integration) of their function? Do we want the user to write their
function using Cython? Do we want them to compile their function separately
and wrap it with Ctypes? Do we use f2py? Do we support all three? The only
one of these I've used was f2py.compile, so any insight is appreciated
here. Regardless, whatever comes out the back end needs to be passed to
compiled, probably C, code for some processing before being handed off to
the F77 library.

So there you have it. I think a compiled wrapper should be placed around
the Quadpack library that uses object data to handle multivariate
functions. This then becomes the point of entry for Python calls to the
library, and allows the user to specify the function
f(x0,x1,...,xn;t0,t1,...,tm) they want to integrate, without relying on
global variables, code generation, or modifying the library. The same kind
of wrapper could be used generally, as it could have a standard interface.

Comments welcome.

Nathan Woods



On Fri, Oct 11, 2013 at 9:41 AM, Nathan Woods <charlesnwoods at gmail.com>wrote:

>
>
>
> On Fri, Oct 11, 2013 at 3:38 AM, Pauli Virtanen <pav at iki.fi> wrote:
>
>> The quad callback would be `double f(double *a, void *params)`.
>> The call signatures of course depends on the routine. Perhaps it should
>> also be standardized.
>>
>> What I mean here is that while in Python, you can do `f(arg1, arg2, *a,
>> **kw)`
>> there's no way in C to make calls with `*a` and `**kw` without on-the-fly
>> code generation. Which we don't want to do --- too complicated.
>> The best option is to keep it simple.
>>
>
> All right, I have a better handle on what you're describing now.
>
>
>> [clip]
>> > I guess I thought that we were talking about replacing most of the
>> > code in quad(). As far as I can tell, the integrate library uses the
>> > C/Python API to communicate with the underlying Quadpack code. One of
>> > the main difficulties I see is that the C/Python API is fairly complex,
>> > and therefore the wrapper code is difficult to modify. I'd be a lot
>> > happier if this could be done with one of the simpler tools
>> > (probably Cython, since that seems to be the way the community is
>> > leaning), so that the interface doesn't become a magic black box.
>>
>> The quadpack wrappers could probably be done with f2py without too
>> many problems.
>>
>
> It was mentioned on here a few weeks ago that there were problems
> associated with using new Fortran code, particularly with  mingw. Looking
> over the build instructions for mingw, I would assume that the difficulty
> is the g77 compiler, which would limit all new fortran code to Fortran77.
> Is that correct? Are there any other difficulties to be aware of?
>
> Nathan Woods
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131011/2fe06de7/attachment.html>

From ralf.gommers at gmail.com  Sat Oct 12 01:17:17 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 12 Oct 2013 07:17:17 +0200
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
Message-ID: <CABL7CQiLNJtZyrEqF1Q7GpAyfPvMo=w5cEF-vy-O76Phe7CJQQ@mail.gmail.com>

On Fri, Oct 11, 2013 at 5:41 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:

>
>
>
> On Fri, Oct 11, 2013 at 3:38 AM, Pauli Virtanen <pav at iki.fi> wrote:
>
>> The quad callback would be `double f(double *a, void *params)`.
>> The call signatures of course depends on the routine. Perhaps it should
>> also be standardized.
>>
>> What I mean here is that while in Python, you can do `f(arg1, arg2, *a,
>> **kw)`
>> there's no way in C to make calls with `*a` and `**kw` without on-the-fly
>> code generation. Which we don't want to do --- too complicated.
>> The best option is to keep it simple.
>>
>
> All right, I have a better handle on what you're describing now.
>
>
>> [clip]
>> > I guess I thought that we were talking about replacing most of the
>> > code in quad(). As far as I can tell, the integrate library uses the
>> > C/Python API to communicate with the underlying Quadpack code. One of
>> > the main difficulties I see is that the C/Python API is fairly complex,
>> > and therefore the wrapper code is difficult to modify. I'd be a lot
>> > happier if this could be done with one of the simpler tools
>> > (probably Cython, since that seems to be the way the community is
>> > leaning), so that the interface doesn't become a magic black box.
>>
>> The quadpack wrappers could probably be done with f2py without too
>> many problems.
>>
>
> It was mentioned on here a few weeks ago that there were problems
> associated with using new Fortran code, particularly with  mingw. Looking
> over the build instructions for mingw, I would assume that the difficulty
> is the g77 compiler, which would limit all new fortran code to Fortran77.
> Is that correct? Are there any other difficulties to be aware of?
>

That's correct. I'm hoping we can drop g77 in the near future, but for the
0.13 release we still depend on it. We should have one release with recent
gfortran without issues before dropping g77 imho.

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

From ralf.gommers at gmail.com  Sat Oct 12 01:22:46 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 12 Oct 2013 07:22:46 +0200
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 release candidate 1
Message-ID: <CABL7CQjm+sQhT=zNoj8fb0WxfPePQJPpU5Lw_ncj0j2yfZM54A@mail.gmail.com>

Hi all,

Hi all,

I'm happy to announce the availability of the first release candidate of
Scipy 0.13.0. Please try this RC and report any issues on the scipy-dev
mailing list.

Source tarballs, binaries and release notes can be found at
http://sourceforge.net/projects/scipy/files/scipy/0.13.0rc1/.

Thanks to everyone who helped test and fix the beta release. This is
shaping up to be a very solid release.

Cheers,
Ralf



==========================
SciPy 0.13.0 Release Notes
==========================

.. note:: Scipy 0.13.0 is not released yet!

.. contents::

SciPy 0.13.0 is the culmination of 7 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and
better documentation.  There have been a number of deprecations and
API changes in this release, which are documented below.  All users
are encouraged to upgrade to this release, as there are a large number
of bug-fixes and optimizations.  Moreover, our development attention
will now shift to bug-fix releases on the 0.13.x branch, and on adding
new features on the master branch.

This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater.


New features
============

``scipy.integrate`` improvements
--------------------------------

N-dimensional numerical integration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A new function `scipy.integrate.nquad`, which provides N-dimensional
integration functionality with a more flexible interface than ``dblquad``
and
``tplquad``, has been added.

``dopri*`` improvements
^^^^^^^^^^^^^^^^^^^^^^^

The intermediate results from the ``dopri`` family of ODE solvers can now be
accessed by a *solout* callback function.


``scipy.linalg`` improvements
-----------------------------

Interpolative decompositions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Scipy now includes a new module `scipy.linalg.interpolative`
containing routines for computing interpolative matrix decompositions
(ID). This feature is based on the ID software package by
P.G. Martinsson, V. Rokhlin, Y. Shkolnisky, and M. Tygert, previously
adapted for Python in the PymatrixId package by K.L. Ho.

Polar decomposition
^^^^^^^^^^^^^^^^^^^

A new function `scipy.linalg.polar`, to compute the polar decomposition
of a matrix, was added.

BLAS level 3 functions
^^^^^^^^^^^^^^^^^^^^^^

The BLAS functions ``symm``, ``syrk``, ``syr2k``, ``hemm``, ``herk`` and
``her2k`` are now wrapped in `scipy.linalg`.

Matrix functions
^^^^^^^^^^^^^^^^

Several matrix function algorithms have been implemented or updated
following
detailed descriptions in recent papers of Nick Higham and his co-authors.
These include the matrix square root (``sqrtm``), the matrix logarithm
(``logm``), the matrix exponential (``expm``) and its Frechet derivative
(``expm_frechet``), and fractional matrix powers
(``fractional_matrix_power``).


``scipy.optimize`` improvements
-------------------------------

Trust-region unconstrained minimization algorithms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The ``minimize`` function gained two trust-region solvers for unconstrained
minimization: ``dogleg`` and ``trust-ncg``.


``scipy.sparse`` improvements
-----------------------------

Boolean comparisons and sparse matrices
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

All sparse matrix types now support boolean data, and boolean operations.
Two
sparse matrices `A` and `B` can be compared in all the expected ways `A <
B`,
`A >= B`, `A != B`, producing similar results as dense Numpy arrays.
Comparisons with dense matrices and scalars are also supported.

CSR and CSC fancy indexing
^^^^^^^^^^^^^^^^^^^^^^^^^^

Compressed sparse row and column sparse matrix types now support fancy
indexing
with boolean matrices, slices, and lists. So where A is a (CSC or CSR)
sparse
matrix, you can do things like::

    >>> A[A > 0.5] = 1  # since Boolean sparse matrices work
    >>> A[:2, :3] = 2
    >>> A[[1,2], 2] = 3


``scipy.sparse.linalg`` improvements
------------------------------------

The new function ``onenormest`` provides a lower bound of the 1-norm of a
linear operator and has been implemented according to Higham and Tisseur
(2000).  This function is not only useful for sparse matrices, but can also
be
used to estimate the norm of products or powers of dense matrices without
explictly building the intermediate matrix.

The multiplicative action of the matrix exponential of a linear operator
(``expm_multiply``) has been implemented following the description in
Al-Mohy
and Higham (2011).

Abstract linear operators (`scipy.sparse.linalg.LinearOperator`) can now be
multiplied, added to each other, and exponentiated, producing new linear
operators. This enables easier construction of composite linear operations.


``scipy.spatial`` improvements
------------------------------

The vertices of a `ConvexHull` can now be accessed via the `vertices`
attribute,
which gives proper orientation in 2-D.


``scipy.signal`` improvements
-----------------------------

The cosine window function `scipy.signal.cosine` was added.


``scipy.special`` improvements
------------------------------

New functions `scipy.special.xlogy` and `scipy.special.xlog1py` were added.
These functions can simplify and speed up code that has to calculate
``x * log(y)`` and give 0 when ``x == 0``.


``scipy.io`` improvements
-------------------------

Unformatted Fortran file reader
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The new class `scipy.io.FortranFile` facilitates reading unformatted
sequential files written by Fortran code.

``scipy.io.wavfile`` enhancements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

`scipy.io.wavfile.write` now accepts a file buffer. Previously it only
accepted a filename.

`scipy.io.wavfile.read` and `scipy.io.wavfile.write` can now handle floating
point WAV files.


``scipy.interpolate`` improvements
----------------------------------

B-spline derivatives and antiderivatives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

`scipy.interpolate.splder` and `scipy.interpolate.splantider` functions
for computing B-splines that represent derivatives and antiderivatives
of B-splines were added.  These functions are also available in the
class-based FITPACK interface as ``UnivariateSpline.derivative`` and
``UnivariateSpline.antiderivative``.


``scipy.stats`` improvements
----------------------------

Distributions now allow using keyword parameters in addition to
positional parameters in all methods.

The function `scipy.stats.power_divergence` has been added for the
Cressie-Read power divergence statistic and goodness of fit test.
Included in this family of statistics is the "G-test"
(http://en.wikipedia.org/wiki/G-test).

`scipy.stats.mood` now accepts multidimensional input.

An option was added to `scipy.stats.wilcoxon` for continuity correction.

`scipy.stats.chisquare` now has an `axis` argument.

`scipy.stats.mstats.chisquare` now has `axis` and `ddof` arguments.


Deprecated features
===================

``expm2`` and ``expm3``
-----------------------

The matrix exponential functions `scipy.linalg.expm2` and
`scipy.linalg.expm3`
are deprecated. All users should use the numerically more robust
`scipy.linalg.expm` function instead.

``scipy.stats`` functions
-------------------------

`scipy.stats.oneway` is deprecated; `scipy.stats.f_oneway` should be used
instead.

`scipy.stats.glm` is deprecated.  `scipy.stats.ttest_ind` is an equivalent
function; more full-featured general (and generalized) linear model
implementations can be found in statsmodels.

`scipy.stats.cmedian` is deprecated; ``numpy.median`` should be used
instead.


Backwards incompatible changes
==============================

LIL matrix assignment
---------------------
Assigning values to LIL matrices with two index arrays now works similarly
as
assigning into ndarrays::

    >>> x = lil_matrix((3, 3))
    >>> x[[0,1,2],[0,1,2]]=[0,1,2]
    >>> x.todense()
    matrix([[ 0.,  0.,  0.],
            [ 0.,  1.,  0.],
            [ 0.,  0.,  2.]])

rather than giving the result::

    >>> x.todense()
    matrix([[ 0.,  1.,  2.],
            [ 0.,  1.,  2.],
            [ 0.,  1.,  2.]])

Users relying on the previous behavior will need to revisit their code.
The previous behavior is obtained by ``x[numpy.ix_([0,1,2],[0,1,2])] = ...`.


Deprecated ``radon`` function removed
-------------------------------------

The ``misc.radon`` function, which was deprecated in scipy 0.11.0, has been
removed.  Users can find a more full-featured ``radon`` function in
scikit-image.


Removed deprecated keywords ``xa`` and ``xb`` from ``stats.distributions``
--------------------------------------------------------------------------

The keywords ``xa`` and ``xb``, which were deprecated since 0.11.0, have
been removed from the distributions in ``scipy.stats``.

Changes to MATLAB file readers / writers
----------------------------------------

The major change is that 1D arrays in numpy now become row vectors (shape
1, N)
when saved to a MATLAB 5 format file.  Previously 1D arrays saved as column
vectors (N, 1).  This is to harmonize the behavior of writing MATLAB 4 and 5
formats, and adapt to the defaults of numpy and MATLAB - for example
``np.atleast_2d`` returns 1D arrays as row vectors.

Trying to save arrays of greater than 2 dimensions in MATLAB 4 format now
raises
an error instead of silently reshaping the array as 2D.

``scipy.io.loadmat('afile')`` used to look for `afile` on the Python system
path
(``sys.path``); now ``loadmat`` only looks in the current directory for a
relative path filename.

Other changes
=============

Security fix: ``scipy.weave`` previously used temporary directories in an
insecure manner under certain circumstances.

Cython is now required to build *unreleased* versions of scipy.
The C files generated from Cython sources are not included in the git repo
anymore.  They are however still shipped in source releases.

The code base received a fairly large PEP8 cleanup.  A ``tox pep8``
command has been added; new code should pass this test command.

Authors
=======

This release contains work by the following people (contributed at least
one patch to this release, names in alphabetical order):

* Jorge Ca?ardo Alastuey +
* Tom Aldcroft +
* Max Bolingbroke +
* Joseph Jon Booker +
* Fran?ois Boulogne
* Matthew Brett
* Christian Brodbeck +
* Per Brodtkorb +
* Christian Brueffer +
* Lars Buitinck
* Evgeni Burovski +
* Tim Cera
* Lawrence Chan +
* David Cournapeau
* Draz?en Luc?anin +
* Alexander J. Dunlap +
* endolith
* Andr? Gaul +
* Christoph Gohlke
* Ralf Gommers
* Alex Griffing +
* Blake Griffith +
* Charles Harris
* Bob Helmbold +
* Andreas Hilboll
* Kat Huang +
* Oleksandr (Sasha) Huziy +
* Gert-Ludwig Ingold +
* Thouis (Ray) Jones
* Juan Luis Cano Rodr?guez +
* Robert Kern
* Andreas Kloeckner +
* Sytse Knypstra +
* Gustav Larsson +
* Denis Laxalde
* Christopher Lee
* Tim Leslie
* Wendy Liu +
* Clemens Novak +
* Takuya Oshima +
* Josef Perktold
* Illia Polosukhin +
* Przemek Porebski +
* Steve Richardson +
* Branden Rolston +
* Skipper Seabold
* Fazlul Shahriar
* Leo Singer +
* Rohit Sivaprasad +
* Daniel B. Smith +
* Julian Taylor
* Louis Thibault +
* Tomas Tomecek +
* John Travers
* Richard Tsai +
* Jacob Vanderplas
* Patrick Varilly
* Pauli Virtanen
* Stefan van der Walt
* Warren Weckesser
* Pedro Werneck +
* Nils Werner +
* Michael Wimmer +
* Nathan Woods +
* Tony S. Yu +

A total of 65 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131012/eab9fb9a/attachment.html>

From jakevdp at cs.washington.edu  Sat Oct 12 04:26:41 2013
From: jakevdp at cs.washington.edu (Jacob Vanderplas)
Date: Sat, 12 Oct 2013 01:26:41 -0700
Subject: [SciPy-Dev] Dijkstra distances with limit
In-Reply-To: <CAGu2niXPFMzDDJwDNR6_ZayFUFCXAzv3ZHCuteXcGkq3HvWjWA@mail.gmail.com>
References: <CAGu2niXPFMzDDJwDNR6_ZayFUFCXAzv3ZHCuteXcGkq3HvWjWA@mail.gmail.com>
Message-ID: <CACpqBg2E8zDj3THyoirFDL0bddBCtX7ViBmg=qOYk_koVfhing@mail.gmail.com>

Hi Eric,
I think that this would be a very useful enhancement.  I was curious about
how Dijkstra's algorithm could be modified to allow this: I searched around
and it seems to be fairly straightforward (see, e.g.
http://rmandvikar.blogspot.hu/2008/07/dijkstras-algorithm.html).  I'll look
out for your pull request!
   Jake

On Fri, Oct 11, 2013 at 10:06 AM, Eric Larson <larson.eric.d at gmail.com>wrote:

> Hello,
>
> I'm doing some calculations of Dijkstra distances on a large surface
> (>100,000 nodes) between a certain subset of nodes of interest (~10,000).
> Moreover, I'm only interested in finding pairs of points that are within a
> certain (relatively small) distance of one another.
>
> The current `sparse.csgraph.dijkstra` implementation allows me to get the
> distances between all 10,000 points of interest, which is helpful. However,
> this is many orders of magnitude slower than it would be if I limited the
> search to just those distances within my small limit of interest (which is
> a couple orders of magnitude smaller than the longest distance). While the
> package `networkx` has this feature using the argument `cutoff`, it is not
> written in C and suffers performance-wise compared to the Cython
> implementation in Scipy.
>
> It seems like it would be fairly straightforward to modify `dijkstra` and
> the Cython code (`_dijkstra_directed` and `_dijkstra_undirected`) in
> `_shortest_path.pyx` to take an argument like `max_dist` that limits how
> large a distance may be used. I'd be happy to do this, assuming this is an
> acceptable new feature. Thoughts?
>
> Cheers,
> Eric
>
>
> _______________________________________________
> 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/20131012/45a5663e/attachment.html>

From howarth at bromo.med.uc.edu  Sat Oct 12 10:10:29 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sat, 12 Oct 2013 10:10:29 -0400
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 release candidate 1
In-Reply-To: <CABL7CQjm+sQhT=zNoj8fb0WxfPePQJPpU5Lw_ncj0j2yfZM54A@mail.gmail.com>
References: <CABL7CQjm+sQhT=zNoj8fb0WxfPePQJPpU5Lw_ncj0j2yfZM54A@mail.gmail.com>
Message-ID: <20131012141028.GA25492@bromo.med.uc.edu>

On Sat, Oct 12, 2013 at 07:22:46AM +0200, Ralf Gommers wrote:
> Hi all,
> 
> Hi all,
> 
> I'm happy to announce the availability of the first release candidate of
> Scipy 0.13.0. Please try this RC and report any issues on the scipy-dev
> mailing list.
> 
> Source tarballs, binaries and release notes can be found at
> http://sourceforge.net/projects/scipy/files/scipy/0.13.0rc1/.
> 
> Thanks to everyone who helped test and fix the beta release. This is
> shaping up to be a very solid release.
> 
> Cheers,
> Ralf

Ralf,
    The build of the new scipy 0.13.0rc1 still produces failures on x86_64-apple-darwin12
against numpy 0.18.0rc1 with both built against Xcode 5.0's clang and FSF gfortran 4.8.1.
These are...

Running unit tests for scipy
NumPy version 1.8.0rc1
NumPy is installed in /sw/lib/python2.7/site-packages/numpy
SciPy version 0.13.0rc1
SciPy is installed in /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy
Python version 2.7.5 (default, Oct  9 2013, 13:51:44) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.75)]
nose version 1.3.0
/sw/lib/python2.7/site-packages/numpy/lib/utils.py:134: DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.blas` instead!
  warnings.warn(depdoc, DeprecationWarning)
/sw/lib/python2.7/site-packages/numpy/lib/utils.py:134: DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg.lapack` instead!
  warnings.warn(depdoc, DeprecationWarning)
..............................................................................................................................................................................................................................K..................................................................................................................K........................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/integrate/quadrature.py:67: RuntimeWarning: invalid value encountered in multiply
  return (b-a)/2.0*sum(w*func(y,*args),0), None
.............................................................K..K......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSS......SSSSSS......SSSS......................................................................................0-th dimension must be fixed to 3 but got 15
..0-th dimension must be fixed to 3 but got 5
.......................S..........K..............................................................................................................................................................................................................................................................................................K....................................................................................................................................................................................F..K...../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/_matfuncs_inv_ssq.py:817: DeprecationWarning: Implicitly casting between incompatible kinds. In a future numpy release, this will raise an error. Use casting="unsafe" if this is intentional.
  U += solve_triangular(ident + beta*R, alpha*R)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/_matfuncs_inv_ssq.py:817: ComplexWarning: Casting complex values to real discards the imaginary part
  U += solve_triangular(ident + beta*R, alpha*R)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/_matfuncs_inv_ssq.py:813: RuntimeWarning: invalid value encountered in multiply
  weights = 0.5 * weights
E..................F.....................................................SSSSSS............S............................................................./sw/lib/python2.7/site-packages/numpy/core/_methods.py:55: RuntimeWarning: Mean of empty slice.
  warnings.warn("Mean of empty slice.", RuntimeWarning)
....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K................................................................./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py:183: ComplexWarning: Casting complex values to real discards the imaginary part
  num[k] = poly(A - dot(B, Ck)) + (D[k] - 1) * den
...F.../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/dltisys.py:113: ComplexWarning: Casting complex values to real discards the imaginary part
  xout[i+1,:] = np.dot(a, xout[i,:]) + np.dot(b, u_dt[i,:])
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/dltisys.py:114: ComplexWarning: Casting complex values to real discards the imaginary part
  yout[i,:] = np.dot(c, xout[i,:]) + np.dot(d, u_dt[i,:])
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/dltisys.py:118: ComplexWarning: Casting complex values to real discards the imaginary part
  np.dot(d, u_dt[out_samples-1,:])
F....F.................................................................E...F..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SS....................SSSSSSSSSS.......KKKSSS.S....KKK......S..K...KKK...KKK...............S..............SSSSS..SSSS.................................SS...............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK...........SSS.S..............SSSSS..SSSS.................................................................................KKKK..........KKKK...............KKKK....KKKK.....................................................................................................................................................................................................................................................................................................................................................................................................................KKKK..........KKKK...............KKKK....KKKK......................................................................................................................................................................................................................................................................................................................................................................SS............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK......S....SSS.S..............SSSSS..SSSS...............................K..S.SSS..........SSS.KKKKSKSSKS....SSSKKKSSS...SSSKKK..........SSSKKKSSSKKK......S.....SSS.S.........K.....KSSS...KSKS................................................SSS................SSSKKK......SSSKKK...........SSSKKK...SSSKKK......S....SSS............K...............................................................................................................................................................................................................................................................................................................................................................................................SSS..................................................................................................................................................................................................................................................................................................................................................................................................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:221: RuntimeWarning: overflow encountered in cdouble_scalars
  wfunc = lambda x: (1-x)**alpha * (1+x)**beta
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:221: RuntimeWarning: invalid value encountered in cdouble_scalars
  wfunc = lambda x: (1-x)**alpha * (1+x)**beta
F........................................................................./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:244: RuntimeWarning: invalid value encountered in greater
  pinf_x = np.isinf(x) & (x > 0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:245: RuntimeWarning: invalid value encountered in greater
  pinf_y = np.isinf(y) & (y > 0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:246: RuntimeWarning: invalid value encountered in less
  minf_x = np.isinf(x) & (x < 0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:247: RuntimeWarning: invalid value encountered in less
  minf_y = np.isinf(y) & (y < 0)
........................................................................................................................................................................................................................................./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:341: RuntimeWarning: overflow encountered in cdouble_scalars
  wfunc = lambda x: exp(-x) * x**alpha
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:341: RuntimeWarning: invalid value encountered in cdouble_scalars
  wfunc = lambda x: exp(-x) * x**alpha
F/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:172: RuntimeWarning: overflow encountered in square
  answer.append((mu*v[0]**2)[sortind])
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:172: RuntimeWarning: invalid value encountered in multiply
  answer.append((mu*v[0]**2)[sortind])
F./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:116: RuntimeWarning: invalid value encountered in cdouble_scalars
  equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
F........................................................................................................................................................................SSSSSSSSFFFFFF/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:417: RuntimeWarning: overflow encountered in exp
  wfunc = lambda x: exp(-x*x)
FFF/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:643: RuntimeWarning: overflow encountered in cdouble_scalars
  p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:643: RuntimeWarning: invalid value encountered in cdouble_scalars
  p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
F/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:532: RuntimeWarning: overflow encountered in cdouble_scalars
  wfunc = lambda x: 1.0/sqrt(1-x*x)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:532: RuntimeWarning: invalid value encountered in cdouble_scalars
  wfunc = lambda x: 1.0/sqrt(1-x*x)
F/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:116: RuntimeWarning: overflow encountered in cdouble_scalars
  equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
FEEE/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:461: RuntimeWarning: overflow encountered in cdouble_scalars
  wfunc = lambda x: exp(-x*x/4.0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:461: RuntimeWarning: invalid value encountered in cdouble_scalars
  wfunc = lambda x: exp(-x*x/4.0)
EEFFFF/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:286: RuntimeWarning: overflow encountered in cdouble_scalars
  wfunc = lambda x: (1.0-x)**(p-q) * (x)**(q-1.)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/orthogonal.py:286: RuntimeWarning: invalid value encountered in cdouble_scalars
  wfunc = lambda x: (1.0-x)**(p-q) * (x)**(q-1.)
EF.........................../sw/lib/python2.7/site-packages/numpy/core/_methods.py:77: RuntimeWarning: Degrees of freedom <= 0 for slice
  warnings.warn("Degrees of freedom <= 0 for slice", RuntimeWarning)
.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7208: RuntimeWarning: invalid value encountered in greater_equal
  return where(temp >= q, vals1, vals)
.............................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7584: RuntimeWarning: invalid value encountered in greater_equal
  return where((temp >= q), vals1, vals)
............................./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7357: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return (1-p)**(k-1) * p
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7357: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return (1-p)**(k-1) * p
..../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
............S..........................................................................................S...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K......................................................................................................
======================================================================
ERROR: test_logm_type_preservation_and_conversion (test_matfuncs.TestLogM)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_matfuncs.py", line 176, in test_logm_type_preservation_and_conversion
    A_logm, info = logm(A, disp=False)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/matfuncs.py", line 69, in logm
    F = scipy.linalg._matfuncs_inv_ssq.logm(A)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/_matfuncs_inv_ssq.py", line 891, in logm
    return _logm_triu(A)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/_matfuncs_inv_ssq.py", line 817, in _logm_triu
    U += solve_triangular(ident + beta*R, alpha*R)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/basic.py", line 155, in solve_triangular
    a1, b1 = map(np.asarray_chkfinite,(a,b))
  File "/sw/lib/python2.7/site-packages/numpy/lib/function_base.py", line 595, in asarray_chkfinite
    "array must not contain infs or NaNs")
ValueError: array must not contain infs or NaNs

======================================================================
ERROR: Test that bode() finds a reasonable frequency range.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_ltisys.py", line 338, in test_05
    w, mag, phase = bode(system, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 983, in bode
    w, y = freqresp(system, w=w, n=n)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/ltisys.py", line 1053, in freqresp
    w, h = freqs(sys.num.ravel(), sys.den, worN=worN)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 142, in freqs
    w = findfreqs(b, a, N)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/filter_design.py", line 70, in findfreqs
    1.5 * ez.imag)) + 0.5)
  File "/sw/lib/python2.7/site-packages/numpy/core/fromnumeric.py", line 2130, in amax
    out=out, keepdims=keepdims)
  File "/sw/lib/python2.7/site-packages/numpy/core/_methods.py", line 17, in _amax
    out=out, keepdims=keepdims)
ValueError: zero-size array to reduction operation maximum which has no identity

======================================================================
ERROR: test_orthogonal_eval.TestPolys.test_gegenbauer
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 93, in test_gegenbauer
    rtol=1e-7)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 220, in check
    got = eval_func_at_params(self.func)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 206, in eval_func_at_params
    got = func(*params)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 70, in polyfunc
    return func(*p)
TypeError: ufunc 'eval_gegenbauer' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

======================================================================
ERROR: test_orthogonal_eval.TestPolys.test_genlaguerre
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 137, in test_genlaguerre
    param_ranges=[(-0.99, 10)], x_range=[0, 100])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 220, in check
    got = eval_func_at_params(self.func)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 206, in eval_func_at_params
    got = func(*params)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 70, in polyfunc
    return func(*p)
TypeError: ufunc 'eval_genlaguerre' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

======================================================================
ERROR: test_orthogonal_eval.TestPolys.test_hermite
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 145, in test_hermite
    param_ranges=[], x_range=[-100, 100])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 220, in check
    got = eval_func_at_params(self.func)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 206, in eval_func_at_params
    got = func(*params)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 70, in polyfunc
    return func(*p)
TypeError: ufunc 'eval_hermite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

======================================================================
ERROR: test_orthogonal_eval.TestPolys.test_hermitenorm
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 149, in test_hermitenorm
    param_ranges=[], x_range=[-100, 100])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 220, in check
    got = eval_func_at_params(self.func)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 206, in eval_func_at_params
    got = func(*params)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 70, in polyfunc
    return func(*p)
TypeError: ufunc 'eval_hermitenorm' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

======================================================================
ERROR: test_orthogonal_eval.TestPolys.test_jacobi
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 83, in test_jacobi
    rtol=1e-5)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 220, in check
    got = eval_func_at_params(self.func)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 206, in eval_func_at_params
    got = func(*params)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 70, in polyfunc
    return func(*p)
TypeError: ufunc 'eval_jacobi' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

======================================================================
ERROR: test_orthogonal_eval.TestPolys.test_sh_jacobi
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 88, in test_sh_jacobi
    rtol=1e-5)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 220, in check
    got = eval_func_at_params(self.func)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 206, in eval_func_at_params
    got = func(*params)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 70, in polyfunc
    return func(*p)
TypeError: ufunc 'eval_sh_jacobi' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

======================================================================
FAIL: test_random_matrices_and_powers (test_matfuncs.TestFractionalMatrixPower)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_matfuncs.py", line 422, in test_random_matrices_and_powers
    assert_allclose(A_power, A_power_expm_logm)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 1181, in assert_allclose
    verbose=verbose, header=header)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=1e-07, atol=0

(mismatch 100.0%)
 x: array([[ 0.11206248-0.9490285j]])
 y: array([[ 0.15883625+2.13345471j]])

======================================================================
FAIL: test_cases (test_solvers.TestSolveDiscreteARE)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 132, in test_cases
    self.check_case(case[0], case[1], case[2], case[3])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 128, in check_case
    a.getH()*x*a-(a.getH()*x*b)*inv(r+b.getH()*x*b)*(b.getH()*x*a)+q-x, 0.0)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 100.0%)
 x: matrix([[-10357.80068892 -1.96967775e-10j,  15195.78532325 +1.77378189e+04j],
        [ 15195.78532325 -1.77378189e+04j, -52669.68595223 -8.76507755e-10j]])
 y: array(0.0)

======================================================================
FAIL: Test method='gbt' with alpha=0.25 for tf and zpk cases.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_cont2discrete.py", line 218, in test_gbt_with_sio_tf_and_zpk
    assert_allclose(dnum, c2dnum)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 1181, in assert_allclose
    verbose=verbose, header=header)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=1e-07, atol=0

(mismatch 100.0%)
 x: array([[ 0.7, -1.4]])
 y: array([[ 0. +3.72190840e-155j,  0. +2.32036032e+077j]])

======================================================================
FAIL: test_dimpulse (test_dltisys.TestDLTI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_dltisys.py", line 172, in test_dimpulse
    assert_array_almost_equal(yout[0].flatten(), yout_tfimpulse)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 33.3333333333%)
 x: array([ 0.,  1.,  2.])
 y: array([ 0.,  1., -1.])

======================================================================
FAIL: test_dstep (test_dltisys.TestDLTI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_dltisys.py", line 132, in test_dstep
    assert_array_almost_equal(yout[0].flatten(), yout_tfstep)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

(mismatch 33.3333333333%)
 x: array([ 0.,  1.,  3.])
 y: array([ 0.,  1.,  0.])

======================================================================
FAIL: test_ltisys.Test_freqresp.test_freq_range
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/signal/tests/test_ltisys.py", line 430, in test_freq_range
    assert_almost_equal(w, expected_w)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 454, in assert_almost_equal
    return assert_array_almost_equal(actual, desired, decimal, err_msg)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 7 decimals

(mismatch 90.0%)
 x: array([  0.1       ,   0.16681005,   0.27825594,   0.46415888,
         0.77426368,   1.29154967,   2.15443469,   3.59381366,
         5.9948425 ,  10.        ])
 y: array([  0.01      ,   0.02154435,   0.04641589,   0.1       ,
         0.21544347,   0.46415888,   1.        ,   2.15443469,
         4.64158883,  10.        ])

======================================================================
FAIL: test_jacobi (test_basic.TestBessel)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 1892, in test_jacobi
    assert_array_almost_equal(P1.c,array([a+b+2,a-b])/2.0,13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([ 3.387 +0.000e+000j, -6.774 +1.054e+232j])
 y: array([ 3.387,  0.685])

======================================================================
FAIL: test_genlaguerre (test_basic.TestLaguerre)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 2296, in test_genlaguerre
    assert_equal(lag1.c,[-1,k+1])
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 260, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 718, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

(mismatch 50.0%)
 x: array([-1. +0.000e+000j,  2. -3.111e+231j])
 y: array([-1.   ,  4.919])

======================================================================
FAIL: test_laguerre (test_basic.TestLaguerre)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 2283, in test_laguerre
    assert_array_almost_equal(lag1.c,[-1,1],13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([-1. +0.000e+00j,  2. -1.731e-77j])
 y: array([-1,  1])

======================================================================
FAIL: test_legendre (test_basic.TestLegendre)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 2311, in test_legendre
    assert_equal(leg1.c,[1,0])
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 260, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 718, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

(mismatch 50.0%)
 x: array([ 1. +0.000e+000j, -2. +3.111e+231j])
 y: array([1, 0])

======================================================================
FAIL: test_orthogonal.TestCall.test_call
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 269, in test_call
    assert_almost_equal(p(0.315), np.poly1d(p)(0.315), err_msg=pstr)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 450, in assert_almost_equal
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 7 decimals orth.jacobi(1,0.3,0.9)
 ACTUAL: 0.20399999999999996
 DESIRED: (-2.6960000000000002-2.0651892368036098e-231j)

======================================================================
FAIL: test_chebyc (test_orthogonal.TestCheby)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 26, in test_chebyc
    assert_array_almost_equal(C1.c,[1,0],13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 100.0%)
 x: array([-0.199+0.4j  ,  2.399-0.799j])
 y: array([1, 0])

======================================================================
FAIL: test_chebys (test_orthogonal.TestCheby)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 40, in test_chebys
    assert_array_almost_equal(S1.c,[1,0],13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 100.0%)
 x: array([ -1.857e-155 +4.310e-78j,   2.000e+000 -8.619e-78j])
 y: array([1, 0])

======================================================================
FAIL: test_chebyt (test_orthogonal.TestCheby)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 54, in test_chebyt
    assert_array_almost_equal(T1.c,[1,0],13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([ 1.+0.j   , -2.-2.004j])
 y: array([1, 0])

======================================================================
FAIL: test_chebyu (test_orthogonal.TestCheby)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 68, in test_chebyu
    assert_array_almost_equal(U1.c,[2,0],13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([ 2. +0.000e+00j, -4. +4.641e+77j])
 y: array([2, 0])

======================================================================
FAIL: test_gegenbauer (test_orthogonal.TestGegenbauer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 89, in test_gegenbauer
    assert_array_almost_equal(Ca1.c,array([2*a,0]),13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([  5.032 +0.000e+000j, -10.064 -6.495e-231j])
 y: array([ 5.032,  0.   ])

======================================================================
FAIL: test_hermite (test_orthogonal.TestHermite)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 108, in test_hermite
    assert_array_almost_equal(H1.c,[2,0],13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([ 2. +0.000e+00j, -4. +4.641e+77j])
 y: array([2, 0])

======================================================================
FAIL: test_hermitenorm (test_orthogonal.TestHermite)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 131, in test_hermitenorm
    assert_array_almost_equal(H1.c,he1.c,13)
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 811, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 644, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 13 decimals

(mismatch 50.0%)
 x: array([ 1. +0.000e+000j, -2. -1.495e-154j])
 y: array([ 1.000 +0.000e+00j, -2.828 +2.447e-77j])

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_chebyc
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 109, in test_chebyc
    param_ranges=[], x_range=[-2, 2])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 4
Max |rdiff|: 2
Bad results (9 out of 100) for the following points (in output 0):
                        (1+0j)                         (-2+0j) =>                        (-2+0j) !=    (2-1.7238701956054301e-77j)  (rdiff                            2.0)
                        (1+0j)         (0.7338517406885452+0j) =>        (0.7338517406885452+0j) !=     (2-5.456688118611782e-78j)  (rdiff             0.6330741296557274)
                        (1+0j)         (0.8508081079316008+0j) =>        (0.8508081079316008+0j) !=     (2-4.952644129420314e-78j)  (rdiff             0.5745959460341996)
                        (1+0j)        (-0.5189969808384203+0j) =>       (-0.5189969808384203+0j) !=    (2-1.0856059545218538e-77j)  (rdiff             1.2594984904192101)
                        (1+0j)        (0.24478474426249974+0j) =>       (0.24478474426249974+0j) !=     (2-7.564408165594599e-78j)  (rdiff             0.8776076278687501)
                        (1+0j)       (0.012332661231238884+0j) =>      (0.012332661231238884+0j) !=     (2-8.566201210204573e-78j)  (rdiff             0.9938336693843806)
                        (1+0j)         (-1.944926201637271+0j) =>        (-1.944926201637271+0j) !=    (2-1.7001351757163572e-77j)  (rdiff             1.9724631008186355)
                        (1+0j)         (1.0913064864494961+0j) =>        (1.0913064864494961+0j) !=    (2-3.9161741623742315e-78j)  (rdiff            0.45434675677525194)
                        (1+0j)         (1.5305647625444663+0j) =>        (1.5305647625444663+0j) !=    (2-2.0231135365413814e-78j)  (rdiff            0.23471761872776686)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_chebys
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 105, in test_chebys
    param_ranges=[], x_range=[-2, 2])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 3.94493
Max |rdiff|: 1.97246
Bad results (18 out of 100) for the following points (in output 0):
                            0j                         (-2+0j) =>                     (inf+nanj) !=                         (1+0j)  (rdiff                            0.0)
                        (1+0j)                         (-2+0j) =>                     (inf+nanj) !=   (2+1.4887633576344935e-154j)  (rdiff                            0.0)
                        (1+0j)         (0.7338517406885452+0j) =>        (0.7338517406885452+0j) !=   (2+4.7124878344889845e-155j)  (rdiff             0.6330741296557274)
                        (1+0j)         (0.8508081079316008+0j) =>        (0.8508081079316008+0j) !=    (2+4.277186949505224e-155j)  (rdiff             0.5745959460341996)
                        (1+0j)        (-0.5189969808384203+0j) =>       (-0.5189969808384203+0j) !=      (2+9.3754760076604e-155j)  (rdiff             1.2594984904192101)
                        (1+0j)        (0.24478474426249974+0j) =>       (0.24478474426249974+0j) !=    (2+6.532750393757624e-155j)  (rdiff             0.8776076278687501)
                        (1+0j)       (0.012332661231238884+0j) =>      (0.012332661231238884+0j) !=    (2+7.397915752814503e-155j)  (rdiff             0.9938336693843806)
                        (1+0j)         (-1.944926201637271+0j) =>        (-1.944926201637271+0j) !=    (2+1.468265394392448e-154j)  (rdiff             1.9724631008186355)
                        (1+0j)         (1.0913064864494961+0j) =>        (1.0913064864494961+0j) !=   (2+3.3820740157353426e-155j)  (rdiff            0.45434675677525194)
                        (1+0j)         (1.5305647625444663+0j) =>        (1.5305647625444663+0j) !=   (2+1.7471949507656264e-155j)  (rdiff            0.23471761872776686)
                        (2+0j)                         (-2+0j) =>                     (inf+nanj) !=        (3.0000000000000018+0j)  (rdiff                            0.0)
                        (3+0j)                         (-2+0j) =>                     (inf+nanj) !=        (-3.999999999999999+0j)  (rdiff                            0.0)
                        (4+0j)                         (-2+0j) =>                     (inf+nanj) !=         (5.000000000000003+0j)  (rdiff                            0.0)
                        (5+0j)                         (-2+0j) =>                     (inf+nanj) !=        (-6.000000000000107+0j)  (rdiff                            0.0)
                        (6+0j)                         (-2+0j) =>                     (inf+nanj) !=         (7.000000000000195+0j)  (rdiff                            0.0)
                        (7+0j)                         (-2+0j) =>                     (inf+nanj) !=        (-8.000000000000094+0j)  (rdiff                            0.0)
                        (8+0j)                         (-2+0j) =>                     (inf+nanj) !=         (9.000000000000357+0j)  (rdiff                            0.0)
                        (9+0j)                         (-2+0j) =>                     (inf+nanj) !=        (-9.999999999999911+0j)  (rdiff                            0.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_chebyt
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 97, in test_chebyt
    param_ranges=[], x_range=[-1, 1])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 2.68679e+154
Max |rdiff|: 1
Bad results (10 out of 100) for the following points (in output 0):
                        (1+0j)                         (-1+0j) =>                        (-1+0j) !=  (-3-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)                          (1+0j) =>                         (1+0j) !=  (-1-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.3669258703442726+0j) =>        (0.3669258703442726+0j) != (-1.6330741296557274-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.4254040539658004+0j) =>        (0.4254040539658004+0j) != (-1.5745959460341996-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)       (-0.25949849041921014+0j) =>      (-0.25949849041921014+0j) != (-2.25949849041921-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)        (0.12239237213124987+0j) =>       (0.12239237213124987+0j) != (-1.8776076278687501-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)       (0.006166330615619442+0j) =>      (0.006166330615619442+0j) != (-1.9938336693843806-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)        (-0.9724631008186355+0j) =>       (-0.9724631008186355+0j) != (-2.9724631008186355-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.5456532432247481+0j) =>        (0.5456532432247481+0j) != (-1.454346756775252-2.6867936932272034e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.7652823812722331+0j) =>        (0.7652823812722331+0j) != (-1.2347176187277669-2.6867936932272034e+154j)  (rdiff                            1.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_chebyu
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 101, in test_chebyu
    param_ranges=[], x_range=[-1, 1])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 5.37359e+154
Max |rdiff|: 1
Bad results (19 out of 100) for the following points (in output 0):
                            0j                         (-1+0j) =>                     (inf+nanj) !=                         (1+0j)  (rdiff                            0.0)
                        (1+0j)                         (-1+0j) =>                     (inf+nanj) !=   (-6-5.373587386454407e+154j)  (rdiff                            0.0)
                        (1+0j)                          (1+0j) =>                         (2+0j) !=   (-2-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.3669258703442726+0j) =>        (0.7338517406885452+0j) != (-3.266148259311455-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.4254040539658004+0j) =>        (0.8508081079316008+0j) != (-3.1491918920683992-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)       (-0.25949849041921014+0j) =>       (-0.5189969808384203+0j) != (-4.51899698083842-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)        (0.12239237213124987+0j) =>       (0.24478474426249974+0j) != (-3.7552152557375003-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)       (0.006166330615619442+0j) =>      (0.012332661231238884+0j) != (-3.987667338768761-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)        (-0.9724631008186355+0j) =>        (-1.944926201637271+0j) != (-5.944926201637271-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.5456532432247481+0j) =>        (1.0913064864494961+0j) != (-2.908693513550504-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.7652823812722331+0j) =>        (1.5305647625444663+0j) != (-2.4694352374555337-5.373587386454407e+154j)  (rdiff                            1.0)
                        (2+0j)                         (-1+0j) =>                     (inf+nanj) !=                         (3+0j)  (rdiff                            0.0)
                        (3+0j)                         (-1+0j) =>                     (inf+nanj) !=        (-3.999999999999999+0j)  (rdiff                            0.0)
                        (4+0j)                         (-1+0j) =>                     (inf+nanj) !=        (5.0000000000000115+0j)  (rdiff                            0.0)
                        (5+0j)                         (-1+0j) =>                     (inf+nanj) !=        (-6.000000000000044+0j)  (rdiff                            0.0)
                        (6+0j)                         (-1+0j) =>                     (inf+nanj) !=         (7.000000000000111+0j)  (rdiff                            0.0)
                        (7+0j)                         (-1+0j) =>                     (inf+nanj) !=        (-8.000000000000083+0j)  (rdiff                            0.0)
                        (8+0j)                         (-1+0j) =>                     (inf+nanj) !=         (9.000000000000327+0j)  (rdiff                            0.0)
                        (9+0j)                         (-1+0j) =>                     (inf+nanj) !=         (-9.99999999999974+0j)  (rdiff                            0.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_laguerre
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 141, in test_laguerre
    param_ranges=[], x_range=[0, 100])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 2.68679e+154
Max |rdiff|: 1
Bad results (10 out of 100) for the following points (in output 0):
                        (1+0j)                              0j =>                         (1+0j) !=     (2-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)                        (100+0j) =>                       (-99+0j) !=   (-98-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)          (68.34629351721362+0j) =>        (-67.34629351721362+0j) != (-66.34629351721362-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)          (71.27020269829002+0j) =>        (-70.27020269829002+0j) != (-69.27020269829002-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)         (37.025075479039494+0j) =>       (-36.025075479039494+0j) != (-35.025075479039494-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)           (56.1196186065625+0j) =>         (-55.1196186065625+0j) != (-54.1196186065625-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)          (50.30831653078097+0j) =>        (-49.30831653078097+0j) != (-48.30831653078097-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)         (1.3768449590682241+0j) =>      (-0.37684495906822413+0j) != (0.6231550409317759-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)           (77.2826621612374+0j) =>         (-76.2826621612374+0j) != (-75.2826621612374-2.68679369322713e+154j)  (rdiff                            1.0)
                        (1+0j)          (88.26411906361166+0j) =>        (-87.26411906361166+0j) != (-86.26411906361166-2.68679369322713e+154j)  (rdiff                            1.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_legendre
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 125, in test_legendre
    param_ranges=[], x_range=[-1, 1])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 2
Max |rdiff|: 2
Bad results (19 out of 100) for the following points (in output 0):
                            0j                         (-1+0j) =>                     (inf+nanj) !=                         (1+0j)  (rdiff                            0.0)
                        (1+0j)                         (-1+0j) =>                     (inf+nanj) !=   (-3-1.290743273001376e-231j)  (rdiff                            0.0)
                        (1+0j)                          (1+0j) =>                         (1+0j) !=   (-1-1.290743273001376e-231j)  (rdiff                            2.0)
                        (1+0j)         (0.3669258703442726+0j) =>        (0.3669258703442726+0j) != (-1.6330741296557274-1.290743273001376e-231j)  (rdiff             1.2246841485521696)
                        (1+0j)         (0.4254040539658004+0j) =>        (0.4254040539658004+0j) != (-1.5745959460341996-1.290743273001376e-231j)  (rdiff             1.2701671213095838)
                        (1+0j)       (-0.25949849041921014+0j) =>      (-0.25949849041921014+0j) != (-2.25949849041921-1.290743273001376e-231j)  (rdiff             0.8851521735820833)
                        (1+0j)        (0.12239237213124987+0j) =>       (0.12239237213124987+0j) != (-1.8776076278687501-1.290743273001376e-231j)  (rdiff             1.0651852763669138)
                        (1+0j)       (0.006166330615619442+0j) =>      (0.006166330615619442+0j) != (-1.9938336693843806-1.290743273001376e-231j)  (rdiff             1.0030927006150534)
                        (1+0j)        (-0.9724631008186355+0j) =>       (-0.9724631008186355+0j) != (-2.9724631008186355-1.290743273001376e-231j)  (rdiff             0.6728426668943971)
                        (1+0j)         (0.5456532432247481+0j) =>        (0.5456532432247481+0j) != (-1.454346756775252-1.290743273001376e-231j)  (rdiff             1.3751878571480671)
                        (1+0j)         (0.7652823812722331+0j) =>        (0.7652823812722331+0j) != (-1.2347176187277669-1.290743273001376e-231j)  (rdiff             1.6198035645273838)
                        (2+0j)                         (-1+0j) =>                     (inf+nanj) !=                         (1+0j)  (rdiff                            0.0)
                        (3+0j)                         (-1+0j) =>                     (inf+nanj) !=       (-0.9999999999999994+0j)  (rdiff                            0.0)
                        (4+0j)                         (-1+0j) =>                     (inf+nanj) !=        (0.9999999999999976+0j)  (rdiff                            0.0)
                        (5+0j)                         (-1+0j) =>                     (inf+nanj) !=       (-0.9999999999999993+0j)  (rdiff                            0.0)
                        (6+0j)                         (-1+0j) =>                     (inf+nanj) !=        (1.0000000000000102+0j)  (rdiff                            0.0)
                        (7+0j)                         (-1+0j) =>                     (inf+nanj) !=       (-1.0000000000000346+0j)  (rdiff                            0.0)
                        (8+0j)                         (-1+0j) =>                     (inf+nanj) !=        (0.9999999999998197+0j)  (rdiff                            0.0)
                        (9+0j)                         (-1+0j) =>                     (inf+nanj) !=        (-1.000000000000452+0j)  (rdiff                            0.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_sh_chebyt
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 115, in test_sh_chebyt
    param_ranges=[], x_range=[0, 1])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 4.64072e+77
Max |rdiff|: 1
Bad results (10 out of 100) for the following points (in output 0):
                        (1+0j)                              0j =>                        (-1+0j) !=    (-4+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)                          (1+0j) =>                         (1+0j) !=    (-2+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.6834629351721363+0j) =>        (0.3669258703442726+0j) != (-2.6330741296557276+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.7127020269829002+0j) =>        (0.4254040539658004+0j) != (-2.5745959460342+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)        (0.37025075479039493+0j) =>      (-0.25949849041921014+0j) != (-3.25949849041921+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.5611961860656249+0j) =>       (0.12239237213124987+0j) != (-2.87760762786875+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.5030831653078097+0j) =>      (0.006166330615619442+0j) != (-2.9938336693843803+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)       (0.013768449590682241+0j) =>       (-0.9724631008186355+0j) != (-3.9724631008186355+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)          (0.772826621612374+0j) =>        (0.5456532432247481+0j) != (-2.454346756775252+4.640720641493804e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.8826411906361166+0j) =>        (0.7652823812722331+0j) != (-2.2347176187277666+4.640720641493804e+77j)  (rdiff                            1.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_sh_chebyu
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 121, in test_sh_chebyu
    param_ranges=[], x_range=[0, 1])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 9.28144e+77
Max |rdiff|: 1
Bad results (19 out of 100) for the following points (in output 0):
                            0j                              0j =>                     (inf+nanj) !=                         (1+0j)  (rdiff                            0.0)
                        (1+0j)                              0j =>                     (inf+nanj) !=    (-8-9.281441282985194e+77j)  (rdiff                            0.0)
                        (1+0j)                          (1+0j) =>                         (2+0j) !=    (-4-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.6834629351721363+0j) =>        (0.7338517406885452+0j) != (-5.266148259311455-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.7127020269829002+0j) =>        (0.8508081079316008+0j) != (-5.1491918920684-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)        (0.37025075479039493+0j) =>       (-0.5189969808384203+0j) != (-6.51899698083842-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.5611961860656249+0j) =>       (0.24478474426249974+0j) != (-5.7552152557375-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.5030831653078097+0j) =>      (0.012332661231238884+0j) != (-5.987667338768761-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)       (0.013768449590682241+0j) =>        (-1.944926201637271+0j) != (-7.944926201637271-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)          (0.772826621612374+0j) =>        (1.0913064864494961+0j) != (-4.908693513550504-9.281441282985194e+77j)  (rdiff                            1.0)
                        (1+0j)         (0.8826411906361166+0j) =>        (1.5305647625444663+0j) != (-4.469435237455533-9.281441282985194e+77j)  (rdiff                            1.0)
                        (2+0j)                              0j =>                     (inf+nanj) !=                         (3+0j)  (rdiff                            0.0)
                        (3+0j)                              0j =>                     (inf+nanj) !=       (-3.9999999999999942+0j)  (rdiff                            0.0)
                        (4+0j)                              0j =>                     (inf+nanj) !=         (4.999999999999999+0j)  (rdiff                            0.0)
                        (5+0j)                              0j =>                     (inf+nanj) !=        (-5.999999999999972+0j)  (rdiff                            0.0)
                        (6+0j)                              0j =>                     (inf+nanj) !=         (6.999999999999943+0j)  (rdiff                            0.0)
                        (7+0j)                              0j =>                     (inf+nanj) !=        (-8.000000000000012+0j)  (rdiff                            0.0)
                        (8+0j)                              0j =>                     (inf+nanj) !=         (8.999999999999902+0j)  (rdiff                            0.0)
                        (9+0j)                              0j =>                     (inf+nanj) !=        (-9.999999999999954+0j)  (rdiff                            0.0)

======================================================================
FAIL: test_orthogonal_eval.TestPolys.test_sh_legendre
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 131, in test_sh_legendre
    param_ranges=[], x_range=[0, 1])
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal_eval.py", line 76, in check_poly
    ds.check()
  File "/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/sw/lib/python2.7/site-packages/numpy/testing/utils.py", line 44, in assert_
    raise AssertionError(msg)
AssertionError: 
Max |adiff|: 5.37359e+154
Max |rdiff|: 1
Bad results (19 out of 100) for the following points (in output 0):
                            0j                              0j =>                     (inf+nanj) !=                         (1+0j)  (rdiff                            0.0)
                        (1+0j)                              0j =>                     (inf+nanj) !=   (-4-5.373587386454407e+154j)  (rdiff                            0.0)
                        (1+0j)                          (1+0j) =>                         (1+0j) !=   (-2-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.6834629351721363+0j) =>        (0.3669258703442726+0j) != (-2.6330741296557276-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.7127020269829002+0j) =>        (0.4254040539658004+0j) != (-2.5745959460342-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)        (0.37025075479039493+0j) =>      (-0.25949849041921014+0j) != (-3.25949849041921-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.5611961860656249+0j) =>       (0.12239237213124987+0j) != (-2.87760762786875-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.5030831653078097+0j) =>      (0.006166330615619442+0j) != (-2.9938336693843803-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)       (0.013768449590682241+0j) =>       (-0.9724631008186355+0j) != (-3.9724631008186355-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)          (0.772826621612374+0j) =>        (0.5456532432247481+0j) != (-2.454346756775252-5.373587386454407e+154j)  (rdiff                            1.0)
                        (1+0j)         (0.8826411906361166+0j) =>        (0.7652823812722331+0j) != (-2.2347176187277666-5.373587386454407e+154j)  (rdiff                            1.0)
                        (2+0j)                              0j =>                     (inf+nanj) !=        (1.0000000000000002+0j)  (rdiff                            0.0)
                        (3+0j)                              0j =>                     (inf+nanj) !=       (-1.0000000000000004+0j)  (rdiff                            0.0)
                        (4+0j)                              0j =>                     (inf+nanj) !=        (1.0000000000000007+0j)  (rdiff                            0.0)
                        (5+0j)                              0j =>                     (inf+nanj) !=       (-1.0000000000000007+0j)  (rdiff                            0.0)
                        (6+0j)                              0j =>                     (inf+nanj) !=        (1.0000000000000029+0j)  (rdiff                            0.0)
                        (7+0j)                              0j =>                     (inf+nanj) !=       (-1.0000000000000016+0j)  (rdiff                            0.0)
                        (8+0j)                              0j =>                     (inf+nanj) !=         (1.000000000000002+0j)  (rdiff                            0.0)
                        (9+0j)                              0j =>                     (inf+nanj) !=       (-1.0000000000000013+0j)  (rdiff                            0.0)

----------------------------------------------------------------------
Ran 8931 tests in 163.398s

FAILED (KNOWNFAIL=114, SKIP=210, errors=8, failures=27)

Reverting the numpy to 1.7.1 eliminates the scipy 0.13.0rc1 failures producing the following results. 

Running unit tests for scipy
NumPy version 1.7.1
NumPy is installed in /sw/lib/python2.7/site-packages/numpy
SciPy version 0.13.0rc1
SciPy is installed in /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy
Python version 2.7.5 (default, Oct  9 2013, 13:51:44) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.75)]
nose version 1.3.0
/sw/lib/python2.7/site-packages/numpy/lib/utils.py:139: DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.blas` instead!
  warnings.warn(depdoc, DeprecationWarning)
/sw/lib/python2.7/site-packages/numpy/lib/utils.py:139: DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg.lapack` instead!
  warnings.warn(depdoc, DeprecationWarning)
..............................................................................................................................................................................................................................K..................................................................................................................K.......................................................................................K..K......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSS......SSSSSS......SSSS......................................................................................0-th dimension must be fixed to 3 but got 15
..0-th dimension must be fixed to 3 but got 5
.......................S..........K..............................................................................................................................................................................................................................................................................................K.......................................................................................................................................................................................K..............................................................................SSSSSS............S.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SS....................SSSSSSSSSS.......KKKSSS.S....KKK......S..K...KKK...KKK...............S..............SSSSS..SSSS.................................SS...............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK...........SSS.S..............SSSSS..SSSS.................................................................................KKKK..........KKKK...............KKKK....KKKK.....................................................................................................................................................................................................................................................................................................................................................................................................................KKKK..........KKKK...............KKKK....KKKK......................................................................................................................................................................................................................................................................................................................................................................SS............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK......S....SSS.S..............SSSSS..SSSS...............................K..S.SSS..........SSS.KKKKSKSSKS....SSSKKKSSS...SSSKKK..........SSSKKKSSSKKK......S.....SSS.S.........K.....KSSS...KSKS................................................SSS................SSSKKK......SSSKKK...........SSSKKK...SSSKKK......S....SSS............K...............................................................................................................................................................................................................................................................................................................................................................................................SSS...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSS.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S..........................................................................................S...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K......................................................................................................
----------------------------------------------------------------------
Ran 8931 tests in 161.814s

OK (KNOWNFAIL=114, SKIP=210)


These builds are against python 2.7.5.

> 
> 
> 
> ==========================
> SciPy 0.13.0 Release Notes
> ==========================
> 
> .. note:: Scipy 0.13.0 is not released yet!
> 
> .. contents::
> 
> SciPy 0.13.0 is the culmination of 7 months of hard work. It contains
> many new features, numerous bug-fixes, improved test coverage and
> better documentation.  There have been a number of deprecations and
> API changes in this release, which are documented below.  All users
> are encouraged to upgrade to this release, as there are a large number
> of bug-fixes and optimizations.  Moreover, our development attention
> will now shift to bug-fix releases on the 0.13.x branch, and on adding
> new features on the master branch.
> 
> This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater.
> 
> 
> New features
> ============
> 
> ``scipy.integrate`` improvements
> --------------------------------
> 
> N-dimensional numerical integration
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> A new function `scipy.integrate.nquad`, which provides N-dimensional
> integration functionality with a more flexible interface than ``dblquad``
> and
> ``tplquad``, has been added.
> 
> ``dopri*`` improvements
> ^^^^^^^^^^^^^^^^^^^^^^^
> 
> The intermediate results from the ``dopri`` family of ODE solvers can now be
> accessed by a *solout* callback function.
> 
> 
> ``scipy.linalg`` improvements
> -----------------------------
> 
> Interpolative decompositions
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Scipy now includes a new module `scipy.linalg.interpolative`
> containing routines for computing interpolative matrix decompositions
> (ID). This feature is based on the ID software package by
> P.G. Martinsson, V. Rokhlin, Y. Shkolnisky, and M. Tygert, previously
> adapted for Python in the PymatrixId package by K.L. Ho.
> 
> Polar decomposition
> ^^^^^^^^^^^^^^^^^^^
> 
> A new function `scipy.linalg.polar`, to compute the polar decomposition
> of a matrix, was added.
> 
> BLAS level 3 functions
> ^^^^^^^^^^^^^^^^^^^^^^
> 
> The BLAS functions ``symm``, ``syrk``, ``syr2k``, ``hemm``, ``herk`` and
> ``her2k`` are now wrapped in `scipy.linalg`.
> 
> Matrix functions
> ^^^^^^^^^^^^^^^^
> 
> Several matrix function algorithms have been implemented or updated
> following
> detailed descriptions in recent papers of Nick Higham and his co-authors.
> These include the matrix square root (``sqrtm``), the matrix logarithm
> (``logm``), the matrix exponential (``expm``) and its Frechet derivative
> (``expm_frechet``), and fractional matrix powers
> (``fractional_matrix_power``).
> 
> 
> ``scipy.optimize`` improvements
> -------------------------------
> 
> Trust-region unconstrained minimization algorithms
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> The ``minimize`` function gained two trust-region solvers for unconstrained
> minimization: ``dogleg`` and ``trust-ncg``.
> 
> 
> ``scipy.sparse`` improvements
> -----------------------------
> 
> Boolean comparisons and sparse matrices
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> All sparse matrix types now support boolean data, and boolean operations.
> Two
> sparse matrices `A` and `B` can be compared in all the expected ways `A <
> B`,
> `A >= B`, `A != B`, producing similar results as dense Numpy arrays.
> Comparisons with dense matrices and scalars are also supported.
> 
> CSR and CSC fancy indexing
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Compressed sparse row and column sparse matrix types now support fancy
> indexing
> with boolean matrices, slices, and lists. So where A is a (CSC or CSR)
> sparse
> matrix, you can do things like::
> 
>     >>> A[A > 0.5] = 1  # since Boolean sparse matrices work
>     >>> A[:2, :3] = 2
>     >>> A[[1,2], 2] = 3
> 
> 
> ``scipy.sparse.linalg`` improvements
> ------------------------------------
> 
> The new function ``onenormest`` provides a lower bound of the 1-norm of a
> linear operator and has been implemented according to Higham and Tisseur
> (2000).  This function is not only useful for sparse matrices, but can also
> be
> used to estimate the norm of products or powers of dense matrices without
> explictly building the intermediate matrix.
> 
> The multiplicative action of the matrix exponential of a linear operator
> (``expm_multiply``) has been implemented following the description in
> Al-Mohy
> and Higham (2011).
> 
> Abstract linear operators (`scipy.sparse.linalg.LinearOperator`) can now be
> multiplied, added to each other, and exponentiated, producing new linear
> operators. This enables easier construction of composite linear operations.
> 
> 
> ``scipy.spatial`` improvements
> ------------------------------
> 
> The vertices of a `ConvexHull` can now be accessed via the `vertices`
> attribute,
> which gives proper orientation in 2-D.
> 
> 
> ``scipy.signal`` improvements
> -----------------------------
> 
> The cosine window function `scipy.signal.cosine` was added.
> 
> 
> ``scipy.special`` improvements
> ------------------------------
> 
> New functions `scipy.special.xlogy` and `scipy.special.xlog1py` were added.
> These functions can simplify and speed up code that has to calculate
> ``x * log(y)`` and give 0 when ``x == 0``.
> 
> 
> ``scipy.io`` improvements
> -------------------------
> 
> Unformatted Fortran file reader
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> The new class `scipy.io.FortranFile` facilitates reading unformatted
> sequential files written by Fortran code.
> 
> ``scipy.io.wavfile`` enhancements
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> `scipy.io.wavfile.write` now accepts a file buffer. Previously it only
> accepted a filename.
> 
> `scipy.io.wavfile.read` and `scipy.io.wavfile.write` can now handle floating
> point WAV files.
> 
> 
> ``scipy.interpolate`` improvements
> ----------------------------------
> 
> B-spline derivatives and antiderivatives
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> `scipy.interpolate.splder` and `scipy.interpolate.splantider` functions
> for computing B-splines that represent derivatives and antiderivatives
> of B-splines were added.  These functions are also available in the
> class-based FITPACK interface as ``UnivariateSpline.derivative`` and
> ``UnivariateSpline.antiderivative``.
> 
> 
> ``scipy.stats`` improvements
> ----------------------------
> 
> Distributions now allow using keyword parameters in addition to
> positional parameters in all methods.
> 
> The function `scipy.stats.power_divergence` has been added for the
> Cressie-Read power divergence statistic and goodness of fit test.
> Included in this family of statistics is the "G-test"
> (http://en.wikipedia.org/wiki/G-test).
> 
> `scipy.stats.mood` now accepts multidimensional input.
> 
> An option was added to `scipy.stats.wilcoxon` for continuity correction.
> 
> `scipy.stats.chisquare` now has an `axis` argument.
> 
> `scipy.stats.mstats.chisquare` now has `axis` and `ddof` arguments.
> 
> 
> Deprecated features
> ===================
> 
> ``expm2`` and ``expm3``
> -----------------------
> 
> The matrix exponential functions `scipy.linalg.expm2` and
> `scipy.linalg.expm3`
> are deprecated. All users should use the numerically more robust
> `scipy.linalg.expm` function instead.
> 
> ``scipy.stats`` functions
> -------------------------
> 
> `scipy.stats.oneway` is deprecated; `scipy.stats.f_oneway` should be used
> instead.
> 
> `scipy.stats.glm` is deprecated.  `scipy.stats.ttest_ind` is an equivalent
> function; more full-featured general (and generalized) linear model
> implementations can be found in statsmodels.
> 
> `scipy.stats.cmedian` is deprecated; ``numpy.median`` should be used
> instead.
> 
> 
> Backwards incompatible changes
> ==============================
> 
> LIL matrix assignment
> ---------------------
> Assigning values to LIL matrices with two index arrays now works similarly
> as
> assigning into ndarrays::
> 
>     >>> x = lil_matrix((3, 3))
>     >>> x[[0,1,2],[0,1,2]]=[0,1,2]
>     >>> x.todense()
>     matrix([[ 0.,  0.,  0.],
>             [ 0.,  1.,  0.],
>             [ 0.,  0.,  2.]])
> 
> rather than giving the result::
> 
>     >>> x.todense()
>     matrix([[ 0.,  1.,  2.],
>             [ 0.,  1.,  2.],
>             [ 0.,  1.,  2.]])
> 
> Users relying on the previous behavior will need to revisit their code.
> The previous behavior is obtained by ``x[numpy.ix_([0,1,2],[0,1,2])] = ...`.
> 
> 
> Deprecated ``radon`` function removed
> -------------------------------------
> 
> The ``misc.radon`` function, which was deprecated in scipy 0.11.0, has been
> removed.  Users can find a more full-featured ``radon`` function in
> scikit-image.
> 
> 
> Removed deprecated keywords ``xa`` and ``xb`` from ``stats.distributions``
> --------------------------------------------------------------------------
> 
> The keywords ``xa`` and ``xb``, which were deprecated since 0.11.0, have
> been removed from the distributions in ``scipy.stats``.
> 
> Changes to MATLAB file readers / writers
> ----------------------------------------
> 
> The major change is that 1D arrays in numpy now become row vectors (shape
> 1, N)
> when saved to a MATLAB 5 format file.  Previously 1D arrays saved as column
> vectors (N, 1).  This is to harmonize the behavior of writing MATLAB 4 and 5
> formats, and adapt to the defaults of numpy and MATLAB - for example
> ``np.atleast_2d`` returns 1D arrays as row vectors.
> 
> Trying to save arrays of greater than 2 dimensions in MATLAB 4 format now
> raises
> an error instead of silently reshaping the array as 2D.
> 
> ``scipy.io.loadmat('afile')`` used to look for `afile` on the Python system
> path
> (``sys.path``); now ``loadmat`` only looks in the current directory for a
> relative path filename.
> 
> Other changes
> =============
> 
> Security fix: ``scipy.weave`` previously used temporary directories in an
> insecure manner under certain circumstances.
> 
> Cython is now required to build *unreleased* versions of scipy.
> The C files generated from Cython sources are not included in the git repo
> anymore.  They are however still shipped in source releases.
> 
> The code base received a fairly large PEP8 cleanup.  A ``tox pep8``
> command has been added; new code should pass this test command.
> 
> Authors
> =======
> 
> This release contains work by the following people (contributed at least
> one patch to this release, names in alphabetical order):
> 
> * Jorge Ca?ardo Alastuey +
> * Tom Aldcroft +
> * Max Bolingbroke +
> * Joseph Jon Booker +
> * Fran?ois Boulogne
> * Matthew Brett
> * Christian Brodbeck +
> * Per Brodtkorb +
> * Christian Brueffer +
> * Lars Buitinck
> * Evgeni Burovski +
> * Tim Cera
> * Lawrence Chan +
> * David Cournapeau
> * Draz?en Luc?anin +
> * Alexander J. Dunlap +
> * endolith
> * Andr? Gaul +
> * Christoph Gohlke
> * Ralf Gommers
> * Alex Griffing +
> * Blake Griffith +
> * Charles Harris
> * Bob Helmbold +
> * Andreas Hilboll
> * Kat Huang +
> * Oleksandr (Sasha) Huziy +
> * Gert-Ludwig Ingold +
> * Thouis (Ray) Jones
> * Juan Luis Cano Rodr?guez +
> * Robert Kern
> * Andreas Kloeckner +
> * Sytse Knypstra +
> * Gustav Larsson +
> * Denis Laxalde
> * Christopher Lee
> * Tim Leslie
> * Wendy Liu +
> * Clemens Novak +
> * Takuya Oshima +
> * Josef Perktold
> * Illia Polosukhin +
> * Przemek Porebski +
> * Steve Richardson +
> * Branden Rolston +
> * Skipper Seabold
> * Fazlul Shahriar
> * Leo Singer +
> * Rohit Sivaprasad +
> * Daniel B. Smith +
> * Julian Taylor
> * Louis Thibault +
> * Tomas Tomecek +
> * John Travers
> * Richard Tsai +
> * Jacob Vanderplas
> * Patrick Varilly
> * Pauli Virtanen
> * Stefan van der Walt
> * Warren Weckesser
> * Pedro Werneck +
> * Nils Werner +
> * Michael Wimmer +
> * Nathan Woods +
> * Tony S. Yu +
> 
> A total of 65 people contributed to this release.
> People with a "+" by their names contributed a patch for the first time.

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From pav at iki.fi  Sat Oct 12 14:12:45 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 12 Oct 2013 21:12:45 +0300
Subject: [SciPy-Dev] numpy 1.8.0rc1 + OSX Accelerate = failure
In-Reply-To: <20131012141028.GA25492@bromo.med.uc.edu>
References: <CABL7CQjm+sQhT=zNoj8fb0WxfPePQJPpU5Lw_ncj0j2yfZM54A@mail.gmail.com>
	<20131012141028.GA25492@bromo.med.uc.edu>
Message-ID: <l3c3ek$u4c$1@ger.gmane.org>

12.10.2013 17:10, Jack Howarth kirjoitti:
[clip]
> The build of the new scipy 0.13.0rc1 still produces failures on
> x86_64-apple-darwin12 against numpy 0.18.0rc1 with both built
> against Xcode 5.0's clang and FSF gfortran 4.8.1. These are...
[clip]
> Reverting the numpy to 1.7.1 eliminates the scipy 0.13.0rc1
> failures producing the following results.

Thanks for the report. This seems to be an issue with Numpy 1.8.0rc1 +
OSX Accelerate, and not in Scipy.

https://github.com/numpy/numpy/issues/3901

-- 
Pauli Virtanen



From pav at iki.fi  Sat Oct 12 17:03:14 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 13 Oct 2013 00:03:14 +0300
Subject: [SciPy-Dev] numpy 1.8.0rc1 + OSX Accelerate = failure
In-Reply-To: <l3c3ek$u4c$1@ger.gmane.org>
References: <CABL7CQjm+sQhT=zNoj8fb0WxfPePQJPpU5Lw_ncj0j2yfZM54A@mail.gmail.com>	<20131012141028.GA25492@bromo.med.uc.edu>
	<l3c3ek$u4c$1@ger.gmane.org>
Message-ID: <l3cde8$ui2$1@ger.gmane.org>

12.10.2013 21:12, Pauli Virtanen kirjoitti:
[clip]
> Thanks for the report. This seems to be an issue with Numpy 1.8.0rc1 +
> OSX Accelerate, and not in Scipy.
> 
> https://github.com/numpy/numpy/issues/3901

... and it's fixed now. You may want to try the maintenance/1.8.x branch
after the backport is done.

https://github.com/numpy/numpy/tree/maintenance/1.8.x

https://github.com/numpy/numpy/pull/3903

-- 
Pauli Virtanen



From pav at iki.fi  Mon Oct 14 05:22:26 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 14 Oct 2013 09:22:26 +0000 (UTC)
Subject: [SciPy-Dev] Beginning work on robustly allowing function
	pointers in integrate - quad
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
	<CAAYHtCQgkCnYZ6j2x6FSthgMOMHPk7sUQdRP0V0Nyokx8ozrXg@mail.gmail.com>
Message-ID: <loom.20131014T111120-142@post.gmane.org>

Nathan Woods <charlesnwoods <at> gmail.com> writes:
[clip]
> In my opinion, the best way to solve the first problem is
> to take advantage of the OOP programming style. Functional
> programming, as used in SLATEC and much of SciPy, is expressly
> designed to prevent the passing of information around the
> program through anything other than the functional interface.
> In FP, f(x) cannot depend on anything other than x, and if it
> depends on x and y, then it absolutely must be written f(x,y).
> The current implementation uses global variables to cheat around
> this restriction, and pass y in through the back door, as it were.
> A perhaps safer alternative is to define f as a bound method to
> an object, and use object variables instead of global variables
> to pass the y,z,... to the function, leaving the interface as
> f(x), just as Quadpack wants it. There's an example of this in
> scipy.integrate.nquad, if anyone is interested. This could be
> fairly easily and safely implemented in Fortran 2003, but that
> is not as widely supported as I think scipy needs. That leaves
> either C, or C++.
[clip]
> Comments welcome.

What you write above is problematic --- you assume that
C and Fortran have similar metaprogramming capabilities as Python.
This is not the case, which makes what you propose above
impossible.

Bound methods do not exist in C or Fortran, even if allowing for 
OO programming that C++ and Fortran 2000+ bring. Moreover,
signatures of all functions to be called must be known at compile
time.

Metaprogramming can be done in principle, but this requires
on-the-fly code generation, which I believe is not a feasible
solution here. The solution to the problem at hand must necessarily
be more restricted.

-- 
Pauli Virtanen



From charlesr.harris at gmail.com  Mon Oct 14 17:37:22 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 14 Oct 2013 15:37:22 -0600
Subject: [SciPy-Dev] NumPy 1.8.0rc2 release
Message-ID: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>

Hi All,

NumPy 1.8.0rc2 is up now on
sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/>.
Binary builds are included, except for Python 3.3 on windows. Many thanks
to Ralf for the binaries and to those who found and fixed the bugs in rc1.
Please test this thoroughly, especially if you have access to one of the
less common platforms. Testing of rc1 turned up several bugs that would
have been a embarrassment if they had made their way into the release and
we are very happy that they were discovered.

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

From howarth at bromo.med.uc.edu  Mon Oct 14 18:34:52 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Mon, 14 Oct 2013 18:34:52 -0400
Subject: [SciPy-Dev] NumPy 1.8.0rc2 release
In-Reply-To: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
References: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
Message-ID: <20131014223452.GA3429@bromo.med.uc.edu>

On Mon, Oct 14, 2013 at 03:37:22PM -0600, Charles R Harris wrote:
> Hi All,
> 
> NumPy 1.8.0rc2 is up now on
> sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/>.
> Binary builds are included, except for Python 3.3 on windows. Many thanks
> to Ralf for the binaries and to those who found and fixed the bugs in rc1.
> Please test this thoroughly, especially if you have access to one of the
> less common platforms. Testing of rc1 turned up several bugs that would
> have been a embarrassment if they had made their way into the release and
> we are very happy that they were discovered.
> 
> Chuck

Chuck,
   I can confirm that the numpy 1.8.0rc2 release eliminates the testsuite failures
in scipy 0.13.0rc1 when built against it on x86_64-apple-darwin12 producing...

Running unit tests for scipy
NumPy version 1.8.0rc2
NumPy is installed in /sw/lib/python2.7/site-packages/numpy
SciPy version 0.13.0rc1
SciPy is installed in /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy
Python version 2.7.5 (default, Oct  9 2013, 13:51:44) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.75)]
nose version 1.3.0
/sw/lib/python2.7/site-packages/numpy/lib/utils.py:134: DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.blas` instead!
  warnings.warn(depdoc, DeprecationWarning)
/sw/lib/python2.7/site-packages/numpy/lib/utils.py:134: DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg.lapack` instead!
  warnings.warn(depdoc, DeprecationWarning)
..............................................................................................................................................................................................................................K..................................................................................................................K.......................................................................................K..K......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSS......SSSSSS......SSSS......................................................................................0-th dimension must be fixed to 3 but got 15
..0-th dimension must be fixed to 3 but got 5
.......................S..........K..............................................................................................................................................................................................................................................................................................K.......................................................................................................................................................................................K..............................................................................SSSSSS............S............................................................./sw/lib/python2.7/site-packages/numpy/core/_methods.py:55: RuntimeWarning: Mean of empty slice.
  warnings.warn("Mean of empty slice.", RuntimeWarning)
....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SS....................SSSSSSSSSS.......KKKSSS.S....KKK......S..K...KKK...KKK...............S..............SSSSS..SSSS.................................SS...............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK...........SSS.S..............SSSSS..SSSS.................................................................................KKKK..........KKKK...............KKKK....KKKK.....................................................................................................................................................................................................................................................................................................................................................................................................................KKKK..........KKKK...............KKKK....KKKK......................................................................................................................................................................................................................................................................................................................................................................SS............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK......S....SSS.S..............SSSSS..SSSS...............................K..S.SSS..........SSS.KKKKSKSSKS....SSSKKKSSS...SSSKKK..........SSSKKKSSSKKK......S.....SSS.S.........K.....KSSS...KSKS................................................SSS................SSSKKK......SSSKKK...........SSSKKK...SSSKKK......S....SSS............K...............................................................................................................................................................................................................................................................................................................................................................................................SSS............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:244: RuntimeWarning: invalid value encountered in greater
  pinf_x = np.isinf(x) & (x > 0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:245: RuntimeWarning: invalid value encountered in greater
  pinf_y = np.isinf(y) & (y > 0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:246: RuntimeWarning: invalid value encountered in less
  minf_x = np.isinf(x) & (x < 0)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:247: RuntimeWarning: invalid value encountered in less
  minf_y = np.isinf(y) & (y < 0)
.....................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSS................................................../sw/lib/python2.7/site-packages/numpy/core/_methods.py:77: RuntimeWarning: Degrees of freedom <= 0 for slice
  warnings.warn("Degrees of freedom <= 0 for slice", RuntimeWarning)
.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7208: RuntimeWarning: invalid value encountered in greater_equal
  return where(temp >= q, vals1, vals)
.............................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7584: RuntimeWarning: invalid value encountered in greater_equal
  return where((temp >= q), vals1, vals)
............................./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7357: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return (1-p)**(k-1) * p
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7357: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return (1-p)**(k-1) * p
..../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
/sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
  return -p**k * 1.0 / k / log(1 - p)
............S..........................................................................................S...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K......................................................................................................
----------------------------------------------------------------------
Ran 8931 tests in 160.354s

OK (KNOWNFAIL=114, SKIP=210)

...when built against python 2.7.5 under fink.
          Jack

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From charlesr.harris at gmail.com  Tue Oct 15 10:57:30 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 15 Oct 2013 08:57:30 -0600
Subject: [SciPy-Dev] NumPy 1.8.0rc2 release
In-Reply-To: <20131014223452.GA3429@bromo.med.uc.edu>
References: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
	<20131014223452.GA3429@bromo.med.uc.edu>
Message-ID: <CAB6mnxLDZET38Bx90yb6jE8WCMumm2rHk8U4Pfka5SLsgOancA@mail.gmail.com>

On Mon, Oct 14, 2013 at 4:34 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote:

> On Mon, Oct 14, 2013 at 03:37:22PM -0600, Charles R Harris wrote:
> > Hi All,
> >
> > NumPy 1.8.0rc2 is up now on
> > sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/
> >.
> > Binary builds are included, except for Python 3.3 on windows. Many thanks
> > to Ralf for the binaries and to those who found and fixed the bugs in
> rc1.
> > Please test this thoroughly, especially if you have access to one of the
> > less common platforms. Testing of rc1 turned up several bugs that would
> > have been a embarrassment if they had made their way into the release and
> > we are very happy that they were discovered.
> >
> > Chuck
>
> Chuck,
>    I can confirm that the numpy 1.8.0rc2 release eliminates the testsuite
> failures
> in scipy 0.13.0rc1 when built against it on x86_64-apple-darwin12
> producing...
>
> Running unit tests for scipy
> NumPy version 1.8.0rc2
> NumPy is installed in /sw/lib/python2.7/site-packages/numpy
> SciPy version 0.13.0rc1
> SciPy is installed in
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy
> Python version 2.7.5 (default, Oct  9 2013, 13:51:44) [GCC 4.2.1
> Compatible Apple LLVM 5.0 (clang-500.2.75)]
> nose version 1.3.0
> /sw/lib/python2.7/site-packages/numpy/lib/utils.py:134:
> DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.blas`
> instead!
>   warnings.warn(depdoc, DeprecationWarning)
> /sw/lib/python2.7/site-packages/numpy/lib/utils.py:134:
> DeprecationWarning: `scipy.lib.lapack` is deprecated, use
> `scipy.linalg.lapack` instead!
>   warnings.warn(depdoc, DeprecationWarning)
>
> ..............................................................................................................................................................................................................................K..................................................................................................................K.......................................................................................K..K.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>  .....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSS......SSSSSS......SSSS......................................................................................0-th
> dimension must be fixed to 3 but got 15
> ..0-th dimension must be fixed to 3 but got 5
> .......................S..........K..............................................................................................................................................................................................................................................................................................K.......................................................................................................................................................................................K..............................................................................SSSSSS............S............................................................./sw/lib/python2.7/site-packages/numpy/core/_methods.py:55:
> RuntimeWarning: Mean of empty slice.
>   warnings.warn("Mean of empty slice.", RuntimeWarning)
>
> ....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K.........................................................................................................................................................................................................................................................................................................................................................................................................................................................
>
>  .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SS..................
>
>  ..SSSSSSSSSS.......KKKSSS.S....KKK......S..K...KKK...KKK...............S..............SSSSS..SSSS.................................SS...............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK...........SSS.S..............SSSSS..SSSS.................................................................................KKKK..........KKKK...............KKKK....KKKK.....................................................................................................................................................................................................................................................................................................................................................................................................................KKKK..........KKKK...............KKKK....KKKK.......................................................................................................................................................................
>
>  ...............................................................................................................................................................................................SS............SSS.SSSSSSSSSS....SSSKKKSSS.S.SSSKKK......S...SSSKKKSSSKKK......S....SSS.S..............SSSSS..SSSS...............................K..S.SSS..........SSS.KKKKSKSSKS....SSSKKKSSS...SSSKKK..........SSSKKKSSSKKK......S.....SSS.S.........K.....KSSS...KSKS................................................SSS................SSSKKK......SSSKKK...........SSSKKK...SSSKKK......S....SSS............K...............................................................................................................................................................................................................................................................................................................................................................................................SSS...........
>  .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:244:
> RuntimeWarning: invalid value encountered in greater
>   pinf_x = np.isinf(x) & (x > 0)
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:245:
> RuntimeWarning: invalid value encountered in greater
>   pinf_y = np.isinf(y) & (y > 0)
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:246:
> RuntimeWarning: invalid value encountered in less
>   minf_x = np.isinf(x) & (x < 0)
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/special/_testutils.py:247:
> RuntimeWarning: invalid value encountered in less
>   minf_y = np.isinf(y) & (y < 0)
> .....................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSS................................................../sw/lib/python2.7/site-packages/numpy/core/_methods.py:77:
> RuntimeWarning: Degrees of freedom <= 0 for slice
>   warnings.warn("Degrees of freedom <= 0 for slice", RuntimeWarning)
> .............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7208:
> RuntimeWarning: invalid value encountered in greater_equal
>   return where(temp >= q, vals1, vals)
> .............................................................................................../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7584:
> RuntimeWarning: invalid value encountered in greater_equal
>   return where((temp >= q), vals1, vals)
> ............................./sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7357:
> DeprecationWarning: converting an array with ndim > 0 to an index will
> result in an error in the future
>   return (1-p)**(k-1) * p
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7357:
> DeprecationWarning: converting an array with ndim > 0 to an index will
> result in an error in the future
>   return (1-p)**(k-1) * p
> ..../sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525:
> DeprecationWarning: converting an array with ndim > 0 to an index will
> result in an error in the future
>   return -p**k * 1.0 / k / log(1 - p)
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525:
> DeprecationWarning: converting an array with ndim > 0 to an index will
> result in an error in the future
>   return -p**k * 1.0 / k / log(1 - p)
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525:
> DeprecationWarning: converting an array with ndim > 0 to an index will
> result in an error in the future
>   return -p**k * 1.0 / k / log(1 - p)
> /sw/src/fink.build/root-scipy-py27-0.13.0rc1-0/sw/lib/python2.7/site-packages/scipy/stats/distributions.py:7525:
> DeprecationWarning: converting an array with ndim > 0 to an index will
> result in an error in the future
>   return -p**k * 1.0 / k / log(1 - p)
>
> ............S..........................................................................................S...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K......................................................................................................
> ----------------------------------------------------------------------
> Ran 8931 tests in 160.354s
>
> OK (KNOWNFAIL=114, SKIP=210)
>
> ...when built against python 2.7.5 under fink.
>           Jack
>
> Thanks for the testing.

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

From prabhu at aero.iitb.ac.in  Tue Oct 15 12:52:17 2013
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Tue, 15 Oct 2013 22:22:17 +0530
Subject: [SciPy-Dev] [ANN] CFP: SciPy India 2013: Dec 13 - 15, IIT Bombay
Message-ID: <525D72C1.5050303@aero.iitb.ac.in>

Hello,

[Apologies for the cross posting!]

The CFP and registration for SciPy India 2013 (http://scipy.in) is open. 
  SciPy India 2013 will be held in IIT Bombay between December 13th to 
December 15th, 2013.

Please spread the word!

SciPy India is an annual conference on using Python for science and 
engineering research and education. The conference is currently in its 
fifth year and provides an opportunity to learn and implement Python in 
education and research.


Call for Papers
================

We look forward to your submissions on the use of Python for
scientific computing and education. This includes pedagogy,
exploration, modeling and analysis from both applied and
developmental perspectives. We welcome contributions from academia
as well as industry.

For details on the paper submission please see here:

  http://scipy.in/2013/call-for-proposals/
  	
Important Dates
================

   - Call for proposals end: 24th November 2013
   - List of accepted proposals will be published: 1st December 2013.


We look forward to seeing you at SciPy India.

Regards,
Prabhu Ramachandran and Jarrod Millman


From cournape at gmail.com  Tue Oct 15 14:46:43 2013
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 15 Oct 2013 19:46:43 +0100
Subject: [SciPy-Dev] [Numpy-discussion] NumPy 1.8.0rc2 release
In-Reply-To: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
References: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
Message-ID: <CAGY4rcUscTBFggzwCf1vSRQj7dFHuEGFXSwq31A3x=zjLQnZ4w@mail.gmail.com>

It looks better than rc1, thanks for the great work. I have only tested on
rh5 for now, but building the following against numpy 1.7.1 and running
against 1.8.0 rc2 only give a few failures for the full list of packages
supported by Enthought. Bottleneck / larry are caused by numpy, the sklearn
may be a bug in numpy or scikit learn or scipy (eigh issue).

List of packages:

GDAL-1.10.0
MDP-3.3
Pycluster-1.50
ScientificPython-2.9.0
SimPy-2.2
astropy-0.2.4
basemap-1.0.6
biopython-1.59
chaco-4.3.0
enable-4.3.0
fastnumpy-1.0
fwrap-0.1.1
h5py-2.2.0
llvmmath-0.1.1
matplotlib-1.3.0
mayavi-4.3.0
netCDF4-1.0.5
networkx-1.8.1
nltk-2.0.1
numba-0.10.2
opencv-2.4.5
pandas-0.12.0
pyfits-3.0.6
pygarrayimage-0.0.7
pygrib-1.9.2
pyhdf-0.8.3
pysparse-1.2.dev213
pytables-2.4.0
scikits.image-0.8.2
scikits.rsformats-0.1
scikits.timeseries-0.91.3
scimath-4.1.2
scipy-0.12.0
traits-4.3.0

As for the bottleneck/larry failures (for reference):

 ======================================================================
  FAIL: Test nanargmin.
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/nose/case.py",
line 197, in runTest
      self.test(*self.arg)
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/bottleneck/tests/func_test.py",
line 78, in unit_maker
      assert_array_equal(actual, desired, err_msg)
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/numpy/testing/utils.py",
line 718, in assert_array_equal
      verbose=verbose, header='Arrays are not equal')
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/numpy/testing/utils.py",
line 644, in assert_array_compare
      raise AssertionError(msg)
  AssertionError:
  Arrays are not equal

  func nanargmin | input a44 (float32) | shape (4,) | axis -1

  Input array:
  [ nan  nan  nan  nan]

  (mismatch 100.0%)
   x: array(nan)
   y: array('Crashed',
        dtype='|S7')

  ======================================================================
  FAIL: Test nanargmax.
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/nose/case.py",
line 197, in runTest
      self.test(*self.arg)
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/bottleneck/tests/func_test.py",
line 78, in unit_maker
      assert_array_equal(actual, desired, err_msg)
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/numpy/testing/utils.py",
line 718, in assert_array_equal
      verbose=verbose, header='Arrays are not equal')
    File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/numpy/testing/utils.py",
line 644, in assert_array_compare
      raise AssertionError(msg)
  AssertionError:
  Arrays are not equal

  func nanargmax | input a44 (float32) | shape (4,) | axis -1

  Input array:
  [ nan  nan  nan  nan]

  (mismatch 100.0%)
   x: array(nan)
   y: array('Crashed',
        dtype='|S7')

  ----------------------------------------------------------------------
  Ran 124 tests in 85.714s

  FAILED (failures=2)
FAIL

and larry:

======================================================================
ERROR: Failure: IndexError (too many indices)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/nose/loader.py",
line 253, in generate
    for test in g():
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/tests/all_nan_test.py",
line 31, in test_all_nan
    actual = getattr(lar(), method)(*parameters)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/deflarry.py",
line 3066, in quantile
    x = quantile(self.x, q, axis=axis)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/farray/normalize.py",
line 289, in quantile
    y = np.apply_along_axis(_quantileraw1d, axis, x, q)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/numpy/lib/shape_base.py",
line 79, in apply_along_axis
    res = func1d(arr[tuple(i.tolist())],*args)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/farray/normalize.py",
line 228, in _quantileraw1d
    xi = xi[idx,:]
IndexError: too many indices

======================================================================
ERROR: larry.quantile_1
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/tests/deflarry_test.py",
line 3401, in test_quantile_1
    actual = self.l1.quantile(2)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/deflarry.py",
line 3066, in quantile
    x = quantile(self.x, q, axis=axis)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/farray/normalize.py",
line 289, in quantile
    y = np.apply_along_axis(_quantileraw1d, axis, x, q)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/numpy/lib/shape_base.py",
line 79, in apply_along_axis
    res = func1d(arr[tuple(i.tolist())],*args)
  File
"/home/vagrant/src/master-env/lib/python2.7/site-packages/la/farray/normalize.py",
line 228, in _quantileraw1d
    xi = xi[idx,:]
IndexError: too many indices

(more similar)


On Mon, Oct 14, 2013 at 10:37 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

> Hi All,
>
> NumPy 1.8.0rc2 is up now on sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/>.
> Binary builds are included, except for Python 3.3 on windows. Many thanks
> to Ralf for the binaries and to those who found and fixed the bugs in rc1.
> Please test this thoroughly, especially if you have access to one of the
> less common platforms. Testing of rc1 turned up several bugs that would
> have been a embarrassment if they had made their way into the release and
> we are very happy that they were discovered.
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131015/ed44cff4/attachment.html>

From howarth at bromo.med.uc.edu  Thu Oct 17 15:33:22 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Thu, 17 Oct 2013 15:33:22 -0400
Subject: [SciPy-Dev] NumPy 1.8.0rc2 release
In-Reply-To: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
References: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
Message-ID: <20131017193322.GA10151@bromo.med.uc.edu>

On Mon, Oct 14, 2013 at 03:37:22PM -0600, Charles R Harris wrote:
> Hi All,
> 
> NumPy 1.8.0rc2 is up now on
> sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/>.
> Binary builds are included, except for Python 3.3 on windows. Many thanks
> to Ralf for the binaries and to those who found and fixed the bugs in rc1.
> Please test this thoroughly, especially if you have access to one of the
> less common platforms. Testing of rc1 turned up several bugs that would
> have been a embarrassment if they had made their way into the release and
> we are very happy that they were discovered.
> 
> Chuck

Chuck,
   I am seeing one puzzling bahavior with numpy-1.8.0. When starting pymol r4045
against numpy 1.8.0rc2 under python 2.6.8, I get the warning...

/sw/lib/python2.6/site-packages/numpy/oldnumeric/__init__.py:11: ModuleDeprecationWarning: The oldnumeric module will be dropped in Numpy 1.9
  warnings.warn(_msg, ModuleDeprecationWarning)

but this warning doesn't appear when pymol built against python 2.7.5 instead.
Since....

diff -u /sw/lib/python2.6/site-packages/numpy/oldnumeric/__init__.py /sw/lib/python2.7/site-packages/numpy/oldnumeric/__init__.py

shows no differences, I am rather puzzled why python2.6 emits the warning and python2.7 doesn't.
Is this a known issue?`
           Jack

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From argriffi at ncsu.edu  Thu Oct 17 15:39:13 2013
From: argriffi at ncsu.edu (alex)
Date: Thu, 17 Oct 2013 15:39:13 -0400
Subject: [SciPy-Dev] NumPy 1.8.0rc2 release
In-Reply-To: <20131017193322.GA10151@bromo.med.uc.edu>
References: <CAB6mnxJxnG5nPwbpoaMhh1QobSGj9A6=5NcrLRDRimDDgyx9rA@mail.gmail.com>
	<20131017193322.GA10151@bromo.med.uc.edu>
Message-ID: <CAE5GFcKwFizhi3xvz_SsZBKfED0871Z2O0U990wc2ZMWk0h1kg@mail.gmail.com>

On Thu, Oct 17, 2013 at 3:33 PM, Jack Howarth <howarth at bromo.med.uc.edu>
wrote:
>
> On Mon, Oct 14, 2013 at 03:37:22PM -0600, Charles R Harris wrote:
> > Hi All,
> >
> > NumPy 1.8.0rc2 is up now on
> > sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/
>.
> > Binary builds are included, except for Python 3.3 on windows. Many
thanks
> > to Ralf for the binaries and to those who found and fixed the bugs in
rc1.
> > Please test this thoroughly, especially if you have access to one of the
> > less common platforms. Testing of rc1 turned up several bugs that would
> > have been a embarrassment if they had made their way into the release
and
> > we are very happy that they were discovered.
> >
> > Chuck
>
> Chuck,
>    I am seeing one puzzling bahavior with numpy-1.8.0. When starting
pymol r4045
> against numpy 1.8.0rc2 under python 2.6.8, I get the warning...
>
> /sw/lib/python2.6/site-packages/numpy/oldnumeric/__init__.py:11:
ModuleDeprecationWarning: The oldnumeric module will be dropped in Numpy 1.9
>   warnings.warn(_msg, ModuleDeprecationWarning)
>
> but this warning doesn't appear when pymol built against python 2.7.5
instead.
> Since....
>
> diff -u /sw/lib/python2.6/site-packages/numpy/oldnumeric/__init__.py
/sw/lib/python2.7/site-packages/numpy/oldnumeric/__init__.py
>
> shows no differences, I am rather puzzled why python2.6 emits the warning
and python2.7 doesn't.
> Is this a known issue?`

I think this is explained in
http://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x
where it says "Two consequences of the long-term significance of 2.7 are:
[...] A policy decision was made to silence warnings only of interest to
developers. DeprecationWarning and its descendants are now ignored unless
otherwise requested, preventing users from seeing warnings triggered by an
application."

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

From charlesnwoods at gmail.com  Fri Oct 18 12:07:17 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 18 Oct 2013 10:07:17 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <loom.20131014T111120-142@post.gmane.org>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
	<CAAYHtCQgkCnYZ6j2x6FSthgMOMHPk7sUQdRP0V0Nyokx8ozrXg@mail.gmail.com>
	<loom.20131014T111120-142@post.gmane.org>
Message-ID: <CAAYHtCSYDDTOGF-ef5p6+MavpTQaNPnApDG=7-D=tncp+850+g@mail.gmail.com>

On Mon, Oct 14, 2013 at 3:22 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Nathan Woods <charlesnwoods <at> gmail.com> writes:
> [clip]
> > In my opinion, the best way to solve the first problem is
> > to take advantage of the OOP programming style. Functional
> > programming, as used in SLATEC and much of SciPy, is expressly
> > designed to prevent the passing of information around the
> > program through anything other than the functional interface.
> > In FP, f(x) cannot depend on anything other than x, and if it
> > depends on x and y, then it absolutely must be written f(x,y).
> > The current implementation uses global variables to cheat around
> > this restriction, and pass y in through the back door, as it were.
> > A perhaps safer alternative is to define f as a bound method to
> > an object, and use object variables instead of global variables
> > to pass the y,z,... to the function, leaving the interface as
> > f(x), just as Quadpack wants it. There's an example of this in
> > scipy.integrate.nquad, if anyone is interested. This could be
> > fairly easily and safely implemented in Fortran 2003, but that
> > is not as widely supported as I think scipy needs. That leaves
> > either C, or C++.
> [clip]
> > Comments welcome.
>
> What you write above is problematic --- you assume that
> C and Fortran have similar metaprogramming capabilities as Python.
> This is not the case, which makes what you propose above
> impossible.
>
> Bound methods do not exist in C or Fortran, even if allowing for
> OO programming that C++ and Fortran 2000+ bring. Moreover,
> signatures of all functions to be called must be known at compile
> time.
>
> Metaprogramming can be done in principle, but this requires
> on-the-fly code generation, which I believe is not a feasible
> solution here. The solution to the problem at hand must necessarily
> be more restricted.
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

Brian and I have some ideas that will make this idea work in a robust way,
at least using C++. Is there any reason to avoid dependence on C++? If so,
there may still be a way to do it in C. I actually got pretty far trying to
implement something like it in f90, but was stymied by the lack of a real
function pointer, which C has.

N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131018/13c3bf04/attachment.html>

From pav at iki.fi  Fri Oct 18 12:42:13 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 18 Oct 2013 19:42:13 +0300
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <CAAYHtCSYDDTOGF-ef5p6+MavpTQaNPnApDG=7-D=tncp+850+g@mail.gmail.com>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>	<l375g2$hkp$1@ger.gmane.org>	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>	<loom.20131011T112317-488@post.gmane.org>	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>	<CAAYHtCQgkCnYZ6j2x6FSthgMOMHPk7sUQdRP0V0Nyokx8ozrXg@mail.gmail.com>	<loom.20131014T111120-142@post.gmane.org>
	<CAAYHtCSYDDTOGF-ef5p6+MavpTQaNPnApDG=7-D=tncp+850+g@mail.gmail.com>
Message-ID: <l3rocr$6tk$1@ger.gmane.org>

Hi,

18.10.2013 19:07, Nathan Woods kirjoitti:
[clip]
> Brian and I have some ideas that will make this idea work in a robust way,
> at least using C++. Is there any reason to avoid dependence on C++? If so,
> there may still be a way to do it in C. I actually got pretty far trying to
> implement something like it in f90, but was stymied by the lack of a real
> function pointer, which C has.

I'm assuming you are speaking here about passing in function pointers
carrying extra arguments, without using global variables or modifying
QUADPACK code.

Please line out how you would do it in C++. Note that things such as
std::bind and taking addresses of member functions will not help here,
because they require passing in not only a function pointers but also
the binding object separately. This issue is outlined in the C++ FAQ ---
the situation with QUADPACK is analogous to event callbacks:

http://www.parashift.com/c++-faq/memfnptr-vs-fnptr.html

-- 
Pauli Virtanen



From charlesnwoods at gmail.com  Fri Oct 18 13:07:48 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 18 Oct 2013 11:07:48 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <l3rocr$6tk$1@ger.gmane.org>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
	<CAAYHtCQgkCnYZ6j2x6FSthgMOMHPk7sUQdRP0V0Nyokx8ozrXg@mail.gmail.com>
	<loom.20131014T111120-142@post.gmane.org>
	<CAAYHtCSYDDTOGF-ef5p6+MavpTQaNPnApDG=7-D=tncp+850+g@mail.gmail.com>
	<l3rocr$6tk$1@ger.gmane.org>
Message-ID: <CAAYHtCTMxD+K4+-h96Df1HfhA31O7=_8-m8zcTof=VuXCOhDrg@mail.gmail.com>

On Fri, Oct 18, 2013 at 10:42 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Hi,
>
> 18.10.2013 19:07, Nathan Woods kirjoitti:
> [clip]
> > Brian and I have some ideas that will make this idea work in a robust
> way,
> > at least using C++. Is there any reason to avoid dependence on C++? If
> so,
> > there may still be a way to do it in C. I actually got pretty far trying
> to
> > implement something like it in f90, but was stymied by the lack of a real
> > function pointer, which C has.
>
> I'm assuming you are speaking here about passing in function pointers
> carrying extra arguments, without using global variables or modifying
> QUADPACK code.
>
> Please line out how you would do it in C++. Note that things such as
> std::bind and taking addresses of member functions will not help here,
> because they require passing in not only a function pointers but also
> the binding object separately. This issue is outlined in the C++ FAQ ---
> the situation with QUADPACK is analogous to event callbacks:
>
> http://www.parashift.com/c++-faq/memfnptr-vs-fnptr.html
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

Your note at the end was helpful, as that is exactly what we were planning.
It would seem, however, that std::bind may still work, provided that the
function being bound is not an object method. So, given a normal function
f(obj,x,y,z,t) that wraps an object and its method, perhaps bind would be
fine. That does leave some questions about how to eventually implement
recursion, though.

To be honest, I'm starting to wonder if the whole thing would just be
easier to handle with COMMON blocks in F77, which at least aren't quite
global. I don't know what that might do to future parallelization efforts,
but it would work for this. At what point do global variables become the
least-painful answer to this problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131018/bc420c0f/attachment.html>

From charlesnwoods at gmail.com  Fri Oct 18 13:44:14 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 18 Oct 2013 11:44:14 -0600
Subject: [SciPy-Dev] Beginning work on robustly allowing function
 pointers in integrate - quad
In-Reply-To: <CAAYHtCTMxD+K4+-h96Df1HfhA31O7=_8-m8zcTof=VuXCOhDrg@mail.gmail.com>
References: <CAEpsjT426vHixSFySC4w=FA9bb2L6Fd8NvYgQnhUqMce7CbLGA@mail.gmail.com>
	<l375g2$hkp$1@ger.gmane.org>
	<CAAYHtCS9CkR9BcVuNYUaU4Ofhyp5vhOknk_JLv-tBobReyjr5g@mail.gmail.com>
	<loom.20131011T112317-488@post.gmane.org>
	<CAAYHtCSCxF75uf5nO7pXj88=+6+aDPqb15yb_ax2iPtwbW_LLA@mail.gmail.com>
	<CAAYHtCQgkCnYZ6j2x6FSthgMOMHPk7sUQdRP0V0Nyokx8ozrXg@mail.gmail.com>
	<loom.20131014T111120-142@post.gmane.org>
	<CAAYHtCSYDDTOGF-ef5p6+MavpTQaNPnApDG=7-D=tncp+850+g@mail.gmail.com>
	<l3rocr$6tk$1@ger.gmane.org>
	<CAAYHtCTMxD+K4+-h96Df1HfhA31O7=_8-m8zcTof=VuXCOhDrg@mail.gmail.com>
Message-ID: <CAAYHtCS6LrvvCsN4UhhEUbzYY+Hqtj+Bw=nvMHNL6uUck77z8A@mail.gmail.com>

Strike that last. COMMON blocks are pretty much the same thing as global
variable.


On Fri, Oct 18, 2013 at 11:07 AM, Nathan Woods <charlesnwoods at gmail.com>wrote:

>
>
>
> On Fri, Oct 18, 2013 at 10:42 AM, Pauli Virtanen <pav at iki.fi> wrote:
>
>> Hi,
>>
>> 18.10.2013 19:07, Nathan Woods kirjoitti:
>> [clip]
>> > Brian and I have some ideas that will make this idea work in a robust
>> way,
>> > at least using C++. Is there any reason to avoid dependence on C++? If
>> so,
>> > there may still be a way to do it in C. I actually got pretty far
>> trying to
>> > implement something like it in f90, but was stymied by the lack of a
>> real
>> > function pointer, which C has.
>>
>> I'm assuming you are speaking here about passing in function pointers
>> carrying extra arguments, without using global variables or modifying
>> QUADPACK code.
>>
>> Please line out how you would do it in C++. Note that things such as
>> std::bind and taking addresses of member functions will not help here,
>> because they require passing in not only a function pointers but also
>> the binding object separately. This issue is outlined in the C++ FAQ ---
>> the situation with QUADPACK is analogous to event callbacks:
>>
>> http://www.parashift.com/c++-faq/memfnptr-vs-fnptr.html
>>
>> --
>> Pauli Virtanen
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
> Your note at the end was helpful, as that is exactly what we were
> planning. It would seem, however, that std::bind may still work, provided
> that the function being bound is not an object method. So, given a normal
> function f(obj,x,y,z,t) that wraps an object and its method, perhaps bind
> would be fine. That does leave some questions about how to eventually
> implement recursion, though.
>
> To be honest, I'm starting to wonder if the whole thing would just be
> easier to handle with COMMON blocks in F77, which at least aren't quite
> global. I don't know what that might do to future parallelization efforts,
> but it would work for this. At what point do global variables become the
> least-painful answer to this problem?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131018/f2d52d1c/attachment.html>

From debian at delanoe.org  Sat Oct 19 04:24:12 2013
From: debian at delanoe.org (Alexandre =?iso-8859-1?Q?Delano=EB?=)
Date: Sat, 19 Oct 2013 10:24:12 +0200
Subject: [SciPy-Dev] int64 Description in docs.scipy.org
Message-ID: <20131019082412.GA11133@delanoe.org>

Hello all,
I have just subscribed to highlight a misprint in your documentation.

Page http://docs.scipy.org/doc/numpy/user/basics.types.html, according
to your int64 Description, only one integer is allowed between (x,y):
x = 9223372036854775808
y = 9223372036854775807

Of course, x should be "-x" :)

By the way, many thanks for all your job (both documentations and
development).


-- 
                Alexandre Delano?


From ralf.gommers at gmail.com  Sat Oct 19 05:48:31 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 19 Oct 2013 11:48:31 +0200
Subject: [SciPy-Dev] planning 0.13.0 release
In-Reply-To: <CAGY4rcWasL7+xOeGKjPwDfwj4mcQYv1qvdmHT4C54LXQSqszVw@mail.gmail.com>
References: <CABL7CQiS0OL5vnx3PTzNEMvGMqqU5UT7WLWndZhWHXq5vHaHDA@mail.gmail.com>
	<CAGY4rcXhNGU6SxeqA2Y6GXNPONhoxwH0oHBn5ougaJ0mh4ALtA@mail.gmail.com>
	<CABL7CQjghj5yiprmXkZpt_JC1yGQ+y7f6S6S5_+=M6m7gh4tsA@mail.gmail.com>
	<CAGY4rcWasL7+xOeGKjPwDfwj4mcQYv1qvdmHT4C54LXQSqszVw@mail.gmail.com>
Message-ID: <CABL7CQgt28SRe=+2qDa=H7guNtxsEh9=Lm9U=g4iWu1BENHDOg@mail.gmail.com>

On Fri, Oct 11, 2013 at 11:09 AM, David Cournapeau <cournape at gmail.com>wrote:

>
>
>
> On Thu, Oct 10, 2013 at 8:35 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Oct 10, 2013 at 12:55 PM, David Cournapeau <cournape at gmail.com>wrote:
>>
>>> I have tested the current 0.13.x branch on both rh5 and windows with the
>>> MKL, and am happy to report it works perfectly.
>>>
>>> We may want to mention in the notes that we can't compile scipy with gcc
>>> 4.1.* anymore (at least the rh5 version). Is it ok to make a PR to add
>>> those to the release notes ?
>>>
>>
>>  Sure, makes sense to add that.
>>
>
It's a bit late for the PR now since I want to start compiling binaries
within a few hours to get the final release done today. I can just add the
text "Scipy cannot be compiled with gfortran 4.1 anymore (at least on RH5),
likely due to that compiler version not supporting entry constructs well.".
If you have a better suggestion, please let me know.



> What's the reason by the way? I don't remember we broke things on purpose.
>>
>
> No, and I don't know for sure it is a compiler bug: could be a bug on our
> end.
>

> Two problems with gcc 4.1* (on rh5, those are often heavily patched):
>
>  - the entry construct in scipy.linalg.interpolative. As soon as you go
> there, it crashes. Since that's the only entry construct used in scipy, I
> suspect this is just not well supported in gfortran 4.1.
> https://github.com/scipy/scipy/issues/2939. We may want to avoid the
> entry construct ? Don't know how realistic that is. I certainly would not
> consider this a killer for the release, since it can be worked around.
>  - gcc 4.4 is more aggressive in optimizing potentially aliased pointers:
> not using the -fno-strict-aliasing is not an option anymore, it breaks
> cython fused types (lambert is completely broken without it, for example).
> I would argue the latter is a cython bug (I think we should be able to
> compile scipy and numpy wo -fno-strict-aliasing).
>

Did you file a bug for this?

Ralf


>
> cheers,
> David
>
>
>> Ralf
>>
>>
>>
>>>
>>> David
>>>
>>>
>>> On Mon, Oct 7, 2013 at 8:38 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>>>
>>>> Hi all,
>>>>
>>>> This has taken a while, but we're now about ready for the first release
>>>> candidate of 0.13.0. I plan to cut that on Thursday. Please don't commit to
>>>> the 0.13.x branch on Wed or Thu anymore but ping me if anything needs to go
>>>> in there at the last minute.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> 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/20131019/e8c83f4f/attachment.html>

From ralf.gommers at gmail.com  Sat Oct 19 11:09:33 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 19 Oct 2013 17:09:33 +0200
Subject: [SciPy-Dev] int64 Description in docs.scipy.org
In-Reply-To: <20131019082412.GA11133@delanoe.org>
References: <20131019082412.GA11133@delanoe.org>
Message-ID: <CABL7CQijp9bsGFYnAWcKUC2Zwh1WCu6AF0KDK6+DhrA=4wVatQ@mail.gmail.com>

On Sat, Oct 19, 2013 at 10:24 AM, Alexandre Delano? <debian at delanoe.org>wrote:

> Hello all,
> I have just subscribed to highlight a misprint in your documentation.
>
> Page http://docs.scipy.org/doc/numpy/user/basics.types.html, according
> to your int64 Description, only one integer is allowed between (x,y):
> x = 9223372036854775808
> y = 9223372036854775807
>
> Of course, x should be "-x" :)
>

Hi Alexandre, thanks for the report. This was already fixed in master,
commit 9e7f462b0.

Cheers,
Ralf


>
> By the way, many thanks for all your job (both documentations and
> development).
>
>
> --
>                 Alexandre Delano?
> _______________________________________________
> 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/20131019/86495b6e/attachment.html>

From ralf.gommers at gmail.com  Sat Oct 19 17:40:15 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 19 Oct 2013 23:40:15 +0200
Subject: [SciPy-Dev] ANN: SciPy 0.13.0 release
Message-ID: <CABL7CQi5B0qdbWMQBrVwRsZ33BGsV2ATaUCEAbA5rjNjm=iyoQ@mail.gmail.com>

On behalf of the SciPy development team I'm pleased to announce the
availability of SciPy 0.13.0. This release contains some interesting new
features (see highlights below) and half a year's worth of maintenance
work. 65 people contributed to this release.

Some of the highlights are:

  - support for fancy indexing and boolean comparisons with sparse matrices
  - interpolative decompositions and matrix functions in the linalg module
  - two new trust-region solvers for unconstrained minimization

This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or
greater. Support for Python 2.4 and 2.5 has been dropped as of this release.

Sources and binaries can be found at
http://sourceforge.net/projects/scipy/files/scipy/0.13.0/, release notes
are copied below.

Enjoy,
Ralf




==========================
SciPy 0.13.0 Release Notes
==========================

.. contents::

SciPy 0.13.0 is the culmination of 7 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and
better documentation.  There have been a number of deprecations and
API changes in this release, which are documented below.  All users
are encouraged to upgrade to this release, as there are a large number
of bug-fixes and optimizations.  Moreover, our development attention
will now shift to bug-fix releases on the 0.13.x branch, and on adding
new features on the master branch.

This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater.
Highlights of this release are:

  - support for fancy indexing and boolean comparisons with sparse matrices
  - interpolative decompositions and matrix functions in the linalg module
  - two new trust-region solvers for unconstrained minimization


New features
============

``scipy.integrate`` improvements
--------------------------------

N-dimensional numerical integration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A new function `scipy.integrate.nquad`, which provides N-dimensional
integration functionality with a more flexible interface than ``dblquad``
and
``tplquad``, has been added.

``dopri*`` improvements
^^^^^^^^^^^^^^^^^^^^^^^

The intermediate results from the ``dopri`` family of ODE solvers can now be
accessed by a *solout* callback function.


``scipy.linalg`` improvements
-----------------------------

Interpolative decompositions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Scipy now includes a new module `scipy.linalg.interpolative`
containing routines for computing interpolative matrix decompositions
(ID). This feature is based on the ID software package by
P.G. Martinsson, V. Rokhlin, Y. Shkolnisky, and M. Tygert, previously
adapted for Python in the PymatrixId package by K.L. Ho.

Polar decomposition
^^^^^^^^^^^^^^^^^^^

A new function `scipy.linalg.polar`, to compute the polar decomposition
of a matrix, was added.

BLAS level 3 functions
^^^^^^^^^^^^^^^^^^^^^^

The BLAS functions ``symm``, ``syrk``, ``syr2k``, ``hemm``, ``herk`` and
``her2k`` are now wrapped in `scipy.linalg`.

Matrix functions
^^^^^^^^^^^^^^^^

Several matrix function algorithms have been implemented or updated
following
detailed descriptions in recent papers of Nick Higham and his co-authors.
These include the matrix square root (``sqrtm``), the matrix logarithm
(``logm``), the matrix exponential (``expm``) and its Frechet derivative
(``expm_frechet``), and fractional matrix powers
(``fractional_matrix_power``).


``scipy.optimize`` improvements
-------------------------------

Trust-region unconstrained minimization algorithms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The ``minimize`` function gained two trust-region solvers for unconstrained
minimization: ``dogleg`` and ``trust-ncg``.


``scipy.sparse`` improvements
-----------------------------

Boolean comparisons and sparse matrices
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

All sparse matrix types now support boolean data, and boolean operations.
Two
sparse matrices `A` and `B` can be compared in all the expected ways `A <
B`,
`A >= B`, `A != B`, producing similar results as dense Numpy arrays.
Comparisons with dense matrices and scalars are also supported.

CSR and CSC fancy indexing
^^^^^^^^^^^^^^^^^^^^^^^^^^

Compressed sparse row and column sparse matrix types now support fancy
indexing
with boolean matrices, slices, and lists. So where A is a (CSC or CSR)
sparse
matrix, you can do things like::

    >>> A[A > 0.5] = 1  # since Boolean sparse matrices work
    >>> A[:2, :3] = 2
    >>> A[[1,2], 2] = 3


``scipy.sparse.linalg`` improvements
------------------------------------

The new function ``onenormest`` provides a lower bound of the 1-norm of a
linear operator and has been implemented according to Higham and Tisseur
(2000).  This function is not only useful for sparse matrices, but can also
be
used to estimate the norm of products or powers of dense matrices without
explictly building the intermediate matrix.

The multiplicative action of the matrix exponential of a linear operator
(``expm_multiply``) has been implemented following the description in
Al-Mohy
and Higham (2011).

Abstract linear operators (`scipy.sparse.linalg.LinearOperator`) can now be
multiplied, added to each other, and exponentiated, producing new linear
operators. This enables easier construction of composite linear operations.


``scipy.spatial`` improvements
------------------------------

The vertices of a `ConvexHull` can now be accessed via the `vertices`
attribute,
which gives proper orientation in 2-D.


``scipy.signal`` improvements
-----------------------------

The cosine window function `scipy.signal.cosine` was added.


``scipy.special`` improvements
------------------------------

New functions `scipy.special.xlogy` and `scipy.special.xlog1py` were added.
These functions can simplify and speed up code that has to calculate
``x * log(y)`` and give 0 when ``x == 0``.


``scipy.io`` improvements
-------------------------

Unformatted Fortran file reader
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The new class `scipy.io.FortranFile` facilitates reading unformatted
sequential files written by Fortran code.

``scipy.io.wavfile`` enhancements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

`scipy.io.wavfile.write` now accepts a file buffer. Previously it only
accepted a filename.

`scipy.io.wavfile.read` and `scipy.io.wavfile.write` can now handle floating
point WAV files.


``scipy.interpolate`` improvements
----------------------------------

B-spline derivatives and antiderivatives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

`scipy.interpolate.splder` and `scipy.interpolate.splantider` functions
for computing B-splines that represent derivatives and antiderivatives
of B-splines were added.  These functions are also available in the
class-based FITPACK interface as ``UnivariateSpline.derivative`` and
``UnivariateSpline.antiderivative``.


``scipy.stats`` improvements
----------------------------

Distributions now allow using keyword parameters in addition to
positional parameters in all methods.

The function `scipy.stats.power_divergence` has been added for the
Cressie-Read power divergence statistic and goodness of fit test.
Included in this family of statistics is the "G-test"
(http://en.wikipedia.org/wiki/G-test).

`scipy.stats.mood` now accepts multidimensional input.

An option was added to `scipy.stats.wilcoxon` for continuity correction.

`scipy.stats.chisquare` now has an `axis` argument.

`scipy.stats.mstats.chisquare` now has `axis` and `ddof` arguments.


Deprecated features
===================

``expm2`` and ``expm3``
-----------------------

The matrix exponential functions `scipy.linalg.expm2` and
`scipy.linalg.expm3`
are deprecated. All users should use the numerically more robust
`scipy.linalg.expm` function instead.

``scipy.stats`` functions
-------------------------

`scipy.stats.oneway` is deprecated; `scipy.stats.f_oneway` should be used
instead.

`scipy.stats.glm` is deprecated.  `scipy.stats.ttest_ind` is an equivalent
function; more full-featured general (and generalized) linear model
implementations can be found in statsmodels.

`scipy.stats.cmedian` is deprecated; ``numpy.median`` should be used
instead.


Backwards incompatible changes
==============================

LIL matrix assignment
---------------------
Assigning values to LIL matrices with two index arrays now works similarly
as
assigning into ndarrays::

    >>> x = lil_matrix((3, 3))
    >>> x[[0,1,2],[0,1,2]]=[0,1,2]
    >>> x.todense()
    matrix([[ 0.,  0.,  0.],
            [ 0.,  1.,  0.],
            [ 0.,  0.,  2.]])

rather than giving the result::

    >>> x.todense()
    matrix([[ 0.,  1.,  2.],
            [ 0.,  1.,  2.],
            [ 0.,  1.,  2.]])

Users relying on the previous behavior will need to revisit their code.
The previous behavior is obtained by ``x[numpy.ix_([0,1,2],[0,1,2])] = ...`.


Deprecated ``radon`` function removed
-------------------------------------

The ``misc.radon`` function, which was deprecated in scipy 0.11.0, has been
removed.  Users can find a more full-featured ``radon`` function in
scikit-image.


Removed deprecated keywords ``xa`` and ``xb`` from ``stats.distributions``
--------------------------------------------------------------------------

The keywords ``xa`` and ``xb``, which were deprecated since 0.11.0, have
been removed from the distributions in ``scipy.stats``.

Changes to MATLAB file readers / writers
----------------------------------------

The major change is that 1D arrays in numpy now become row vectors (shape
1, N)
when saved to a MATLAB 5 format file.  Previously 1D arrays saved as column
vectors (N, 1).  This is to harmonize the behavior of writing MATLAB 4 and 5
formats, and adapt to the defaults of numpy and MATLAB - for example
``np.atleast_2d`` returns 1D arrays as row vectors.

Trying to save arrays of greater than 2 dimensions in MATLAB 4 format now
raises
an error instead of silently reshaping the array as 2D.

``scipy.io.loadmat('afile')`` used to look for `afile` on the Python system
path
(``sys.path``); now ``loadmat`` only looks in the current directory for a
relative path filename.


Other changes
=============

Security fix: ``scipy.weave`` previously used temporary directories in an
insecure manner under certain circumstances.

Cython is now required to build *unreleased* versions of scipy.
The C files generated from Cython sources are not included in the git repo
anymore.  They are however still shipped in source releases.

The code base received a fairly large PEP8 cleanup.  A ``tox pep8``
command has been added; new code should pass this test command.

Scipy cannot be compiled with gfortran 4.1 anymore (at least on RH5), likely
due to that compiler version not supporting entry constructs well.


Authors
=======

This release contains work by the following people (contributed at least
one patch to this release, names in alphabetical order):

* Jorge Ca?ardo Alastuey +
* Tom Aldcroft +
* Max Bolingbroke +
* Joseph Jon Booker +
* Fran?ois Boulogne
* Matthew Brett
* Christian Brodbeck +
* Per Brodtkorb +
* Christian Brueffer +
* Lars Buitinck
* Evgeni Burovski +
* Tim Cera
* Lawrence Chan +
* David Cournapeau
* Draz?en Luc?anin +
* Alexander J. Dunlap +
* endolith
* Andr? Gaul +
* Christoph Gohlke
* Ralf Gommers
* Alex Griffing +
* Blake Griffith +
* Charles Harris
* Bob Helmbold +
* Andreas Hilboll
* Kat Huang +
* Oleksandr (Sasha) Huziy +
* Gert-Ludwig Ingold +
* Thouis (Ray) Jones
* Juan Luis Cano Rodr?guez +
* Robert Kern
* Andreas Kloeckner +
* Sytse Knypstra +
* Gustav Larsson +
* Denis Laxalde
* Christopher Lee
* Tim Leslie
* Wendy Liu +
* Clemens Novak +
* Takuya Oshima +
* Josef Perktold
* Illia Polosukhin +
* Przemek Porebski +
* Steve Richardson +
* Branden Rolston +
* Skipper Seabold
* Fazlul Shahriar
* Leo Singer +
* Rohit Sivaprasad +
* Daniel B. Smith +
* Julian Taylor
* Louis Thibault +
* Tomas Tomecek +
* John Travers
* Richard Tsai +
* Jacob Vanderplas
* Patrick Varilly
* Pauli Virtanen
* Stefan van der Walt
* Warren Weckesser
* Pedro Werneck +
* Nils Werner +
* Michael Wimmer +
* Nathan Woods +
* Tony S. Yu +

A total of 65 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131019/e215d455/attachment.html>

From scopatz at gmail.com  Sat Oct 19 17:52:25 2013
From: scopatz at gmail.com (Anthony Scopatz)
Date: Sat, 19 Oct 2013 16:52:25 -0500
Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 0.13.0 release
In-Reply-To: <CABL7CQi5B0qdbWMQBrVwRsZ33BGsV2ATaUCEAbA5rjNjm=iyoQ@mail.gmail.com>
References: <CABL7CQi5B0qdbWMQBrVwRsZ33BGsV2ATaUCEAbA5rjNjm=iyoQ@mail.gmail.com>
Message-ID: <CAPk-6T5mNH-PNma25qnqWLAAAzwRDhBuPQ5bP9LkLGm1jvexJw@mail.gmail.com>

Congrats All!


On Sat, Oct 19, 2013 at 4:40 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

> On behalf of the SciPy development team I'm pleased to announce the
> availability of SciPy 0.13.0. This release contains some interesting new
> features (see highlights below) and half a year's worth of maintenance
> work. 65 people contributed to this release.
>
> Some of the highlights are:
>
>   - support for fancy indexing and boolean comparisons with sparse matrices
>   - interpolative decompositions and matrix functions in the linalg module
>   - two new trust-region solvers for unconstrained minimization
>
> This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or
> greater. Support for Python 2.4 and 2.5 has been dropped as of this release.
>
> Sources and binaries can be found at
> http://sourceforge.net/projects/scipy/files/scipy/0.13.0/, release notes
> are copied below.
>
> Enjoy,
> Ralf
>
>
>
>
> ==========================
> SciPy 0.13.0 Release Notes
> ==========================
>
> .. contents::
>
> SciPy 0.13.0 is the culmination of 7 months of hard work. It contains
> many new features, numerous bug-fixes, improved test coverage and
> better documentation.  There have been a number of deprecations and
> API changes in this release, which are documented below.  All users
> are encouraged to upgrade to this release, as there are a large number
> of bug-fixes and optimizations.  Moreover, our development attention
> will now shift to bug-fix releases on the 0.13.x branch, and on adding
> new features on the master branch.
>
> This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or
> greater.
> Highlights of this release are:
>
>   - support for fancy indexing and boolean comparisons with sparse matrices
>   - interpolative decompositions and matrix functions in the linalg module
>   - two new trust-region solvers for unconstrained minimization
>
>
> New features
> ============
>
> ``scipy.integrate`` improvements
> --------------------------------
>
> N-dimensional numerical integration
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> A new function `scipy.integrate.nquad`, which provides N-dimensional
> integration functionality with a more flexible interface than ``dblquad``
> and
> ``tplquad``, has been added.
>
> ``dopri*`` improvements
> ^^^^^^^^^^^^^^^^^^^^^^^
>
> The intermediate results from the ``dopri`` family of ODE solvers can now
> be
> accessed by a *solout* callback function.
>
>
> ``scipy.linalg`` improvements
> -----------------------------
>
> Interpolative decompositions
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Scipy now includes a new module `scipy.linalg.interpolative`
> containing routines for computing interpolative matrix decompositions
> (ID). This feature is based on the ID software package by
> P.G. Martinsson, V. Rokhlin, Y. Shkolnisky, and M. Tygert, previously
> adapted for Python in the PymatrixId package by K.L. Ho.
>
> Polar decomposition
> ^^^^^^^^^^^^^^^^^^^
>
> A new function `scipy.linalg.polar`, to compute the polar decomposition
> of a matrix, was added.
>
> BLAS level 3 functions
> ^^^^^^^^^^^^^^^^^^^^^^
>
> The BLAS functions ``symm``, ``syrk``, ``syr2k``, ``hemm``, ``herk`` and
> ``her2k`` are now wrapped in `scipy.linalg`.
>
> Matrix functions
> ^^^^^^^^^^^^^^^^
>
> Several matrix function algorithms have been implemented or updated
> following
> detailed descriptions in recent papers of Nick Higham and his co-authors.
> These include the matrix square root (``sqrtm``), the matrix logarithm
> (``logm``), the matrix exponential (``expm``) and its Frechet derivative
> (``expm_frechet``), and fractional matrix powers
> (``fractional_matrix_power``).
>
>
> ``scipy.optimize`` improvements
> -------------------------------
>
> Trust-region unconstrained minimization algorithms
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The ``minimize`` function gained two trust-region solvers for unconstrained
> minimization: ``dogleg`` and ``trust-ncg``.
>
>
> ``scipy.sparse`` improvements
> -----------------------------
>
> Boolean comparisons and sparse matrices
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> All sparse matrix types now support boolean data, and boolean operations.
> Two
> sparse matrices `A` and `B` can be compared in all the expected ways `A <
> B`,
> `A >= B`, `A != B`, producing similar results as dense Numpy arrays.
> Comparisons with dense matrices and scalars are also supported.
>
> CSR and CSC fancy indexing
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Compressed sparse row and column sparse matrix types now support fancy
> indexing
> with boolean matrices, slices, and lists. So where A is a (CSC or CSR)
> sparse
> matrix, you can do things like::
>
>     >>> A[A > 0.5] = 1  # since Boolean sparse matrices work
>     >>> A[:2, :3] = 2
>     >>> A[[1,2], 2] = 3
>
>
> ``scipy.sparse.linalg`` improvements
> ------------------------------------
>
> The new function ``onenormest`` provides a lower bound of the 1-norm of a
> linear operator and has been implemented according to Higham and Tisseur
> (2000).  This function is not only useful for sparse matrices, but can
> also be
> used to estimate the norm of products or powers of dense matrices without
> explictly building the intermediate matrix.
>
> The multiplicative action of the matrix exponential of a linear operator
> (``expm_multiply``) has been implemented following the description in
> Al-Mohy
> and Higham (2011).
>
> Abstract linear operators (`scipy.sparse.linalg.LinearOperator`) can now be
> multiplied, added to each other, and exponentiated, producing new linear
> operators. This enables easier construction of composite linear operations.
>
>
> ``scipy.spatial`` improvements
> ------------------------------
>
> The vertices of a `ConvexHull` can now be accessed via the `vertices`
> attribute,
> which gives proper orientation in 2-D.
>
>
> ``scipy.signal`` improvements
> -----------------------------
>
> The cosine window function `scipy.signal.cosine` was added.
>
>
> ``scipy.special`` improvements
> ------------------------------
>
> New functions `scipy.special.xlogy` and `scipy.special.xlog1py` were added.
> These functions can simplify and speed up code that has to calculate
> ``x * log(y)`` and give 0 when ``x == 0``.
>
>
> ``scipy.io`` improvements
> -------------------------
>
> Unformatted Fortran file reader
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The new class `scipy.io.FortranFile` facilitates reading unformatted
> sequential files written by Fortran code.
>
> ``scipy.io.wavfile`` enhancements
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> `scipy.io.wavfile.write` now accepts a file buffer. Previously it only
> accepted a filename.
>
> `scipy.io.wavfile.read` and `scipy.io.wavfile.write` can now handle
> floating
> point WAV files.
>
>
> ``scipy.interpolate`` improvements
> ----------------------------------
>
> B-spline derivatives and antiderivatives
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> `scipy.interpolate.splder` and `scipy.interpolate.splantider` functions
> for computing B-splines that represent derivatives and antiderivatives
> of B-splines were added.  These functions are also available in the
> class-based FITPACK interface as ``UnivariateSpline.derivative`` and
> ``UnivariateSpline.antiderivative``.
>
>
> ``scipy.stats`` improvements
> ----------------------------
>
> Distributions now allow using keyword parameters in addition to
> positional parameters in all methods.
>
> The function `scipy.stats.power_divergence` has been added for the
> Cressie-Read power divergence statistic and goodness of fit test.
> Included in this family of statistics is the "G-test"
> (http://en.wikipedia.org/wiki/G-test).
>
> `scipy.stats.mood` now accepts multidimensional input.
>
> An option was added to `scipy.stats.wilcoxon` for continuity correction.
>
> `scipy.stats.chisquare` now has an `axis` argument.
>
> `scipy.stats.mstats.chisquare` now has `axis` and `ddof` arguments.
>
>
> Deprecated features
> ===================
>
> ``expm2`` and ``expm3``
> -----------------------
>
> The matrix exponential functions `scipy.linalg.expm2` and
> `scipy.linalg.expm3`
> are deprecated. All users should use the numerically more robust
> `scipy.linalg.expm` function instead.
>
> ``scipy.stats`` functions
> -------------------------
>
> `scipy.stats.oneway` is deprecated; `scipy.stats.f_oneway` should be used
> instead.
>
> `scipy.stats.glm` is deprecated.  `scipy.stats.ttest_ind` is an equivalent
> function; more full-featured general (and generalized) linear model
> implementations can be found in statsmodels.
>
> `scipy.stats.cmedian` is deprecated; ``numpy.median`` should be used
> instead.
>
>
> Backwards incompatible changes
> ==============================
>
> LIL matrix assignment
> ---------------------
> Assigning values to LIL matrices with two index arrays now works similarly
> as
> assigning into ndarrays::
>
>     >>> x = lil_matrix((3, 3))
>     >>> x[[0,1,2],[0,1,2]]=[0,1,2]
>     >>> x.todense()
>     matrix([[ 0.,  0.,  0.],
>             [ 0.,  1.,  0.],
>             [ 0.,  0.,  2.]])
>
> rather than giving the result::
>
>     >>> x.todense()
>     matrix([[ 0.,  1.,  2.],
>             [ 0.,  1.,  2.],
>             [ 0.,  1.,  2.]])
>
> Users relying on the previous behavior will need to revisit their code.
> The previous behavior is obtained by ``x[numpy.ix_([0,1,2],[0,1,2])] =
> ...`.
>
>
> Deprecated ``radon`` function removed
> -------------------------------------
>
> The ``misc.radon`` function, which was deprecated in scipy 0.11.0, has been
> removed.  Users can find a more full-featured ``radon`` function in
> scikit-image.
>
>
> Removed deprecated keywords ``xa`` and ``xb`` from ``stats.distributions``
> --------------------------------------------------------------------------
>
> The keywords ``xa`` and ``xb``, which were deprecated since 0.11.0, have
> been removed from the distributions in ``scipy.stats``.
>
> Changes to MATLAB file readers / writers
> ----------------------------------------
>
> The major change is that 1D arrays in numpy now become row vectors (shape
> 1, N)
> when saved to a MATLAB 5 format file.  Previously 1D arrays saved as column
> vectors (N, 1).  This is to harmonize the behavior of writing MATLAB 4 and
> 5
> formats, and adapt to the defaults of numpy and MATLAB - for example
> ``np.atleast_2d`` returns 1D arrays as row vectors.
>
> Trying to save arrays of greater than 2 dimensions in MATLAB 4 format now
> raises
> an error instead of silently reshaping the array as 2D.
>
> ``scipy.io.loadmat('afile')`` used to look for `afile` on the Python
> system path
> (``sys.path``); now ``loadmat`` only looks in the current directory for a
> relative path filename.
>
>
> Other changes
> =============
>
> Security fix: ``scipy.weave`` previously used temporary directories in an
> insecure manner under certain circumstances.
>
> Cython is now required to build *unreleased* versions of scipy.
> The C files generated from Cython sources are not included in the git repo
> anymore.  They are however still shipped in source releases.
>
> The code base received a fairly large PEP8 cleanup.  A ``tox pep8``
> command has been added; new code should pass this test command.
>
> Scipy cannot be compiled with gfortran 4.1 anymore (at least on RH5),
> likely
> due to that compiler version not supporting entry constructs well.
>
>
> Authors
> =======
>
> This release contains work by the following people (contributed at least
> one patch to this release, names in alphabetical order):
>
> * Jorge Ca?ardo Alastuey +
> * Tom Aldcroft +
> * Max Bolingbroke +
> * Joseph Jon Booker +
> * Fran?ois Boulogne
> * Matthew Brett
> * Christian Brodbeck +
> * Per Brodtkorb +
> * Christian Brueffer +
> * Lars Buitinck
> * Evgeni Burovski +
> * Tim Cera
> * Lawrence Chan +
> * David Cournapeau
> * Draz?en Luc?anin +
> * Alexander J. Dunlap +
> * endolith
> * Andr? Gaul +
> * Christoph Gohlke
> * Ralf Gommers
> * Alex Griffing +
> * Blake Griffith +
> * Charles Harris
> * Bob Helmbold +
> * Andreas Hilboll
> * Kat Huang +
> * Oleksandr (Sasha) Huziy +
> * Gert-Ludwig Ingold +
> * Thouis (Ray) Jones
> * Juan Luis Cano Rodr?guez +
> * Robert Kern
> * Andreas Kloeckner +
> * Sytse Knypstra +
> * Gustav Larsson +
> * Denis Laxalde
> * Christopher Lee
> * Tim Leslie
> * Wendy Liu +
> * Clemens Novak +
> * Takuya Oshima +
> * Josef Perktold
> * Illia Polosukhin +
> * Przemek Porebski +
> * Steve Richardson +
> * Branden Rolston +
> * Skipper Seabold
> * Fazlul Shahriar
> * Leo Singer +
> * Rohit Sivaprasad +
> * Daniel B. Smith +
> * Julian Taylor
> * Louis Thibault +
> * Tomas Tomecek +
> * John Travers
> * Richard Tsai +
> * Jacob Vanderplas
> * Patrick Varilly
> * Pauli Virtanen
> * Stefan van der Walt
> * Warren Weckesser
> * Pedro Werneck +
> * Nils Werner +
> * Michael Wimmer +
> * Nathan Woods +
> * Tony S. Yu +
>
> A total of 65 people contributed to this release.
> People with a "+" by their names contributed a patch for the first time.
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131019/f74b7ccb/attachment.html>

From robfalck at gmail.com  Tue Oct 22 21:35:44 2013
From: robfalck at gmail.com (Rob Falck)
Date: Tue, 22 Oct 2013 21:35:44 -0400
Subject: [SciPy-Dev] [SciPy-User] Linear Programming via Simplex
	Algorithm
In-Reply-To: <CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>
References: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>
	<CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>
Message-ID: <CAEQapLqNzLvBm4Dcn6RrrKtZNFxra4tztYALtADKS0-wq6D0Hg@mail.gmail.com>

Hello Ralf,

First, my apologies that this went to SciPy Users, it was intended for the
Developers list and I'm redirecting this message there.

On Tue, Oct 22, 2013 at 2:08 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>
>
> On Mon, Oct 21, 2013 at 3:59 AM, Rob Falck <robfalck at gmail.com> wrote:
>
>> Hello,
>>
>> I've spent some time recently polishing a simplex-based linear
>> programming function.  I've seen traffic from time to time about including
>> such functionality in scipy.optimize but it always seems to have been
>> closed without inclusion.
>>
>
> Hi Rob, I assume you have seen https://github.com/scipy/scipy/pull/218then? Looks like it's functionality that we'd like to see in scipy.optimize
> but needs some more effort than anyone has been willing to spend so far.
>

I've seen pull request 218 and parts of it are very good.  The simplex
method itself is lean, but it doesn't support equality or lower-bound
constraints.  It also differs in that it returns a new class LPResult.  In
my approach I had tried to stay with the general scipy.optimize.Result
setup and use only those fields which are applicable.  Do you have any
guidance on which way would be preferable?


> My intent was to develop a linear-programming routine that, given a
>> non-standard linear programming problem, generates a canonical tableau and
>> solves it using the simplex algorithm. By nonstandard I mean that variables
>> may have negative values, and three types of constraints are supported
>> (lower-bound, upper-bound, and equality).
>>
>> I've named a top-level routine "linprog".  I suspect in the future that
>> scipy may include other algorithms besides the simplex to solve linear
>> programming problems, in which case linprog would serve as the main
>> function (similarly to the way minimize serves as the interfact to all nlp
>> routines).
>>
>
> A generic `linprog` interface sounds like a good idea. It looks like the
> API and the current implementation are fairly specific to your lpsimplex
> algorithm however. Compare how little minimize() does to the 400 LoC in
> linprog(). If you want to make linprog() generic maybe it would help if you
> would consider how you could integrate the algorithm of
> https://github.com/scipy/scipy/pull/218 into it without changing the API
> besides adding a "method" keyword.
>

I'd be happy to incorporate both, although theres a good bit of overlap
between the two contributions. I'd hate for that author's work to go
unused, so perhaps I can replace the core simplex solving routine of my
code with that one.  It's leaner and honestly I like a few things about it
better than mine.  That way my top-level simplex routine would rework a
problem with lower-bound and equality constraints into standard form, to be
solved by that underlying simplex routine.

Also, my implementation of linprog is long because it contains a great deal
of error checking.  I will rework a top-level linprog interface which
leaves most of the error-checking to the underlying linear programming
routines.



> For example, consider a relatively simple problem:
>>
>> Maximize:  f = 3*x[0] + 2*x[1]
>> Subject to:  2*x[0] + 1*x[1] <= 10
>>                   1*x[0] + 1*x[1] <= 8
>>                   1*x[0] + 0*x[1] <= 4
>>
>> where: 0 <= x[0] <= inf
>>           0 <= x[1] <= inf
>>
>> The inputs are such that the objective is specified by array c where f =
>> dot(c,x).
>> We have three upper-bound constraints, which we define using dot(A_ub,x)
>> <= b_ub
>>
>> >>>c = [3,2]
>> >>>b_ub = [10,8,4]
>> >>>A_ub = [[2,1],
>> >>>            [1,1],
>> >>>            [1,0]]
>> >>>res=linprog(c=c,A_ub=A_ub,b_ub=b_ub,objtype='max',disp=True)
>> Optimization terminated successfully.
>>          Current function value: 18.000000
>>          Iterations: 3
>>
>> I've written a suite of unit tests and have documented all functions.
>>  It's somewhat non-standard but I've also included two callback functions.
>>  linprog_verbose_callback prints the simplex tableau, pivot element, and
>> basic variables at each iteration of the simplex method.
>> linprog_terse_callback simply prints the value of the solution vector x at
>> each iteration.
>>
>
> Do the callbacks need to be separate public functions? My impression is
> no. And what about lpsimplex()? If linprog() is the generic interface maybe
> lpsimplex can be private?
>
>

I felt like a verbose callback that displays the simplex tableau at each
iteration would be useful for people who want it.  I can remove it and
include it as an example callback in documentation or something like that.

lpsimplex will be made private (or more likely replaced by the
implementation from pull request 218)

The only top-level function will be linprog, which like minimize, will
support a "method" argument.  For now, the only valid method will be
"simplex".



>  The code is currently in the linprog branch at
>> https://github.com/robfalck/scipy/tree/linprog/scipy
>> (relevant files are scipy/optimize/linprog.py,
>> scipy/optimize/__init__.py, and scipy/optimize/tests/test_linprog.py)
>>
>
> This looks pretty good from a quick browse (disclaimer: I haven't tried to
> understand your algorithm in detail).
>
>
>>  I welcome constructive criticism of the algorithm.  It's been designed
>> to detect degenerate cases due to unbounded problems, and it has a
>> relatively basic way to avoid cycling in the simplex solution.
>>
>
> Have you benchmarked your algorithm against other implementations? And/or
> checked the efficiency (typical should be 2N to 3N iterations, with N the
> size of the constraint matrix)?
>


I've checked my algorithm against some textbook examples and a few randomly
generated cases from
http://demonstrations.wolfram.com/TwoPhaseSimplexMethod/

Basically there are two important things I had to get right.  First, was
the linprog routine (to become _linprog_simplex) creating a correct tableau
given the problem at hand?  Secondly, given that the tableau was correct
was the algorithm choosing the correct pivots to get to the solution as
quickly as possible.  In both cases, from all my testing thus far, the
answer has been yes.  I've checked a basic cycling case and was able to
successfully break out of the cycling to converge to the correct solution,
although I wouldn't say my method of avoiding cycling is advanced.  If
someone has a relatively complex example to test this against, I'd be happy
to try it.

I doubt this implementaiton will be fast with dozens of variables and
constraints, but I don't have a good feeling for where the maximum
appropriate problem size should be.



> If there's interest in including this I'd be happy to proceed with
>> submitting a PR.  I still have a bit of cleanup to perform but it's
>> relatively close to being ready (pep8 compliance, etc)
>>
>
> Sounds good to me!
>
> In terms of completing the cleanup, I think fixing line length to 80 chars
> and breaking up linprog() into smaller logical units would be good to
> before submitting imho. Also, linprog.py should be renamed to _linprog.py.
>

I'll will work on this and submit a pull request when I'm satisfied with
the state of things.  I will keep you posted.


> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>


-- 
- Rob Falck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131022/bc09a073/attachment.html>

From pav at iki.fi  Wed Oct 23 13:38:26 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 23 Oct 2013 20:38:26 +0300
Subject: [SciPy-Dev] [SciPy-User] Linear Programming via Simplex
	Algorithm
In-Reply-To: <CAEQapLqNzLvBm4Dcn6RrrKtZNFxra4tztYALtADKS0-wq6D0Hg@mail.gmail.com>
References: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>	<CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>
	<CAEQapLqNzLvBm4Dcn6RrrKtZNFxra4tztYALtADKS0-wq6D0Hg@mail.gmail.com>
Message-ID: <l491i9$dqp$1@ger.gmane.org>

Hi,

23.10.2013 04:35, Rob Falck kirjoitti:
[clip]
> I've spent some time recently polishing a simplex-based linear
> programming function.  I've seen traffic from time to time about including
> such functionality in scipy.optimize but it always seems to have been
> closed without inclusion.

One important question: is this algorithm regarded as useful and robust
enough by people in the know?

Are there existing more sophisticated LP solver codes with compatible
licences?

Does the LP simplex method win over nonlinear solvers such as COBYLA?

scipy.optimize currently contains many "naive" solvers, which is not a
completely happy situation. Of course, something is better than nothing,
but if possible, I'd prefer one sophisticated code over many naive
methods. I'm not an expert in LP, so I can't judge very well myself here.

-- 
Pauli Virtanen



From warren.weckesser at gmail.com  Wed Oct 23 14:20:45 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Wed, 23 Oct 2013 14:20:45 -0400
Subject: [SciPy-Dev] Bug in stats.fisher_exact
Message-ID: <CAGzF1udyagbL6byHyu9gzD+rbr-9NCZWvw2hWGrLtQPiqS1phw@mail.gmail.com>

A problem with stats.fisher_exact was reported on stackoverflow:

http://stackoverflow.com/questions/19548854/python-scipy-stats-module-valueerror-axis-entry-is-out-of-bounds

The culprit appears to be this line:
    https://github.com/scipy/scipy/blame/master/scipy/stats/stats.py#L2633

I assume that `np.max(pexact, pmode)` should be
`np.maximum(pexact, pmode)`.  Could someone more familiar with this
calculation confirm this?

Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131023/9a69f878/attachment.html>

From warren.weckesser at gmail.com  Wed Oct 23 14:50:34 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Wed, 23 Oct 2013 14:50:34 -0400
Subject: [SciPy-Dev] Bug in stats.fisher_exact
In-Reply-To: <CAGzF1udyagbL6byHyu9gzD+rbr-9NCZWvw2hWGrLtQPiqS1phw@mail.gmail.com>
References: <CAGzF1udyagbL6byHyu9gzD+rbr-9NCZWvw2hWGrLtQPiqS1phw@mail.gmail.com>
Message-ID: <CAGzF1ufGtUSrxxgSiK3Dad0JhWqrKgmK1_8LmgHONh_zZw8zBg@mail.gmail.com>

On Wed, Oct 23, 2013 at 2:20 PM, Warren Weckesser <
warren.weckesser at gmail.com> wrote:

> A problem with stats.fisher_exact was reported on stackoverflow:
>
> http://stackoverflow.com/questions/19548854/python-scipy-stats-module-valueerror-axis-entry-is-out-of-bounds
>
> The culprit appears to be this line:
>     https://github.com/scipy/scipy/blame/master/scipy/stats/stats.py#L2633
>
> I assume that `np.max(pexact, pmode)` should be
> `np.maximum(pexact, pmode)`.  Could someone more familiar with this
> calculation confirm this?
>
>

I created a github issue for this:
https://github.com/scipy/scipy/issues/3014



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

From robfalck at gmail.com  Thu Oct 24 18:17:21 2013
From: robfalck at gmail.com (Rob Falck)
Date: Thu, 24 Oct 2013 18:17:21 -0400
Subject: [SciPy-Dev] [SciPy-User] Linear Programming via Simplex
	Algorithm
In-Reply-To: <l491i9$dqp$1@ger.gmane.org>
References: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>
	<CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>
	<CAEQapLqNzLvBm4Dcn6RrrKtZNFxra4tztYALtADKS0-wq6D0Hg@mail.gmail.com>
	<l491i9$dqp$1@ger.gmane.org>
Message-ID: <CAEQapLpUgix44D02Qq+bBopduzOASuuZJZ+o7Y7Tqe+sdXWN4g@mail.gmail.com>

Pauli,

My understanding is that the simplex algorithm is used in "real-world"
applications.  The other most-common linear-programming method is probably
the interior point method.  There is a package lpsolve, which is quite good
and has a python wrapper, but it is under the LGPL license.  At some point
in the future it would be nice to mimic the linprog capability of matlab,
which gives the user the option of which linear programming method to use.

The LP simplex method is different than COBYLA in that it ONLY solves
linear problems, whereas COBYLA is essentially a sequential linear
programming method for solving nonlinear problems.  My understanding is
that linear programming techniques are generally faster at solving linear
problems than nlp methods.  For instance, Excel's solver routine has an
"assume linear" option that lets it branch into a linear programming mode
for faster results. (
http://www.solver.com/standard-excel-solver-limitations-nonlinear-optimization
)

Personally I think it's good to have a suite of several "simple" solvers.
 There are times when nelder-mead is the perferable solution method, and
there are other times when BFGS or COBYLA are the preferable method.
 Having several relatively simple solvers lets the user better understand
the limitations of each rather than trying to figure out the logic of one
massive solver routine.  In fact, one of the reasons I'm interested in
getting a linear programming routine into Scipy is that so a new sequential
linear programming method can be built upon it.  COBYLA is essentially
doing that now, but having more control over bounds and constraints would
be nice.

-Rob


On Wed, Oct 23, 2013 at 1:38 PM, Pauli Virtanen <pav at iki.fi> wrote:

> Hi,
>
> 23.10.2013 04:35, Rob Falck kirjoitti:
> [clip]
> > I've spent some time recently polishing a simplex-based linear
> > programming function.  I've seen traffic from time to time about
> including
> > such functionality in scipy.optimize but it always seems to have been
> > closed without inclusion.
>
> One important question: is this algorithm regarded as useful and robust
> enough by people in the know?
>
> Are there existing more sophisticated LP solver codes with compatible
> licences?
>
> Does the LP simplex method win over nonlinear solvers such as COBYLA?
>
> scipy.optimize currently contains many "naive" solvers, which is not a
> completely happy situation. Of course, something is better than nothing,
> but if possible, I'd prefer one sophisticated code over many naive
> methods. I'm not an expert in LP, so I can't judge very well myself here.
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
- Rob Falck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131024/23d446c7/attachment.html>

From cjordan1 at uw.edu  Fri Oct 25 01:20:40 2013
From: cjordan1 at uw.edu (Christopher Jordan-Squire)
Date: Thu, 24 Oct 2013 22:20:40 -0700
Subject: [SciPy-Dev] [SciPy-User] Linear Programming via Simplex
	Algorithm
In-Reply-To: <l491i9$dqp$1@ger.gmane.org>
References: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>
	<CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>
	<CAEQapLqNzLvBm4Dcn6RrrKtZNFxra4tztYALtADKS0-wq6D0Hg@mail.gmail.com>
	<l491i9$dqp$1@ger.gmane.org>
Message-ID: <CAEJxiFoTsdRVsAP5kq9tw02b0kB51FB7DdLUkYpBFbLrv-si5Q@mail.gmail.com>

Rob--Thanks for posting the code. I've been hoping an LP solver would
make it into scipy.optimize for awhile. Like Rob said, they're
important both on their own and as subproblems in other algorithms,
such as integer LP arising from approximation algorithms for
combinatorial optimization problems. Successive linear programming has
also had a lot of success in some industries. Rob's also right that
it's generally better to use an LP solver on an LP problem than a
non-linear solver. If comparing implementations of similar quality,
then an LP solver will usually be faster and more accurate.

Anyways, I wouldn't consider myself an expert, but I am semi-informed.
For people not familiar with linear programming, it's probably good to
mention a few important facts about LP's.

The tl;dr is LP solvers are really complicated. Including a basic one
in Scipy is possible, especially with iterative improvements over
time, but having even a basic LP solver with all the major options
included for a standard LP solver would be a pretty huge undertaking.
Details about why are below. Having just the simplex (and dual
simplex? What happened to that PR?) would be nice, but it's important
to be up front about them being relatively untested, almost certainly
not very robust, and (I assume) using dense matrices instead of sparse
matrices.

<general LP info>

--Existing open source implementations are generally about an order of
magnitude slower than commercial implementations. [1] [2] show this,
but those are specifically talking about integer and mixed integer
LP's.

--The main commercial implementations are Cplex, Gurobi, Mosek, and
Xpress. As far as I know their interfaces are rather dissimilar,
and--unfortunately--many OR people use a bafflingly large array of
DSL's to build their LPs, such as AMPL, GAMS, Mosle (Xpress), and OPL
(Cplex).

--There are 3 major algorithms for solving general LP's: simplex, dual
simplex, and barrier. The simplex and dual simplex methods will, for
large-scale problems, use sparse direct linear algebra solvers, while
barrier methods can, depending on the implementation, use sparse
direct or iterative solvers.

--There are also a whole host of algorithms for efficiently solving
LP's with more structure, such as network flow LP's. These include
primal-dual method (different from primal-dual interior point method)
and auction algorithms. As I understand it, commercial LP solvers
generally do some checking to recognize if that kind of structure is
present.

--Mature LP implementations include support for large, sparse LP's,
which uses some LP-specific sparse matrix techniques [3]. They also
include presolving, but the details of that are usually proprietary.
These are a huge deal, but a standard reference says "Relatively
little information about presolving techniques has appeared in the
literature, in part because they have commercial value as an important
component of linear programming software." [4] Similarly, any time
iterative solvers are used the choice of preconditioner can be a big
deal.

--Mature implementations are also good at dealing with various kinds
of degeneracy and detecting infeasibility and unboundedness.

--All of the above refers only to LP's. Integer LP's and Mixed Integer
LP's get (much) more complicated. For example, Frank Hutter at UBC has
several papers on using an optimization algorithm just to find the
best set of configurations for Cplex for a mixed integer linear
program.

[1]http://www.gurobi.com/pdf/Benchmarks.pdf, slide 16
[2]http://scip.zib.de/
[3]http://www.stanford.edu/class/msande318/notes/notes05-updates.pdf
[4]Nocedal and Wright, Nonlinear Optimization 2nd edition, page 388

</general LP info>

Here are some specific comments on Rob's code.

--What is the cycle variable?
--I'm not a fan of matlab, but if you're going to call it linprog it
might be nice to have the same interface at matlab's
--I can't think of a good reason, either theoretical or practical, to
use both A_lb and A_up
--Similarly, I think the objective type (min or max) isn't worth
including since you can just take the negative of the cost vector
--linprog looks like it contains a lot of code that looks very
similar. Could that be refactored out into some loops and/or function
calls, to increase clarity, conciseness, and maintainability?
--What is an artificial variable?
--What is it you're doing to prevent cycling? (i.e., can you provide a
reference? I believe there are a number of different cycling rules, so
there's some ambiguity.)

 -Chris

On Wed, Oct 23, 2013 at 10:38 AM, Pauli Virtanen <pav at iki.fi> wrote:
> Hi,
>
> 23.10.2013 04:35, Rob Falck kirjoitti:
> [clip]
>> I've spent some time recently polishing a simplex-based linear
>> programming function.  I've seen traffic from time to time about including
>> such functionality in scipy.optimize but it always seems to have been
>> closed without inclusion.
>
> One important question: is this algorithm regarded as useful and robust
> enough by people in the know?
>
> Are there existing more sophisticated LP solver codes with compatible
> licences?
>
> Does the LP simplex method win over nonlinear solvers such as COBYLA?
>
> scipy.optimize currently contains many "naive" solvers, which is not a
> completely happy situation. Of course, something is better than nothing,
> but if possible, I'd prefer one sophisticated code over many naive
> methods. I'm not an expert in LP, so I can't judge very well myself here.
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev


From robfalck at gmail.com  Fri Oct 25 07:04:14 2013
From: robfalck at gmail.com (Rob Falck)
Date: Fri, 25 Oct 2013 07:04:14 -0400
Subject: [SciPy-Dev] [SciPy-User] Linear Programming via Simplex
	Algorithm
In-Reply-To: <CAEJxiFoTsdRVsAP5kq9tw02b0kB51FB7DdLUkYpBFbLrv-si5Q@mail.gmail.com>
References: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>
	<CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>
	<CAEQapLqNzLvBm4Dcn6RrrKtZNFxra4tztYALtADKS0-wq6D0Hg@mail.gmail.com>
	<l491i9$dqp$1@ger.gmane.org>
	<CAEJxiFoTsdRVsAP5kq9tw02b0kB51FB7DdLUkYpBFbLrv-si5Q@mail.gmail.com>
Message-ID: <CAEQapLomy8kLrVzcRAhgdx8NftbsOK84qJ0O-1m_5d5dZ16Z5A@mail.gmail.com>

Chris,

Thanks for the information.  As for your specific questions:



--What is the cycle variable?
>

 Cycle goes to one when the tableau reverts to its original form (the
iteration has begun to cycle rather than converging to a solution).  It's a
pretty crude solution that I'm currently revamping.  Right now I'm
comparing the current tableau to the original, but as you can imagine, this
is probably not at all ideal for larger problems.  I'm currently looking
into a more efficient way to detect cycling.

--I'm not a fan of matlab, but if you're going to call it linprog it
> might be nice to have the same interface at matlab's

--I can't think of a good reason, either theoretical or practical, to
> use both A_lb and A_up

--Similarly, I think the objective type (min or max) isn't worth
> including since you can just take the negative of the cost vector
>

Thats understandable.  My thought was to make the interface as explicit as
possible, but I can remove those options.  It would certainly simplify the
code somewhat.


> --linprog looks like it contains a lot of code that looks very
> similar. Could that be refactored out into some loops and/or function
> calls, to increase clarity, conciseness, and maintainability?
>

I'm currently in the process of simplifying things.  The final form should
be much more clear.


> --What is an artificial variable?
>

In a two-phase simplex method, an artificial variable essentially acts as
an "offset" that allows you to find a basic feasible solution when the
origin (x=0) isn't a basic feasible solution (i.e. isn't a vertex of the
feasible region.)  In the phase one problem, a separate objective is used
in which each artificial variable has a penalty of 1.  If the problem is
feasible, then at the end of phase 1 the phase-one objective will be zero,
and the initial basic feasible solution for phase 2 will be a vertex of the
feasible region.

Wolfram actually has a very good demonstration of the two phase simplex
method where they start the phase 1 problem with m artificial variables:
http://demonstrations.wolfram.com/TwoPhaseSimplexMethod/


> --What is it you're doing to prevent cycling? (i.e., can you provide a
> reference? I believe there are a number of different cycling rules, so
> there's some ambiguity.)


At the moment, if cycling is detected, I'm choosing a different pivot
element.  By default the pivot column is the column with the most negative
coefficient in the objective row of the tableau.  The pivot row is then
chosen such that it minimizes b[row]/a[row,pivcol].  In theory choosing
this combination takes to you the optimal solution as quickly as possible.
 To avoid cycling I'm choosing a slightly less optimal path to perturb the
algorithm off of the cyclic sequence. I'll try to find a formal reference
for this...this one was taken from the notes of a course on optimization.

Rob


On Fri, Oct 25, 2013 at 1:20 AM, Christopher Jordan-Squire
<cjordan1 at uw.edu>wrote:

> Rob--Thanks for posting the code. I've been hoping an LP solver would
> make it into scipy.optimize for awhile. Like Rob said, they're
> important both on their own and as subproblems in other algorithms,
> such as integer LP arising from approximation algorithms for
> combinatorial optimization problems. Successive linear programming has
> also had a lot of success in some industries. Rob's also right that
> it's generally better to use an LP solver on an LP problem than a
> non-linear solver. If comparing implementations of similar quality,
> then an LP solver will usually be faster and more accurate.
>
> Anyways, I wouldn't consider myself an expert, but I am semi-informed.
> For people not familiar with linear programming, it's probably good to
> mention a few important facts about LP's.
>
> The tl;dr is LP solvers are really complicated. Including a basic one
> in Scipy is possible, especially with iterative improvements over
> time, but having even a basic LP solver with all the major options
> included for a standard LP solver would be a pretty huge undertaking.
> Details about why are below. Having just the simplex (and dual
> simplex? What happened to that PR?) would be nice, but it's important
> to be up front about them being relatively untested, almost certainly
> not very robust, and (I assume) using dense matrices instead of sparse
> matrices.
>
> <general LP info>
>
> --Existing open source implementations are generally about an order of
> magnitude slower than commercial implementations. [1] [2] show this,
> but those are specifically talking about integer and mixed integer
> LP's.
>
> --The main commercial implementations are Cplex, Gurobi, Mosek, and
> Xpress. As far as I know their interfaces are rather dissimilar,
> and--unfortunately--many OR people use a bafflingly large array of
> DSL's to build their LPs, such as AMPL, GAMS, Mosle (Xpress), and OPL
> (Cplex).
>
> --There are 3 major algorithms for solving general LP's: simplex, dual
> simplex, and barrier. The simplex and dual simplex methods will, for
> large-scale problems, use sparse direct linear algebra solvers, while
> barrier methods can, depending on the implementation, use sparse
> direct or iterative solvers.
>
> --There are also a whole host of algorithms for efficiently solving
> LP's with more structure, such as network flow LP's. These include
> primal-dual method (different from primal-dual interior point method)
> and auction algorithms. As I understand it, commercial LP solvers
> generally do some checking to recognize if that kind of structure is
> present.
>
> --Mature LP implementations include support for large, sparse LP's,
> which uses some LP-specific sparse matrix techniques [3]. They also
> include presolving, but the details of that are usually proprietary.
> These are a huge deal, but a standard reference says "Relatively
> little information about presolving techniques has appeared in the
> literature, in part because they have commercial value as an important
> component of linear programming software." [4] Similarly, any time
> iterative solvers are used the choice of preconditioner can be a big
> deal.
>
> --Mature implementations are also good at dealing with various kinds
> of degeneracy and detecting infeasibility and unboundedness.
>
> --All of the above refers only to LP's. Integer LP's and Mixed Integer
> LP's get (much) more complicated. For example, Frank Hutter at UBC has
> several papers on using an optimization algorithm just to find the
> best set of configurations for Cplex for a mixed integer linear
> program.
>
> [1]http://www.gurobi.com/pdf/Benchmarks.pdf, slide 16
> [2]http://scip.zib.de/
> [3]http://www.stanford.edu/class/msande318/notes/notes05-updates.pdf
> [4]Nocedal and Wright, Nonlinear Optimization 2nd edition, page 388
>
> </general LP info>
>
> Here are some specific comments on Rob's code.
>
> --What is the cycle variable?
> --I'm not a fan of matlab, but if you're going to call it linprog it
> might be nice to have the same interface at matlab's
> --I can't think of a good reason, either theoretical or practical, to
> use both A_lb and A_up
> --Similarly, I think the objective type (min or max) isn't worth
> including since you can just take the negative of the cost vector
> --linprog looks like it contains a lot of code that looks very
> similar. Could that be refactored out into some loops and/or function
> calls, to increase clarity, conciseness, and maintainability?
> --What is an artificial variable?
> --What is it you're doing to prevent cycling? (i.e., can you provide a
> reference? I believe there are a number of different cycling rules, so
> there's some ambiguity.)
>
>  -Chris
>
> On Wed, Oct 23, 2013 at 10:38 AM, Pauli Virtanen <pav at iki.fi> wrote:
> > Hi,
> >
> > 23.10.2013 04:35, Rob Falck kirjoitti:
> > [clip]
> >> I've spent some time recently polishing a simplex-based linear
> >> programming function.  I've seen traffic from time to time about
> including
> >> such functionality in scipy.optimize but it always seems to have been
> >> closed without inclusion.
> >
> > One important question: is this algorithm regarded as useful and robust
> > enough by people in the know?
> >
> > Are there existing more sophisticated LP solver codes with compatible
> > licences?
> >
> > Does the LP simplex method win over nonlinear solvers such as COBYLA?
> >
> > scipy.optimize currently contains many "naive" solvers, which is not a
> > completely happy situation. Of course, something is better than nothing,
> > but if possible, I'd prefer one sophisticated code over many naive
> > methods. I'm not an expert in LP, so I can't judge very well myself here.
> >
> > --
> > Pauli Virtanen
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > 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
>



-- 
- Rob Falck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131025/da9e8e32/attachment.html>

From matthew.brett at gmail.com  Fri Oct 25 10:54:22 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 25 Oct 2013 07:54:22 -0700
Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 0.13.0 release
In-Reply-To: <CABL7CQi5B0qdbWMQBrVwRsZ33BGsV2ATaUCEAbA5rjNjm=iyoQ@mail.gmail.com>
References: <CABL7CQi5B0qdbWMQBrVwRsZ33BGsV2ATaUCEAbA5rjNjm=iyoQ@mail.gmail.com>
Message-ID: <CAH6Pt5ogO_YDo3+ahJ_we+nD87=a6mpkhf-=ye-=21hL0Gq2yA@mail.gmail.com>

Hi,

On Sat, Oct 19, 2013 at 2:40 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> On behalf of the SciPy development team I'm pleased to announce the
> availability of SciPy 0.13.0. This release contains some interesting new
> features (see highlights below) and half a year's worth of maintenance work.
> 65 people contributed to this release.
>
> Some of the highlights are:
>
>   - support for fancy indexing and boolean comparisons with sparse matrices
>   - interpolative decompositions and matrix functions in the linalg module
>   - two new trust-region solvers for unconstrained minimization
>
> This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater.
> Support for Python 2.4 and 2.5 has been dropped as of this release.
>
> Sources and binaries can be found at
> http://sourceforge.net/projects/scipy/files/scipy/0.13.0/, release notes are
> copied below.

Sorry to be slow to the party, but I just wanted to point out:

git shortlog -ns v0.12.0..v0.13.0

   389  Pauli Virtanen
   225  Ralf Gommers
   105  alex
   104  Blake Griffith
   101  Warren Weckesser
...

So - to y'all, but in particular to Pauli and Ralf - thank you for
this all this great, patient, organized work.

A deep bow,

Matthew


From ralf.gommers at gmail.com  Sat Oct 26 06:05:21 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 26 Oct 2013 12:05:21 +0200
Subject: [SciPy-Dev] deprecating stats.randwppf and randwcdf
Message-ID: <CABL7CQjzDY4d_nqxmfYmbopYGgbLY_3+S8UUBObw=02XN-6fzg@mail.gmail.com>

Hi,

https://github.com/scipy/scipy/pull/3007 proposes to deprecate
stats.randwppf and stats.randwcdf. That makes a lot of sense, so we'll
merge that PR in a few days unless someone objects.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131026/af78a798/attachment.html>

From charlesr.harris at gmail.com  Wed Oct 30 17:49:56 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 30 Oct 2013 15:49:56 -0600
Subject: [SciPy-Dev] ANN: NumPy 1.8.0 release.
Message-ID: <CAB6mnxLNKmtd2-7B3=89oi3yE_7xyw3yn7b5RpY70kQtAYL5Pw@mail.gmail.com>

I am pleased to announce the availability of NumPy 1.8.0. This release is
the culmination of over a years worth of work by the NumPy team and
contains many fixes, enhancements, and new features. Highlights are:

   - New, no 2to3, Python 2 and Python 3 are supported by a common code
   base.
   - New, gufuncs for linear algebra, enabling operations on stacked arrays.
   - New, inplace fancy indexing for ufuncs with the ``.at`` method.
   - New, ``partition`` function, partial sorting via selection for fast
   median.
   - New, ``nanmean``, ``nanvar``, and ``nanstd`` functions skipping NaNs.
   - New, ``full`` and ``full_like`` functions to create value initialized
   arrays.
   - New, ``PyUFunc_RegisterLoopForDescr``, better ufunc support for user
   dtypes.
   - Numerous performance improvements in many areas.

This release requires Python 2.6, 2.7 or 3.2-3.3, support for Python 2.4
and 2.5 has been dropped. Sources and binaries can be found at
http://sourceforge.net/projects/numpy/files/NumPy/1.8.0/.

Some 119 people contributed to this release. This is a remarkable increase
and shows that there is still life in this venerable code that had its
beginning in Numeric some 18 years ago. Many thanks to you all.

Enjoy,

Chuck


NumPy 1.8.0 Release Notes
*************************

This release supports  Python 2.6 -2.7 and 3.2 - 3.3.


Highlights
==========


* New, no 2to3, Python 2 and Python 3 are supported by a common code base.
* New, gufuncs for linear algebra, enabling operations on stacked arrays.
* New, inplace fancy indexing for ufuncs with the ``.at`` method.
* New, ``partition`` function, partial sorting via selection for fast
median.
* New, ``nanmean``, ``nanvar``, and ``nanstd`` functions skipping NaNs.
* New, ``full`` and ``full_like`` functions to create value initialized
arrays.
* New, ``PyUFunc_RegisterLoopForDescr``, better ufunc support for user
dtypes.
* Numerous performance improvements in many areas.


Dropped Support
===============


Support for Python versions 2.4 and 2.5 has been dropped,

Support for SCons has been removed.


Future Changes
==============


The Datetime64 type remains experimental in this release. In 1.9 there will
probably be some changes to make it more useable.

The diagonal method currently returns a new array and raises a
FutureWarning. In 1.9 it will return a readonly view.

Multiple field selection from a array of structured type currently
returns a new array and raises a FutureWarning. In 1.9 it will return a
readonly view.

The numpy/oldnumeric and numpy/numarray compatibility modules will be
removed in 1.9.


Compatibility notes
===================


The doc/sphinxext content has been moved into its own github repository,
and is included in numpy as a submodule. See the instructions in
doc/HOWTO_BUILD_DOCS.rst.txt for how to access the content.

.. _numpydoc: https://github.com/numpy/numpydoc

The hash function of numpy.void scalars has been changed.  Previously the
pointer to the data was hashed as an integer.  Now, the hash function uses
the tuple-hash algorithm to combine the hash functions of the elements of
the scalar, but only if the scalar is read-only.

Numpy has switched its build system to using 'separate compilation' by
default.  In previous releases this was supported, but not default. This
should produce the same results as the old system, but if you're trying to
do something complicated like link numpy statically or using an unusual
compiler, then it's possible you will encounter problems. If so, please
file a bug and as a temporary workaround you can re-enable the old build
system by exporting the shell variable NPY_SEPARATE_COMPILATION=0.

For the AdvancedNew iterator the ``oa_ndim`` flag should now be -1 to
indicate
that no ``op_axes`` and ``itershape`` are passed in. The ``oa_ndim == 0``
case, now indicates a 0-D iteration and ``op_axes`` being NULL and the old
usage is deprecated. This does not effect the ``NpyIter_New`` or
``NpyIter_MultiNew`` functions.

The functions nanargmin and nanargmax now return np.iinfo['intp'].min for
the index in all-NaN slices. Previously the functions would raise a
ValueError
for array returns and NaN for scalar returns.

NPY_RELAXED_STRIDES_CHECKING
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is a new compile time environment variable
``NPY_RELAXED_STRIDES_CHECKING``. If this variable is set to 1, then
numpy will consider more arrays to be C- or F-contiguous -- for
example, it becomes possible to have a column vector which is
considered both C- and F-contiguous simultaneously. The new definition
is more accurate, allows for faster code that makes fewer unnecessary
copies, and simplifies numpy's code internally. However, it may also
break third-party libraries that make too-strong assumptions about the
stride values of C- and F-contiguous arrays. (It is also currently
known that this breaks Cython code using memoryviews, which will be
fixed in Cython.) THIS WILL BECOME THE DEFAULT IN A FUTURE RELEASE, SO
PLEASE TEST YOUR CODE NOW AGAINST NUMPY BUILT WITH::

  NPY_RELAXED_STRIDES_CHECKING=1 python setup.py install

You can check whether NPY_RELAXED_STRIDES_CHECKING is in effect by
running::

  np.ones((10, 1), order="C").flags.f_contiguous

This will be ``True`` if relaxed strides checking is enabled, and
``False`` otherwise. The typical problem we've seen so far is C code
that works with C-contiguous arrays, and assumes that the itemsize can
be accessed by looking at the last element in the ``PyArray_STRIDES(arr)``
array. When relaxed strides are in effect, this is not true (and in
fact, it never was true in some corner cases). Instead, use
``PyArray_ITEMSIZE(arr)``.

For more information check the "Internal memory layout of an ndarray"
section in the documentation.

Binary operations with non-arrays as second argument
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Binary operations of the form ``<array-or-subclass> * <non-array-subclass>``
where ``<non-array-subclass>`` declares an ``__array_priority__`` higher
than
that of ``<array-or-subclass>`` will now unconditionally return
*NotImplemented*, giving ``<non-array-subclass>`` a chance to handle the
operation.  Previously, `NotImplemented` would only be returned if
``<non-array-subclass>`` actually implemented the reversed operation, and
after
a (potentially expensive) array conversion of ``<non-array-subclass>`` had
been
attempted. (`bug <https://github.com/numpy/numpy/issues/3375>`_, `pull
request
<https://github.com/numpy/numpy/pull/3501>`_)

Function `median` used with `overwrite_input` only partially sorts array
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If `median` is used with `overwrite_input` option the input array will now
only
be partially sorted instead of fully sorted.

Fix to financial.npv
~~~~~~~~~~~~~~~~~~~~
The npv function had a bug. Contrary to what the documentation stated, it
summed from indexes ``1`` to ``M`` instead of from ``0`` to ``M - 1``. The
fix changes the returned value. The mirr function called the npv function,
but worked around the problem, so that was also fixed and the return value
of the mirr function remains unchanged.

Runtime warnings when comparing NaN numbers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comparing ``NaN`` floating point numbers now raises the ``invalid`` runtime
warning. If a ``NaN`` is expected the warning can be ignored using
np.errstate.
E.g.::

  with np.errstate(invalid='ignore'):
      operation()


New Features
============


Support for linear algebra on stacked arrays
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The gufunc machinery is now used for np.linalg, allowing operations on
stacked arrays and vectors. For example::

    >>> a
    array([[[ 1.,  1.],
            [ 0.,  1.]],

           [[ 1.,  1.],
            [ 0.,  1.]]])

    >>> np.linalg.inv(a)
    array([[[ 1., -1.],
            [ 0.,  1.]],

           [[ 1., -1.],
            [ 0.,  1.]]])

In place fancy indexing for ufuncs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The function ``at`` has been added to ufunc objects to allow in place
ufuncs with no buffering when fancy indexing is used. For example, the
following will increment the first and second items in the array, and will
increment the third item twice: ``numpy.add.at(arr, [0, 1, 2, 2], 1)``

This is what many have mistakenly thought ``arr[[0, 1, 2, 2]] += 1`` would
do,
but that does not work as the incremented value of ``arr[2]`` is simply
copied
into the third slot in ``arr`` twice, not incremented twice.

New functions `partition` and `argpartition`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New functions to partially sort arrays via a selection algorithm.

A ``partition`` by index ``k`` moves the ``k`` smallest element to the
front of
an array.  All elements before ``k`` are then smaller or equal than the
value
in position ``k`` and all elements following ``k`` are then greater or equal
than the value in position ``k``. The ordering of the values within these
bounds is undefined.
A sequence of indices can be provided to sort all of them into their sorted
position at once iterative partitioning.
This can be used to efficiently obtain order statistics like median or
percentiles of samples.
``partition`` has a linear time complexity of ``O(n)`` while a full sort has
``O(n log(n))``.

New functions `nanmean`, `nanvar` and `nanstd`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New nan aware statistical functions are added. In these functions the
results are what would be obtained if nan values were ommited from all
computations.

New functions `full` and `full_like`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New convenience functions to create arrays filled with a specific value;
complementary to the existing `zeros` and `zeros_like` functions.

IO compatibility with large files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Large NPZ files >2GB can be loaded on 64-bit systems.

Building against OpenBLAS
~~~~~~~~~~~~~~~~~~~~~~~~~
It is now possible to build numpy against OpenBLAS by editing site.cfg.

New constant
~~~~~~~~~~~~
Euler's constant is now exposed in numpy as euler_gamma.

New modes for qr
~~~~~~~~~~~~~~~~
New modes 'complete', 'reduced', and 'raw' have been added to the qr
factorization and the old 'full' and 'economic' modes are deprecated.
The 'reduced' mode replaces the old 'full' mode and is the default as was
the 'full' mode, so backward compatibility can be maintained by not
specifying the mode.

The 'complete' mode returns a full dimensional factorization, which can be
useful for obtaining a basis for the orthogonal complement of the range
space. The 'raw' mode returns arrays that contain the Householder
reflectors and scaling factors that can be used in the future to apply q
without needing to convert to a matrix. The 'economic' mode is simply
deprecated, there isn't much use for it and it isn't any more efficient
than the 'raw' mode.

New `invert` argument to `in1d`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The function `in1d` now accepts a `invert` argument which, when `True`,
causes the returned array to be inverted.

Advanced indexing using `np.newaxis`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is now possible to use `np.newaxis`/`None` together with index
arrays instead of only in simple indices. This means that
``array[np.newaxis, [0, 1]]`` will now work as expected and select the first
two rows while prepending a new axis to the array.


C-API
~~~~~
New ufuncs can now be registered with builtin input types and a custom
output type. Before this change, NumPy wouldn't be able to find the right
ufunc loop function when the ufunc was called from Python, because the ufunc
loop signature matching logic wasn't looking at the output operand type.
Now the correct ufunc loop is found, as long as the user provides an output
argument with the correct output type.

runtests.py
~~~~~~~~~~~
A simple test runner script ``runtests.py`` was added. It also builds Numpy
via
``setup.py build`` and can be used to run tests easily during development.


Improvements
============

IO performance improvements
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Performance in reading large files was improved by chunking (see also IO
compatibility).

Performance improvements to `pad`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `pad` function has a new implementation, greatly improving performance
for
all inputs except `mode=<function>` (retained for backwards compatibility).
Scaling with dimensionality is dramatically improved for rank >= 4.

Performance improvements to `isnan`, `isinf`, `isfinite` and `byteswap`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`isnan`, `isinf`, `isfinite` and `byteswap` have been improved to take
advantage of compiler builtins to avoid expensive calls to libc.
This improves performance of these operations by about a factor of two on
gnu
libc systems.

Performance improvements via SSE2 vectorization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Several functions have been optimized to make use of SSE2 CPU SIMD
instructions.

* Float32 and float64:
    * base math (`add`, `subtract`, `divide`, `multiply`)
    * `sqrt`
    * `minimum/maximum`
    * `absolute`
* Bool:
    * `logical_or`
    * `logical_and`
    * `logical_not`

This improves performance of these operations up to 4x/2x for
float32/float64
and up to 10x for bool depending on the location of the data in the CPU
caches.
The performance gain is greatest for in-place operations.

In order to use the improved functions the SSE2 instruction set must be
enabled
at compile time. It is enabled by default on x86_64 systems. On x86_32 with
a
capable CPU it must be enabled by passing the appropriate flag to the CFLAGS
build variable (-msse2 with gcc).

Performance improvements to `median`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`median` is now implemented in terms of `partition` instead of `sort` which
reduces its time complexity from O(n log(n)) to O(n).
If used with the `overwrite_input` option the array will now only be
partially
sorted instead of fully sorted.


Overrideable operand flags in ufunc C-API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When creating a ufunc, the default ufunc operand flags can be overridden
via the new op_flags attribute of the ufunc object. For example, to set
the operand flag for the first input to read/write:

PyObject \*ufunc = PyUFunc_FromFuncAndData(...);
ufunc->op_flags[0] = NPY_ITER_READWRITE;

This allows a ufunc to perform an operation in place. Also, global nditer
flags
can be overridden via the new iter_flags attribute of the ufunc object.
For example, to set the reduce flag for a ufunc:

ufunc->iter_flags = NPY_ITER_REDUCE_OK;


Changes
=======


General
~~~~~~~
The function np.take now allows 0-d arrays as indices.

The separate compilation mode is now enabled by default.

Several changes to np.insert and np.delete:

* Previously, negative indices and indices that pointed past the end of
  the array were simply ignored. Now, this will raise a Future or
Deprecation
  Warning. In the future they will be treated like normal indexing treats
  them -- negative indices will wrap around, and out-of-bound indices will
  generate an error.
* Previously, boolean indices were treated as if they were integers (always
  referring to either the 0th or 1st item in the array). In the future, they
  will be treated as masks. In this release, they raise a FutureWarning
  warning of this coming change.
* In Numpy 1.7. np.insert already allowed the syntax
  `np.insert(arr, 3, [1,2,3])` to insert multiple items at a single
position.
  In Numpy 1.8. this is also possible for `np.insert(arr, [3], [1, 2, 3])`.

Padded regions from np.pad are now correctly rounded, not truncated.

C-API Array Additions
~~~~~~~~~~~~~~~~~~~~~
Four new functions have been added to the array C-API.

* PyArray_Partition
* PyArray_ArgPartition
* PyArray_SelectkindConverter
* PyDataMem_NEW_ZEROED

C-API Ufunc Additions
~~~~~~~~~~~~~~~~~~~~~
One new function has been added to the ufunc C-API that allows to register
an inner loop for user types using the descr.

* PyUFunc_RegisterLoopForDescr

Deprecations
============

The 'full' and 'economic' modes of qr factorization are deprecated.

General
~~~~~~~
The use of non-integer for indices and most integer arguments has been
deprecated. Previously float indices and function arguments such as axes or
shapes were truncated to integers without warning. For example
`arr.reshape(3., -1)` or `arr[0.]` will trigger a deprecation warning in
NumPy 1.8., and in some future version of NumPy they will raise an error.


Authors
=======

This release contains work by the following people who contributed at least
one patch to this release. The names are in alphabetical order by first
name:

* 87
* Adam Ginsburg +
* Adam Griffiths +
* Alexander Belopolsky +
* Alex Barth +
* Alex Ford +
* Andreas Hilboll +
* Andreas Kloeckner +
* Andreas Schwab +
* Andrew Horton +
* argriffing +
* Arink Verma +
* Bago Amirbekian +
* Bartosz Telenczuk +
* bebert218 +
* Benjamin Root +
* Bill Spotz +
* Bradley M. Froehle
* Carwyn Pelley +
* Charles Harris
* Chris
* Christian Brueffer +
* Christoph Dann +
* Christoph Gohlke
* Dan Hipschman +
* Daniel +
* Dan Miller +
* daveydave400 +
* David Cournapeau
* David Warde-Farley
* Denis Laxalde
* dmuellner +
* Edward Catmur +
* Egor Zindy +
* endolith
* Eric Firing
* Eric Fode
* Eric Moore +
* Eric Price +
* Fazlul Shahriar +
* F?lix Hartmann +
* Fernando Perez
* Frank B +
* Frank Breitling +
* Frederic
* Gabriel
* GaelVaroquaux
* Guillaume Gay +
* Han Genuit
* HaroldMills +
* hklemm +
* jamestwebber +
* Jason Madden +
* Jay Bourque
* jeromekelleher +
* Jes?s G?mez +
* jmozmoz +
* jnothman +
* Johannes Sch?nberger +
* John Benediktsson +
* John Salvatier +
* John Stechschulte +
* Jonathan Waltman +
* Joon Ro +
* Jos de Kloe +
* Joseph Martinot-Lagarde +
* Josh Warner (Mac) +
* Jostein B? Fl?ystad +
* Juan Luis Cano Rodr?guez +
* Julian Taylor +
* Julien Phalip +
* K.-Michael Aye +
* Kumar Appaiah +
* Lars Buitinck
* Leon Weber +
* Luis Pedro Coelho
* Marcin Juszkiewicz
* Mark Wiebe
* Marten van Kerkwijk +
* Martin Baeuml +
* Martin Spacek
* Martin Teichmann +
* Matt Davis +
* Matthew Brett
* Maximilian Albert +
* m-d-w +
* Michael Droettboom
* mwtoews +
* Nathaniel J. Smith
* Nicolas Scheffer +
* Nils Werner +
* ochoadavid +
* Ond?ej ?ert?k
* ovillellas +
* Paul Ivanov
* Pauli Virtanen
* peterjc
* Ralf Gommers
* Raul Cota +
* Richard Hattersley +
* Robert Costa +
* Robert Kern
* Rob Ruana +
* Ronan Lamy
* Sandro Tosi
* Sascha Peilicke +
* Sebastian Berg
* Skipper Seabold
* Stefan van der Walt
* Steve +
* Takafumi Arakaki +
* Thomas Robitaille +
* Tomas Tomecek +
* Travis E. Oliphant
* Valentin Haenel
* Vladimir Rutsky +
* Warren Weckesser
* Yaroslav Halchenko
* Yury V. Zaytsev +

A total of 119 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131030/39e4d860/attachment.html>