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-User] [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.scipy.org/pipermail/scipy-user/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-User] [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.scipy.org/pipermail/scipy-user/attachments/20131001/a6e513ac/attachment.html>

From sgarcia at olfac.univ-lyon1.fr  Tue Oct  1 06:27:07 2013
From: sgarcia at olfac.univ-lyon1.fr (Samuel Garcia)
Date: Tue, 01 Oct 2013 12:27:07 +0200
Subject: [SciPy-User] Interpolation with sinc
Message-ID: <524AA37B.5080108@olfac.univ-lyon1.fr>

Hi list and numerical experts,

I would like to do an interplation with sinc. sinc if often used for 
oversampling but it is not what I want, I really want an interpolation 
(= shift in a signal)
It seems that it is not in scipy.interpolate.inter1d.

Here an example, where I do interpolate with a spline with interp1d 
(sig1)  and my own sinc interpolation with loop (sig2) and with convole 
(sig3):

import numpy as np
from matplotlib import pyplot
from scipy.interpolate import interp1d


t = np.arange(500,1000)
sig = np.sin(2*np.pi*0.01*t)

delta = 0.2
t2 = np.arange(702, 802) - delta

# solution 1
# spline with interp1d
interpolator = interp1d(t,sig, kind = 1)
sig1 = interpolator(t2)

# solution 2
# with sinc loop
s = np.sinc(t-delta)
sig2 = np.zeros(t2.size)
for i in range(t2.size):
     for j in range(sig.size):
         sig2[i] += sig[j] * np.sinc(t2[i]-t[j])

# solution 3
# with sinc convole
half = t.size//2
sig3 = np.convolve(sig, np.sinc(np.arange(-half, half)-delta+1), mode = 
'same')
sig3 = sig3[202:302]

pyplot.plot(t, sig, 'or-')
pyplot.plot(t2, sig1, '*b-')
pyplot.plot(t2, sig2, '^g-')
pyplot.plot(t2, sig3, '+y-')
pyplot.show()



The loop (solution 2) is slow of course. The version 2 is better because 
vectorized but it compute the all signal and then take a part after.
Does some one have a better solution than would look like solution 3 but 
do take all point ?



Thanks a lot.


Samuel garcia


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samuel Garcia
Lyon Neuroscience
CNRS - UMR5292 -  INSERM U1028 -  Universite Claude Bernard LYON 1
Equipe R et D
50, avenue Tony Garnier
69366 LYON Cedex 07
FRANCE
T?l : 04 37 28 74 24
Fax : 04 37 28 76 01
http://olfac.univ-lyon1.fr/unite/equipe-07/
http://neuralensemble.org/trac/OpenElectrophy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From sturla at molden.no  Tue Oct  1 09:28:14 2013
From: sturla at molden.no (Sturla Molden)
Date: Tue, 1 Oct 2013 15:28:14 +0200
Subject: [SciPy-User] bug report + feature request (was: scipy cblas
	return value)
In-Reply-To: <52458ECA.20809@gmail.com>
References: <1e44591c-dc17-46b4-a998-cab29016d434@googlegroups.com>
	<CADiQ+QAuQak5Vp2QTV=S1wwTjoUmFAO5jGTQpTP2R6qhiyJbEQ@mail.gmail.com>
	<80fbdffc-ed06-46b6-a372-eeb01736d248@googlegroups.com>
	<l1sibh$jgl$1@ger.gmane.org>
	<dd29db75-f254-4aaf-be60-9f8b5996b060@googlegroups.com>
	<FEC48936-830F-4B1E-BA6C-AA6EBD47350A@molden.no>
	<445edf58-50aa-463a-81cc-04c27e689c15@googlegroups.com>
	<401ED18D-80E9-4304-9C21-411EEEA61096@molden.no>
	<CAP-8ehgRfEaDSmomxFv8_T0Ex1CvNoffSYpbusAt86crb49GbQ@mail.gmail.com>
	<A1FC5511-0740-4C15-AB2E-2ED30F1640B7@molden.no>
	<52458ECA.20809@gmail.com>
Message-ID: <8CF1467E-8EB4-40DF-BCF0-95CBB8984E80@molden.no>


On Sep 27, 2013, at 3:57 PM, Jonathan Stickel <jjstickel at gmail.com> wrote:

> 
> This is a rather narrow viewpoint. There are free-software package managers for Mac OS X, and macports is a decent one. It has its critics, but I have found it to reliably provide a working python/numpy/scipy environment including all the necessary associated libraries.
> 

Personally I prefer to not install another GCC, it case it renders Xcode and system libraries fubar.

Thus I rather pay for Intel compilers and SciPy from Enthought or Anaconda. A Mac will be more expensive than a Linux or Wintendo computer anyway. I just consider this a part of the additional expense. :-)

I am sure there are some who will disagree.  :-)


Sturla





From L.J.Buitinck at uva.nl  Tue Oct  1 10:26:15 2013
From: L.J.Buitinck at uva.nl (Lars Buitinck)
Date: Tue, 1 Oct 2013 16:26:15 +0200
Subject: [SciPy-User] SciPy-User Digest, Vol 122, Issue 1
In-Reply-To: <mailman.4543.1380622905.971.scipy-user@scipy.org>
References: <mailman.4543.1380622905.971.scipy-user@scipy.org>
Message-ID: <CAKz-xUc1aftCkBojyX8rx0DgEcyrkLNyUiqEurhkUn=5D+8C4Q@mail.gmail.com>

2013/10/1  <scipy-user-request at scipy.org>:
> Message: 1
> Date: Mon, 30 Sep 2013 19:02:38 +0100
> From: Nathaniel Smith <njs at pobox.com>
> Subject: Re: [SciPy-User] [SciPy-Dev] 1.8.0rc1
> To: numpy-discussion <numpy-discussion at scipy.org>,      SciPy Users List
>         <scipy-user at scipy.org>
> Message-ID:
>         <CAPJVwBnyBSZ-oYbD1XRD57Wj2a4LcPHvN6T6v2n1cFKUs7qEpw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Everyone please do actually test this! It is really in your best
> interest, and I think people don't always realize this.

I just tested the RC by compiling scikit-learn against it and running
its full test suite. That passed.


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-User] [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.scipy.org/pipermail/scipy-user/attachments/20131001/7190cc5b/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-User] [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.scipy.org/pipermail/scipy-user/attachments/20131001/a9797d0d/attachment.html>

From njs at pobox.com  Tue Oct  1 17:24:23 2013
From: njs at pobox.com (Nathaniel Smith)
Date: Tue, 1 Oct 2013 22:24:23 +0100
Subject: [SciPy-User] Least squares speed
Message-ID: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>

Here are several ways to solve the least squares problem XB = Y:

scipy.linalg.lstsq(x, y)
np.linalg.lstsq(x, y)
np.dot(scipy.linalg.pinv(x), y)
np.dot(np.linalg.pinv(x), y)

>From the documentation, I would expect these to be ordered by speed,
fastest up top and slowest at the bottom. It turns out they *are*
ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
very substantial differences (more than a factor of 20!):

# Typical smallish problem for me:
In [40]: x = np.random.randn(780, 2)

In [41]: y = np.random.randn(780, 32 * 275)

In [42]: %timeit scipy.linalg.lstsq(x, y)
1 loops, best of 3: 494 ms per loop

In [43]: %timeit np.linalg.lstsq(x, y)
1 loops, best of 3: 356 ms per loop

In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
10 loops, best of 3: 62.2 ms per loop

In [45]: %timeit np.dot(np.linalg.pinv(x), y)
10 loops, best of 3: 23.2 ms per loop

Is this expected? I'm particularly confused at why scipy's lstsq
should be almost 40% slower than numpy's. (And shouldn't we have a
fast one-function way to solve least squares problems?)

Any reason not to use the last option? Is it as numerically stable as lstsq?

Is there any other version that's even faster or even more numerically stable?

-n


From josef.pktd at gmail.com  Tue Oct  1 17:45:01 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 1 Oct 2013 17:45:01 -0400
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
Message-ID: <CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>

On Tue, Oct 1, 2013 at 5:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
> Here are several ways to solve the least squares problem XB = Y:
>
> scipy.linalg.lstsq(x, y)
> np.linalg.lstsq(x, y)
> np.dot(scipy.linalg.pinv(x), y)
> np.dot(np.linalg.pinv(x), y)
>
> >From the documentation, I would expect these to be ordered by speed,
> fastest up top and slowest at the bottom. It turns out they *are*
> ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
> scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
> very substantial differences (more than a factor of 20!):
>
> # Typical smallish problem for me:
> In [40]: x = np.random.randn(780, 2)
>
> In [41]: y = np.random.randn(780, 32 * 275)
>
> In [42]: %timeit scipy.linalg.lstsq(x, y)
> 1 loops, best of 3: 494 ms per loop
>
> In [43]: %timeit np.linalg.lstsq(x, y)
> 1 loops, best of 3: 356 ms per loop
>
> In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
> 10 loops, best of 3: 62.2 ms per loop
>
> In [45]: %timeit np.dot(np.linalg.pinv(x), y)
> 10 loops, best of 3: 23.2 ms per loop
>
> Is this expected? I'm particularly confused at why scipy's lstsq
> should be almost 40% slower than numpy's. (And shouldn't we have a
> fast one-function way to solve least squares problems?)
>
> Any reason not to use the last option? Is it as numerically stable as lstsq?
>
> Is there any other version that's even faster or even more numerically stable?

If you have very long x, then using normal equation is faster for univariate y.

There are many different ways to calculate pinv
https://github.com/scipy/scipy/pull/289

np.lstsq breaks on rank deficient x IIRC, uses different Lapack
functions than scipy's lstsq

In very badly scaled cases (worst NIST case), scipy's pinv was a bit
more accurate than numpy's, but maybe just different defaults.
numpy's pinv was also faster than scipy's in the cases that I tried.

There is only a single NIST case that can fail using the defaults with
numpy pinv.

(what about using qr or chol_solve ?)

Lots of different ways to solve this and I never figured out a ranking
across different cases, speed, precision, robustness to
near-singularity.

Josef


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


From pav at iki.fi  Tue Oct  1 17:45:15 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 02 Oct 2013 00:45:15 +0300
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
Message-ID: <l2ffp4$r6$1@ger.gmane.org>

02.10.2013 00:24, Nathaniel Smith kirjoitti:
[clip]
> Is this expected? I'm particularly confused at why scipy's lstsq
> should be almost 40% slower than numpy's. (And shouldn't we have a
> fast one-function way to solve least squares problems?)

It checks if there are nans in the array.

Also, it uses xGELSS, whereas the numpy one uses xGELSD, so also the
algorithm called in LAPACK is different.

There's probably no reason why they should be different.

-- 
Pauli Virtanen



From josef.pktd at gmail.com  Tue Oct  1 17:54:46 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 1 Oct 2013 17:54:46 -0400
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
	<CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
Message-ID: <CAMMTP+B7Qm_7WJ7kGJhgEd3_5VqHS2fvozmrvJ2-ZOhe52JKdQ@mail.gmail.com>

On Tue, Oct 1, 2013 at 5:45 PM,  <josef.pktd at gmail.com> wrote:
> On Tue, Oct 1, 2013 at 5:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> Here are several ways to solve the least squares problem XB = Y:
>>
>> scipy.linalg.lstsq(x, y)
>> np.linalg.lstsq(x, y)
>> np.dot(scipy.linalg.pinv(x), y)
>> np.dot(np.linalg.pinv(x), y)
>>
>> >From the documentation, I would expect these to be ordered by speed,
>> fastest up top and slowest at the bottom. It turns out they *are*
>> ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
>> scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
>> very substantial differences (more than a factor of 20!):
>>
>> # Typical smallish problem for me:
>> In [40]: x = np.random.randn(780, 2)
>>
>> In [41]: y = np.random.randn(780, 32 * 275)
>>
>> In [42]: %timeit scipy.linalg.lstsq(x, y)
>> 1 loops, best of 3: 494 ms per loop
>>
>> In [43]: %timeit np.linalg.lstsq(x, y)
>> 1 loops, best of 3: 356 ms per loop
>>
>> In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
>> 10 loops, best of 3: 62.2 ms per loop
>>
>> In [45]: %timeit np.dot(np.linalg.pinv(x), y)
>> 10 loops, best of 3: 23.2 ms per loop
>>
>> Is this expected? I'm particularly confused at why scipy's lstsq
>> should be almost 40% slower than numpy's. (And shouldn't we have a
>> fast one-function way to solve least squares problems?)
>>
>> Any reason not to use the last option? Is it as numerically stable as lstsq?
>>
>> Is there any other version that's even faster or even more numerically stable?
>
> If you have very long x, then using normal equation is faster for univariate y.
>
> There are many different ways to calculate pinv
> https://github.com/scipy/scipy/pull/289
>
> np.lstsq breaks on rank deficient x IIRC, uses different Lapack
> functions than scipy's lstsq
>
> In very badly scaled cases (worst NIST case), scipy's pinv was a bit
> more accurate than numpy's, but maybe just different defaults.
> numpy's pinv was also faster than scipy's in the cases that I tried.
>
> There is only a single NIST case that can fail using the defaults with
> numpy pinv.


for example, when I was playing with precision problems
Addendum 2: scipy.linalg versus numpy.linalg
http://jpktd.blogspot.ca/2012/03/numerical-accuracy-in-linear-least.html

Josef

>
> (what about using qr or chol_solve ?)
>
> Lots of different ways to solve this and I never figured out a ranking
> across different cases, speed, precision, robustness to
> near-singularity.
>
> Josef
>
>
>>
>> -n
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user


From tmp50 at ukr.net  Wed Oct  2 15:32:41 2013
From: tmp50 at ukr.net (Dmitrey)
Date: Wed, 02 Oct 2013 22:32:41 +0300
Subject: [SciPy-User] MATLAB fsolve now available in Python
Message-ID: <1380742043.471698032.9rc2y0ro@frv43.ukr.net>

Hi all, 
New solver for systems of nonlinear equations ( SNLE ) has been connected to free Python framework OpenOpt: fsolve from? MATLAB ? Optimization Toolbox; uploaded into PYPI in v. 0.5112. 

As well as fmincon , currently it's available for Python 2 only. 
Unlike scipy.optimize fsolve, it can handle sparse derivatives, user-supplied or from FuncDesigner automatic differentiation. 
See the example with 15000 equations. 
To keep discussion in a single place please use the OpenOpt forum thread. Regards, D. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131002/d92e3d48/attachment.html>

From njs at pobox.com  Wed Oct  2 15:58:06 2013
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 2 Oct 2013 20:58:06 +0100
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
	<CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
Message-ID: <CAPJVwBkuHw-6bvw1dgJXYbAyzwb7daZgBc+r6cx+6JXWF+C=iA@mail.gmail.com>

On Tue, Oct 1, 2013 at 10:45 PM,  <josef.pktd at gmail.com> wrote:
> On Tue, Oct 1, 2013 at 5:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> Here are several ways to solve the least squares problem XB = Y:
>>
>> scipy.linalg.lstsq(x, y)
>> np.linalg.lstsq(x, y)
>> np.dot(scipy.linalg.pinv(x), y)
>> np.dot(np.linalg.pinv(x), y)
>>
>> >From the documentation, I would expect these to be ordered by speed,
>> fastest up top and slowest at the bottom. It turns out they *are*
>> ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
>> scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
>> very substantial differences (more than a factor of 20!):
>>
>> # Typical smallish problem for me:
>> In [40]: x = np.random.randn(780, 2)
>>
>> In [41]: y = np.random.randn(780, 32 * 275)
>>
>> In [42]: %timeit scipy.linalg.lstsq(x, y)
>> 1 loops, best of 3: 494 ms per loop
>>
>> In [43]: %timeit np.linalg.lstsq(x, y)
>> 1 loops, best of 3: 356 ms per loop
>>
>> In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
>> 10 loops, best of 3: 62.2 ms per loop
>>
>> In [45]: %timeit np.dot(np.linalg.pinv(x), y)
>> 10 loops, best of 3: 23.2 ms per loop
>>
>> Is this expected? I'm particularly confused at why scipy's lstsq
>> should be almost 40% slower than numpy's. (And shouldn't we have a
>> fast one-function way to solve least squares problems?)
>>
>> Any reason not to use the last option? Is it as numerically stable as lstsq?
>>
>> Is there any other version that's even faster or even more numerically stable?
>
> If you have very long x, then using normal equation is faster for univariate y.
>
> There are many different ways to calculate pinv
> https://github.com/scipy/scipy/pull/289
>
> np.lstsq breaks on rank deficient x IIRC, uses different Lapack
> functions than scipy's lstsq
>
> In very badly scaled cases (worst NIST case), scipy's pinv was a bit
> more accurate than numpy's, but maybe just different defaults.
> numpy's pinv was also faster than scipy's in the cases that I tried.
>
> There is only a single NIST case that can fail using the defaults with
> numpy pinv.
>
> (what about using qr or chol_solve ?)
>
> Lots of different ways to solve this and I never figured out a ranking
> across different cases, speed, precision, robustness to
> near-singularity.

Amazingly enough, in this case doing a full rank-revealing QR,
including calculating the rank via condition number of submatrices, is
tied for the fastest method:

In [66]: %timeit q, r, p = scipy.linalg.qr(x, mode="economic",
pivoting=True); [np.linalg.cond(r[:i, :i]) for i in xrange(1,
r.shape[0])]; np.linalg.solve(r[:, p], np.dot(q.T, y))
10 loops, best of 3: 22 ms per loop

Also tied for fastest with np.linalg.pinv (above) are the direct
method, cho_solve, and a non-rank-revealing QR with lower-triangular
backsolve:

In [70]: %timeit np.linalg.solve(np.dot(x.T, x), np.dot(x.T, y))
10 loops, best of 3: 21.4 ms per loop

In [71]: %timeit c = scipy.linalg.cho_factor(np.dot(x.T, x));
scipy.linalg.cho_solve(c, np.dot(x.T, y))
10 loops, best of 3: 21.2 ms per loop

In [72]: %timeit q, r = scipy.linalg.qr(x, mode="economic");
scipy.linalg.solve_triangular(r, np.dot(q.T, y))
10 loops, best of 3: 22.4 ms per loop

But AFAIK QR is the gold standard for precision on the kinds of linear
regression problems I care about (and definitely has better numerical
stability than the versions that involve dot(x.T, x)), and in my case
I actually want to detect and reject ill-conditioned problems rather
than impose some secondary disambiguating constraint, so... RRQR seems
to be the obvious choice.

Not sure if there's anything that could or should be done to make
these trade-offs more obvious to people less obsessive than me...

-n


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-User] 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.scipy.org/pipermail/scipy-user/attachments/20131002/62957027/attachment.ksh>
-------------- next part --------------

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

From charlesr.harris at gmail.com  Wed Oct  2 18:42:38 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 2 Oct 2013 16:42:38 -0600
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
Message-ID: <CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>

On Wed, Oct 2, 2013 at 2:31 PM, Piet van Oostrum <piet at vanoostrum.org>wrote:

> 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.dmgan 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.
>
>
I'd guess you have the wrong Fortran. IIRC, you have to get it somewhere
else than from Apple. Someone else here would know.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131002/c9a5143b/attachment.html>

From matthew.brett at gmail.com  Wed Oct  2 18:48:35 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 2 Oct 2013 15:48:35 -0700
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
Message-ID: <CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>

Hi,

On Wed, Oct 2, 2013 at 3:42 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
>
> On Wed, Oct 2, 2013 at 2:31 PM, Piet van Oostrum <piet at vanoostrum.org>
> wrote:
>>
>> 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.
>>
>
> I'd guess you have the wrong Fortran. IIRC, you have to get it somewhere
> else than from Apple. Someone else here would know.

I don't think he should need Fortran installing from the binary
installer - should he?

Cheers,

Matthew


From charlesr.harris at gmail.com  Wed Oct  2 19:07:29 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 2 Oct 2013 17:07:29 -0600
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
Message-ID: <CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>

On Wed, Oct 2, 2013 at 4:48 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Wed, Oct 2, 2013 at 3:42 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> >
> > On Wed, Oct 2, 2013 at 2:31 PM, Piet van Oostrum <piet at vanoostrum.org>
> > wrote:
> >>
> >> 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.
> >>
> >
> > I'd guess you have the wrong Fortran. IIRC, you have to get it somewhere
> > else than from Apple. Someone else here would know.
>
> I don't think he should need Fortran installing from the binary
> installer - should he?
>
> Cheers,
>
>
The f2py tests use it. Apparently he has a Fortran, it is just the wrong
one.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131002/ecc0d003/attachment.html>

From matthew.brett at gmail.com  Wed Oct  2 20:09:58 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 2 Oct 2013 17:09:58 -0700
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAPJVwBkuHw-6bvw1dgJXYbAyzwb7daZgBc+r6cx+6JXWF+C=iA@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
	<CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
	<CAPJVwBkuHw-6bvw1dgJXYbAyzwb7daZgBc+r6cx+6JXWF+C=iA@mail.gmail.com>
Message-ID: <CAH6Pt5rYAF_UV4KydYKLgxK_wDb1QikT_f0z1jajnfwtmQA1DQ@mail.gmail.com>

Hi,

On Wed, Oct 2, 2013 at 12:58 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Tue, Oct 1, 2013 at 10:45 PM,  <josef.pktd at gmail.com> wrote:
>> On Tue, Oct 1, 2013 at 5:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>> Here are several ways to solve the least squares problem XB = Y:
>>>
>>> scipy.linalg.lstsq(x, y)
>>> np.linalg.lstsq(x, y)
>>> np.dot(scipy.linalg.pinv(x), y)
>>> np.dot(np.linalg.pinv(x), y)
>>>
>>> >From the documentation, I would expect these to be ordered by speed,
>>> fastest up top and slowest at the bottom. It turns out they *are*
>>> ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
>>> scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
>>> very substantial differences (more than a factor of 20!):
>>>
>>> # Typical smallish problem for me:
>>> In [40]: x = np.random.randn(780, 2)
>>>
>>> In [41]: y = np.random.randn(780, 32 * 275)
>>>
>>> In [42]: %timeit scipy.linalg.lstsq(x, y)
>>> 1 loops, best of 3: 494 ms per loop
>>>
>>> In [43]: %timeit np.linalg.lstsq(x, y)
>>> 1 loops, best of 3: 356 ms per loop
>>>
>>> In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
>>> 10 loops, best of 3: 62.2 ms per loop
>>>
>>> In [45]: %timeit np.dot(np.linalg.pinv(x), y)
>>> 10 loops, best of 3: 23.2 ms per loop
>>>
>>> Is this expected? I'm particularly confused at why scipy's lstsq
>>> should be almost 40% slower than numpy's. (And shouldn't we have a
>>> fast one-function way to solve least squares problems?)
>>>
>>> Any reason not to use the last option? Is it as numerically stable as lstsq?
>>>
>>> Is there any other version that's even faster or even more numerically stable?
>>
>> If you have very long x, then using normal equation is faster for univariate y.
>>
>> There are many different ways to calculate pinv
>> https://github.com/scipy/scipy/pull/289
>>
>> np.lstsq breaks on rank deficient x IIRC, uses different Lapack
>> functions than scipy's lstsq
>>
>> In very badly scaled cases (worst NIST case), scipy's pinv was a bit
>> more accurate than numpy's, but maybe just different defaults.
>> numpy's pinv was also faster than scipy's in the cases that I tried.
>>
>> There is only a single NIST case that can fail using the defaults with
>> numpy pinv.
>>
>> (what about using qr or chol_solve ?)
>>
>> Lots of different ways to solve this and I never figured out a ranking
>> across different cases, speed, precision, robustness to
>> near-singularity.
>
> Amazingly enough, in this case doing a full rank-revealing QR,
> including calculating the rank via condition number of submatrices, is
> tied for the fastest method:
>
> In [66]: %timeit q, r, p = scipy.linalg.qr(x, mode="economic",
> pivoting=True); [np.linalg.cond(r[:i, :i]) for i in xrange(1,
> r.shape[0])]; np.linalg.solve(r[:, p], np.dot(q.T, y))
> 10 loops, best of 3: 22 ms per loop
>
> Also tied for fastest with np.linalg.pinv (above) are the direct
> method, cho_solve, and a non-rank-revealing QR with lower-triangular
> backsolve:
>
> In [70]: %timeit np.linalg.solve(np.dot(x.T, x), np.dot(x.T, y))
> 10 loops, best of 3: 21.4 ms per loop
>
> In [71]: %timeit c = scipy.linalg.cho_factor(np.dot(x.T, x));
> scipy.linalg.cho_solve(c, np.dot(x.T, y))
> 10 loops, best of 3: 21.2 ms per loop
>
> In [72]: %timeit q, r = scipy.linalg.qr(x, mode="economic");
> scipy.linalg.solve_triangular(r, np.dot(q.T, y))
> 10 loops, best of 3: 22.4 ms per loop
>
> But AFAIK QR is the gold standard for precision on the kinds of linear
> regression problems I care about (and definitely has better numerical
> stability than the versions that involve dot(x.T, x)), and in my case
> I actually want to detect and reject ill-conditioned problems rather
> than impose some secondary disambiguating constraint, so... RRQR seems
> to be the obvious choice.
>
> Not sure if there's anything that could or should be done to make
> these trade-offs more obvious to people less obsessive than me...

How about a tutorial page or a notebook?  I am quite sure that there
will be an audience for that level of obsessive :).  Me on a day I'm
trying to do a lot of modeling for example.

Cheers,

Matthew


From matthew.brett at gmail.com  Wed Oct  2 20:46:25 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 2 Oct 2013 17:46:25 -0700
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
Message-ID: <CAH6Pt5pQnyPqV0Gtc=mFopDK2FACNodxBMq8BbtXEwON+puWmQ@mail.gmail.com>

On Wed, Oct 2, 2013 at 4:07 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
>
> On Wed, Oct 2, 2013 at 4:48 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> On Wed, Oct 2, 2013 at 3:42 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> >
>> > On Wed, Oct 2, 2013 at 2:31 PM, Piet van Oostrum <piet at vanoostrum.org>
>> > wrote:
>> >>
>> >> 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.
>> >>
>> >
>> > I'd guess you have the wrong Fortran. IIRC, you have to get it somewhere
>> > else than from Apple. Someone else here would know.
>>
>> I don't think he should need Fortran installing from the binary
>> installer - should he?
>>
>> Cheers,
>>
>
> The f2py tests use it. Apparently he has a Fortran, it is just the wrong
> one.

Aha - yes - that makes sense,

Thanks,

Matthew


From ralf.gommers at gmail.com  Thu Oct  3 03:44:01 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 3 Oct 2013 09:44:01 +0200
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
Message-ID: <CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>

On Thu, Oct 3, 2013 at 1:07 AM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

>
>
>
> On Wed, Oct 2, 2013 at 4:48 PM, Matthew Brett <matthew.brett at gmail.com>wrote:
>
>> Hi,
>>
>> On Wed, Oct 2, 2013 at 3:42 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> >
>> > On Wed, Oct 2, 2013 at 2:31 PM, Piet van Oostrum <piet at vanoostrum.org>
>> > wrote:
>> >>
>> >> 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.
>> >>
>> >
>> > I'd guess you have the wrong Fortran. IIRC, you have to get it somewhere
>> > else than from Apple. Someone else here would know.
>>
>> I don't think he should need Fortran installing from the binary
>> installer - should he?
>>
>> Cheers,
>>
>>
> The f2py tests use it. Apparently he has a Fortran, it is just the wrong
> one.
>

Piet, you should get one of the ones recommended at
http://scipy.org/scipylib/building/macosx.html#fortran

The last error, test_io.TestSavezLoad, is real though. I can reproduce it,
will try to figure it out.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131003/8e2377ec/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-User] [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.scipy.org/pipermail/scipy-user/attachments/20131001/4f0dbf12/attachment.bin>

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-User] [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 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-User] [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 kevin.gullikson at gmail.com  Thu Oct  3 09:17:45 2013
From: kevin.gullikson at gmail.com (Kevin Gullikson)
Date: Thu, 3 Oct 2013 08:17:45 -0500
Subject: [SciPy-User] Fitting data with optimize.curve_fit
In-Reply-To: <1380067837076-18692.post@n7.nabble.com>
References: <1380067837076-18692.post@n7.nabble.com>
Message-ID: <CAEUX0Xf9_8SN5g9_Vd+6iFaY+YC6-Xie4Sqfn1tFUGr=m-j3Ww@mail.gmail.com>

Have you tried dividing by 60.0 (instead of 60) to get count rate from
counts? Annoying integer arithmetic things can cause issues like this.


Kevin Gullikson


On Tue, Sep 24, 2013 at 7:10 PM, TFSM <tesla.bamf at gmail.com> wrote:

> lab1.py <http://scipy-user.10969.n7.nabble.com/file/n18692/lab1.py>
> I have a couple questions. The data show as counts is the total number of
> counts in 60 seconds. When using the count rate instead of the total counts
> as the y data, curve_fit does not want to give a meaningful answer. It
> gives
> the co-variance as infinity and the cosine that is fit does not match the
> data. Using total counts y*60, the co-variance is reasonable and the cosine
> fits the data.
>
> Why does increasing the counts by 60 allow curve_fit to give a reasonable
> answer?
>
> A similar problem happens when trying to fit the first harmonic to this
> data, A11*cos(3x/pi) + A31*cos(3x/pi) but I must increase the counts
> artificially by at least 10 times for curve_fit to give me a curve that
> resembles the data being fit.
>
> Is there a better way to fit this data? Is what I am doing here legitimate
> artificially increase y to get a fit then just dividing by that amount to
> get the data back to count rate? Sorry for the noob questions and thanks.
>
>
>
>
>
>
> --
> View this message in context:
> http://scipy-user.10969.n7.nabble.com/Fitting-data-with-optimize-curve-fit-tp18692.html
> Sent from the Scipy-User mailing list archive at Nabble.com.
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131003/b026a5e6/attachment.html>

From josef.pktd at gmail.com  Thu Oct  3 09:46:59 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 3 Oct 2013 09:46:59 -0400
Subject: [SciPy-User] Fitting data with optimize.curve_fit
In-Reply-To: <1380067837076-18692.post@n7.nabble.com>
References: <1380067837076-18692.post@n7.nabble.com>
Message-ID: <CAMMTP+AaZssPDUYsK+jAyCTDTN8sBNZzoSVOH+BCQBC5j2QmOA@mail.gmail.com>

On Tue, Sep 24, 2013 at 8:10 PM, TFSM <tesla.bamf at gmail.com> wrote:
> lab1.py <http://scipy-user.10969.n7.nabble.com/file/n18692/lab1.py>
> I have a couple questions. The data show as counts is the total number of
> counts in 60 seconds. When using the count rate instead of the total counts
> as the y data, curve_fit does not want to give a meaningful answer. It gives
> the co-variance as infinity and the cosine that is fit does not match the
> data. Using total counts y*60, the co-variance is reasonable and the cosine
> fits the data.
>
> Why does increasing the counts by 60 allow curve_fit to give a reasonable
> answer?
>
> A similar problem happens when trying to fit the first harmonic to this
> data, A11*cos(3x/pi) + A31*cos(3x/pi) but I must increase the counts
> artificially by at least 10 times for curve_fit to give me a curve that
> resembles the data being fit.
>
> Is there a better way to fit this data? Is what I am doing here legitimate
> artificially increase y to get a fit then just dividing by that amount to
> get the data back to count rate? Sorry for the noob questions and thanks.

The mysteries of numerical optimization

Many or most optimizers are not scale invariant, at least not under
default options

for example
default starting values are ones, which might not be good in a rescaled version

forward derivative: it could also be that epsfcn is not appropriate in
the rescaled version
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.leastsq.html

ftol looks scale invariant but not xtol which should, however, only
affect the precision of the final estimate.


Josef

>
>
>
>
>
>
> --
> View this message in context: http://scipy-user.10969.n7.nabble.com/Fitting-data-with-optimize-curve-fit-tp18692.html
> Sent from the Scipy-User mailing list archive at Nabble.com.
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user


From sergio_r at mail.com  Thu Oct  3 15:46:25 2013
From: sergio_r at mail.com (Sergio Rojas)
Date: Thu, 03 Oct 2013 15:46:25 -0400
Subject: [SciPy-User] Problem building scipy-0.13.0b1 with umfpack
Message-ID: <20131003194625.123100@gmx.com>

Hello,

Trying to build scipy-0.13.0b1, the command
 python setup.py build config_fc --fcompiler=gnu95
ends with errors about umfpack [1]. This is strange because
the lines related to that library in my site.cfg file are commented

#
#[umfpack]
#search_static_first = true
#umfpack_libs = umfpack
#

Nevertheless, something (which I have been unable to find) is telling 'setup.py build` to search for that
library (which is actually installed in the same directory where I have installed atlas, lapack, blas, etc.

Is there a way to disable in setup.py to search for umfpack?

Regards,

Sergio
[1]

/home/myProg/NumLibs64b/lib/libumfpack.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: Command "gcc -pthread -shared build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/scipy/sparse/linalg/dsolve/umfpack/_umfpack_wrap.o -L/home/myProg/NumLibs64b/lib -Lbuild/temp.linux-x86_64-2.7 -lumfpack -lamd -lptf77blas -lptcblas -latlas -o build/lib.linux-x86_64-2.7/scipy/sparse/linalg/dsolve/umfpack/__umfpack.so" failed with exit status 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131003/de4a37c0/attachment.html>

From tmp50 at ukr.net  Fri Oct  4 15:26:38 2013
From: tmp50 at ukr.net (Dmitrey)
Date: Fri, 04 Oct 2013 22:26:38 +0300
Subject: [SciPy-User] [ANN] MATLAB ODE solvers - now available in Python
Message-ID: <1380914598.651925561.b7d4jpuh@frv43.ukr.net>

Several MATLAB ODE dy/dt = f(y,t) solvers (ode15s, ode23, ode113, ode23t, ode23tb, ode45, ode23s)? have been connected to free OpenOpt Suite package (possibly with? FuncDesigner ? automatic differentiation) in addition to scipy_lsoda (scipy.integrate.odeint), see the example . 
Currently only reltol parameter is available; future plans may include abstol, Python3 and PyPy support, solver ode15i for solving f(dy/dt, y, t) = 0, possibility to use single MATLAB session for several ODE probs. Sparse matrices handling is implemented for fmincon and fsolve but not ode solvers yet. 
---------------------- 
Regards, D. http://openopt.org/Dmitrey 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131004/6bafe132/attachment.html>

From piet at vanoostrum.org  Fri Oct  4 23:34:50 2013
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Fri, 04 Oct 2013 23:34:50 -0400
Subject: [SciPy-User] 1.8.0rc1
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
Message-ID: <m2eh801jc5.fsf@cochabamba.vanoostrum.org>

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

> Piet, you should get one of the ones recommended at http://scipy.org/scipylib/building/macosx.html
> #fortran?
>
> The last error, test_io.TestSavezLoad, is real though. I can reproduce it, will try to figure it
> out.
>
I have installed gfortran 4.2.3, which is the one recommended for Snow leopard:

bash-3.2$ gfortran -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /Builds/unix/gcc/gcc-4.2/configure --prefix=/usr/local --mandir=/share/man --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --build=i686-apple-darwin8 --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-languages=fortran
Thread model: posix
gcc version 4.2.3

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



From tmp50 at ukr.net  Sat Oct  5 04:27:04 2013
From: tmp50 at ukr.net (Dmitrey)
Date: Sat, 05 Oct 2013 11:27:04 +0300
Subject: [SciPy-User] [Numpy-discussion] [ANN] MATLAB ODE solvers - now
 available in	Python
In-Reply-To: <l2nesl$8ab$1@ger.gmane.org>
References: <1380914598.651925561.b7d4jpuh@frv43.ukr.net>
	<l2nesl$8ab$1@ger.gmane.org>
Message-ID: <1380961403.991447284.5qt9wlwp@frv43.ukr.net>

It requires MATLAB or MATLAB Component Runtime? ( http://www.mathworks.com/products/compiler/mcr/ ) 
I'm not regular subscriber of the mail list thus you'd better ask openopt forum. 

---------------------- 
Regards, D. http://openopt.org/Dmitrey 
--- ???????? ????????? --- 
?? ????: "Eric Carlson" < ecarlson at eng.ua.edu > 
????: 5 ??????? 2013, 01:19:28 

Hello,
Does this require a MATLAB install, or are these equivalent routines?

Thanks,
Eric

_______________________________________________
NumPy-Discussion mailing list
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131005/efa7fba5/attachment.html>

From pav at iki.fi  Sun Oct  6 11:28:24 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 06 Oct 2013 18:28:24 +0300
Subject: [SciPy-User] Strange results by scipy.spatial Delaunay
In-Reply-To: <CAE7vhgNDTj=qOoCjg2+_Sv3QrFB9fWv1C-+_22NJFEm49hsmDg@mail.gmail.com>
References: <CAE7vhgNDTj=qOoCjg2+_Sv3QrFB9fWv1C-+_22NJFEm49hsmDg@mail.gmail.com>
Message-ID: <l2rvif$khh$1@ger.gmane.org>

20.09.2013 15:30, Nils Wagner kirjoitti:
> I tried to create a convex hull of a set of points distributed on a
> cylindrical surface by the following
> script. The needed input file coor.dat is attached.
> How can I fix the problem with the distorted mesh (convex.png) ?

The resulting mesh is as reported by Qhull, so you can try tuning Qhull
options to make the result better.

If you only want convex hulls, you should use scipy.spatial.ConvexHull
rather than scipy.spatial.Delaunay, as Delaunay triangulation is both
more sensitive to rounding errors and slower than direct convex hulling.

-- 
Pauli Virtanen



From ralf.gommers at gmail.com  Sun Oct  6 14:45:09 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 6 Oct 2013 20:45:09 +0200
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <m2eh801jc5.fsf@cochabamba.vanoostrum.org>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
	<m2eh801jc5.fsf@cochabamba.vanoostrum.org>
Message-ID: <CABL7CQjF50vyPG5TwqnFaBLfGSbq_YSZdCfsyAdEGKE1NLTO_A@mail.gmail.com>

On Sat, Oct 5, 2013 at 5:34 AM, Piet van Oostrum <piet at vanoostrum.org>wrote:

> Ralf Gommers <ralf.gommers at gmail.com> writes:
>
> > Piet, you should get one of the ones recommended at
> http://scipy.org/scipylib/building/macosx.html
> > #fortran
> >
> > The last error, test_io.TestSavezLoad, is real though. I can reproduce
> it, will try to figure it
> > out.
> >
> I have installed gfortran 4.2.3, which is the one recommended for Snow
> leopard:
>
> bash-3.2$ gfortran -v
> Using built-in specs.
> Target: i686-apple-darwin8
> Configured with: /Builds/unix/gcc/gcc-4.2/configure --prefix=/usr/local
> --mandir=/share/man --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> --build=i686-apple-darwin8 --host=i686-apple-darwin8
> --target=i686-apple-darwin8 --enable-languages=fortran
> Thread model: posix
> gcc version 4.2.3
>

I can't reproduce it with the exact same OS and Fortran compiler. Looking
at the tracebacks a bit more carefully, I see that the compile fails on
missing symbols from the Python C API. Did you install Python with the dmg
installer from python.org? And can you give the output of "$ locate
Python.h"?

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131006/7ad03e1e/attachment.html>

From piet at vanoostrum.org  Sun Oct  6 23:39:45 2013
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Sun, 06 Oct 2013 23:39:45 -0400
Subject: [SciPy-User] 1.8.0rc1
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
	<m2eh801jc5.fsf@cochabamba.vanoostrum.org>
	<CABL7CQjF50vyPG5TwqnFaBLfGSbq_YSZdCfsyAdEGKE1NLTO_A@mail.gmail.com>
Message-ID: <m2d2nhzr3y.fsf@cochabamba.vanoostrum.org>

I should have added that yes, I have installed the DMG from python.org.
-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]



From piet at vanoostrum.org  Mon Oct  7 07:48:37 2013
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Mon, 07 Oct 2013 07:48:37 -0400
Subject: [SciPy-User] 1.8.0rc1
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
	<m2eh801jc5.fsf@cochabamba.vanoostrum.org>
	<CABL7CQjF50vyPG5TwqnFaBLfGSbq_YSZdCfsyAdEGKE1NLTO_A@mail.gmail.com>
Message-ID: <m2bo31z4h6.fsf@cochabamba.vanoostrum.org>

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

> On Sat, Oct 5, 2013 at 5:34 AM, Piet van Oostrum <piet at vanoostrum.org> wrote:
>
>     Ralf Gommers <ralf.gommers at gmail.com> writes:
>    
>     > Piet, you should get one of the ones recommended at http://scipy.org/scipylib/building/
>     macosx.html
>     > #fortran?
>     >
>     > The last error, test_io.TestSavezLoad, is real though. I can reproduce it, will try to
>     figure it
>     > out.
>     >
>     I have installed gfortran 4.2.3, which is the one recommended for Snow leopard:
>    
>     bash-3.2$ gfortran -v
>     Using built-in specs.
>     Target: i686-apple-darwin8
>     Configured with: /Builds/unix/gcc/gcc-4.2/configure --prefix=/usr/local --mandir=/share/man
>     --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --build=i686-apple-darwin8 --host=
>     i686-apple-darwin8 --target=i686-apple-darwin8 --enable-languages=fortran
>     Thread model: posix
>     gcc version 4.2.3
>
> I can't reproduce it with the exact same OS and Fortran compiler. Looking at the tracebacks a bit
> more carefully, I see that the compile fails on missing symbols from the Python C API. Did you
> install Python with the dmg installer from python.org? And can you give the output of "$ locate
> Python.h"?

It does contain (among others) /Library/Frameworks/Python.framework/Versions/3.3/include/python3.3m/Python.h (I am using Python 3.3.2)

I have some progress: I reinstalled XCode 3.2.6 after removing the old XCode. And I run the test with the default gcc, which is gcc-4.2 (=version 4.2.1). 

$ gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

On my previous test I used 

$ export CC=/usr/bin/gcc-4.0
$ export CXX=/usr/bin/g++-4.0

as recommended in http://scipy.org/scipylib/building/macosx.html, but maybe this recommendation is outdated as the Python is compiled with gcc version 4.2.1

Now there is only one error left:

ERROR: test_big_arrays (test_io.TestSavezLoad)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/testing/decorators.py", line 146, in skipper_func
    return f(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/tests/test_io.py", line 149, in test_big_arrays
    np.savez(tmp, a=a)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/npyio.py", line 530, in savez
    _savez(file, args, kwds, False)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/npyio.py", line 589, in _savez
    format.write_array(fid, np.asanyarray(val))
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/format.py", line 417, in write_array
    fp.write(array.tostring('C'))
OSError: [Errno 22] Invalid argument

That's the one you mentioned I think.
-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]



From ralf.gommers at gmail.com  Mon Oct  7 14:31:32 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 7 Oct 2013 20:31:32 +0200
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <m2bo31z4h6.fsf@cochabamba.vanoostrum.org>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
	<m2eh801jc5.fsf@cochabamba.vanoostrum.org>
	<CABL7CQjF50vyPG5TwqnFaBLfGSbq_YSZdCfsyAdEGKE1NLTO_A@mail.gmail.com>
	<m2bo31z4h6.fsf@cochabamba.vanoostrum.org>
Message-ID: <CABL7CQgaJGYF_re-zasg-uiLqigk8F=FXOGJMH+S11_Mq2yVag@mail.gmail.com>

On Mon, Oct 7, 2013 at 1:48 PM, Piet van Oostrum <piet at vanoostrum.org>wrote:

> Ralf Gommers <ralf.gommers at gmail.com> writes:
>
> > On Sat, Oct 5, 2013 at 5:34 AM, Piet van Oostrum <piet at vanoostrum.org>
> wrote:
> >
> >     Ralf Gommers <ralf.gommers at gmail.com> writes:
> >
> >     > Piet, you should get one of the ones recommended at
> http://scipy.org/scipylib/building/
> >     macosx.html
> >     > #fortran
> >     >
> >     > The last error, test_io.TestSavezLoad, is real though. I can
> reproduce it, will try to
> >     figure it
> >     > out.
> >     >
> >     I have installed gfortran 4.2.3, which is the one recommended for
> Snow leopard:
> >
> >     bash-3.2$ gfortran -v
> >     Using built-in specs.
> >     Target: i686-apple-darwin8
> >     Configured with: /Builds/unix/gcc/gcc-4.2/configure
> --prefix=/usr/local --mandir=/share/man
> >     --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> --build=i686-apple-darwin8 --host=
> >     i686-apple-darwin8 --target=i686-apple-darwin8
> --enable-languages=fortran
> >     Thread model: posix
> >     gcc version 4.2.3
> >
> > I can't reproduce it with the exact same OS and Fortran compiler.
> Looking at the tracebacks a bit
> > more carefully, I see that the compile fails on missing symbols from the
> Python C API. Did you
> > install Python with the dmg installer from python.org? And can you give
> the output of "$ locate
> > Python.h"?
>
> It does contain (among others)
> /Library/Frameworks/Python.framework/Versions/3.3/include/python3.3m/Python.h
> (I am using Python 3.3.2)
>
> I have some progress: I reinstalled XCode 3.2.6 after removing the old
> XCode. And I run the test with the default gcc, which is gcc-4.2 (=version
> 4.2.1).
>
> $ gcc-4.2 -v
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure
> --disable-checking --enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
> --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
> --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
> --with-gxx-include-dir=/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
>
> On my previous test I used
>
> $ export CC=/usr/bin/gcc-4.0
> $ export CXX=/usr/bin/g++-4.0
>
> as recommended in http://scipy.org/scipylib/building/macosx.html, but
> maybe this recommendation is outdated as the Python is compiled with gcc
> version 4.2.1
>

Ah yes. The recommendation is still valid for Python 2.6, which was the
highest Python version available at the time those instructions were
written. Python 2.7 from python.org was compiled with gcc 4.2 instead of
4.0.


>
> Now there is only one error left:
>
> ERROR: test_big_arrays (test_io.TestSavezLoad)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/testing/decorators.py",
> line 146, in skipper_func
>     return f(*args, **kwargs)
>   File
> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/tests/test_io.py",
> line 149, in test_big_arrays
>     np.savez(tmp, a=a)
>   File
> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/npyio.py",
> line 530, in savez
>     _savez(file, args, kwds, False)
>   File
> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/npyio.py",
> line 589, in _savez
>     format.write_array(fid, np.asanyarray(val))
>   File
> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/format.py",
> line 417, in write_array
>     fp.write(array.tostring('C'))
> OSError: [Errno 22] Invalid argument
>
> That's the one you mentioned I think.
>

Indeed. That error will be silenced in the final 1.8.0 release. You've got
everything working correctly now.

Cheers,
Ralf



> --
> Piet van Oostrum <piet at vanoostrum.org>
> WWW: http://pietvanoostrum.com/
> PGP key: [8DAE142BE17999C4]
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131007/27b48eba/attachment.html>

From sergio_r at mail.com  Mon Oct  7 15:11:56 2013
From: sergio_r at mail.com (Sergio Rojas)
Date: Mon, 07 Oct 2013 15:11:56 -0400
Subject: [SciPy-User] Installing SciPy version 0.13.0b1: 1 test fail
Message-ID: <20131007191156.230970@gmx.com>

Installing SciPy version 0.13.0b1 ended with a fail test message [1]
which does not look too critical as the numerical values match
close to single precision.

I am curious, however, about a deprecated message given at the
beginning of the test:

"
 DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg.lapack
`" and a few others.

How we are suppose to fix that in using scipy?

Sergio
[1]

======================================================================^M
FAIL: test_qz_complex64 (test_decomp.TestQZ)^M
----------------------------------------------------------------------^M
Traceback (most recent call last):^M
 File "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/scipy/li
nalg/tests/test_decomp.py", line 1781, in test_qz_complex64^M
 assert_array_almost_equal(dot(dot(Q,AA),Z.conjugate().T), A)^M
 File "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
sting/utils.py", line 812, in assert_array_almost_equal^M
 header=('Arrays are not almost equal to %d decimals' % decimal))^M
 File "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
sting/utils.py", line 645, in assert_array_compare^M
 raise AssertionError(msg)^M
AssertionError: ^M
Arrays are not almost equal to 6 decimals^M
^M
(mismatch 4.0%)^M
 x: array([[ 0.92961568+0.729689j , 0.31637624+0.99401343j,^M
 0.18391913+0.67687303j, 0.20456031+0.79082209j,^M
 0.56772494+0.17091393j],...^M
 y: array([[ 0.92961609+0.72968906j, 0.31637555+0.99401456j,^M
 0.18391882+0.67687368j, 0.20456028+0.79082251j,^M
 0.56772500+0.17091426j],...^M
^M
----------------------------------------------------------------------^M
Ran 9902 tests in 895.284s^M
^M
FAILED (KNOWNFAIL=131, SKIP=324, failures=1)^M
<nose.result.TextTestResult run=9902 errors=0 failures=1>^M

Python 2.7.3 (default, Sep 30 2013, 13:55:58) ^M
[GCC 4.6.3] on linux2^M
Type "help", "copyright", "credits" or "license" for more information.^M

Type "help", "copyright", "credits" or "license" for more information.^M
>>> import scipy^M
>>> scipy.show_config()^M
amd_info:^M
 libraries = ['amd']^M
 library_dirs = ['/home/myProg/NumLibs64b/lib']^M
 define_macros = [('SCIPY_AMD_H', None)]^M
 swig_opts = ['-I/home/myProg/NumLibs64b/include']^M
 include_dirs = ['/home/myProg/NumLibs64b/include']^M
umfpack_info:^M
 libraries = ['umfpack', 'amd']^M
 library_dirs = ['/home/myProg/NumLibs64b/lib']^M
 define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]^M
 swig_opts = ['-I/home/myProg/NumLibs64b/include', '-I/home/myProg/NumLibs64
b/include']^M
 include_dirs = ['/home/myProg/NumLibs64b/include']^M
atlas_threads_info:^M
 libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']^M
 library_dirs = ['/home/myProg/NumLibs64b/lib']^M
 define_macros = [('NO_ATLAS_INFO', -1)]^M
 language = f77^M
 include_dirs = ['/home/myProg/NumLibs64b/include']^M
blas_opt_info:^M
 libraries = ['ptf77blas', 'ptcblas', 'atlas']^M
 library_dirs = ['/home/myProg/NumLibs64b/lib']^M
 define_macros = [('NO_ATLAS_INFO', -1)]^M
 language = c^M
 include_dirs = ['/home/myProg/NumLibs64b/include']^M
atlas_blas_threads_info:^M
 libraries = ['ptf77blas', 'ptcblas', 'atlas']^M
 library_dirs = ['/home/myProg/NumLibs64b/lib']^M
 define_macros = [('NO_ATLAS_INFO', -1)]^M
 language = c^M
 include_dirs = ['/home/myProg/NumLibs64b/include']^M
lapack_opt_info:^M
 libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']^M
 library_dirs = ['/home/myProg/NumLibs64b/lib']^M
 define_macros = [('NO_ATLAS_INFO', -1)]^M
 language = f77^M
 include_dirs = ['/home/myProg/NumLibs64b/include']^M
lapack_mkl_info:^M
 NOT AVAILABLE^M
blas_mkl_info:^M
 NOT AVAILABLE^M
mkl_info:^M
 NOT AVAILABLE^M
>>> scipy.test('full', verbose=2)^M
Running unit tests for scipy^M
NumPy version 1.7.0^M
NumPy is installed in /home/myProg/Python273GNU/Linux64b/lib/python2.7/site-pac
kages/numpy^M
SciPy version 0.13.0b1^M
SciPy is installed in /home/myProg/Python273GNU/Linux64b/lib/python2.7/site-pac
kages/scipy^M
Python version 2.7.3 (default, Sep 30 2013, 13:55:58) [GCC 4.6.3]^M
nose version 1.3.0^M
/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/lib/utils.
py:139: DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.b
las` instead!^M
 warnings.warn(depdoc, DeprecationWarning)^M
/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/lib/utils.
py:139: DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg
.lapack` instead!^M
...
...
======================================================================
FAIL: test_qz_complex64 (test_decomp.TestQZ)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/scipy/li
nalg/tests/test_decomp.py", line 1781, in test_qz_complex64
 assert_array_almost_equal(dot(dot(Q,AA),Z.conjugate().T), A)
 File "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
sting/utils.py", line 812, in assert_array_almost_equal
 header=('Arrays are not almost equal to %d decimals' % decimal))
 File "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
sting/utils.py", line 645, in assert_array_compare
 raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 6 decimals

(mismatch 4.0%)
 x: array([[ 0.92961568+0.729689j , 0.31637624+0.99401343j,
 0.18391913+0.67687303j, 0.20456031+0.79082209j,
 0.56772494+0.17091393j],...
 y: array([[ 0.92961609+0.72968906j, 0.31637555+0.99401456j,
 0.18391882+0.67687368j, 0.20456028+0.79082251j,
 0.56772500+0.17091426j],...

----------------------------------------------------------------------
Ran 9902 tests in 895.284s

FAILED (KNOWNFAIL=131, SKIP=324, failures=1)
<nose.result.TextTestResult run=9902 errors=0 failures=1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131007/a5cd15a4/attachment.html>

From ralf.gommers at gmail.com  Mon Oct  7 15:16:14 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 7 Oct 2013 21:16:14 +0200
Subject: [SciPy-User] Installing SciPy version 0.13.0b1: 1 test fail
In-Reply-To: <20131007191156.230970@gmx.com>
References: <20131007191156.230970@gmx.com>
Message-ID: <CABL7CQj+Yqvk+4M869=8edoqGauxrvVka03v7oHf8K30t-f8ag@mail.gmail.com>

On Mon, Oct 7, 2013 at 9:11 PM, Sergio Rojas <sergio_r at mail.com> wrote:

>
> Installing SciPy version 0.13.0b1 ended with a fail test message [1]
> which does not look too critical as the numerical values match
> close to single precision.
>

That test failure is fixed now in the 0.13.x branch.


>
> I am curious, however, about a deprecated message given at the
> beginning of the test:
>
> "
>  DeprecationWarning: `scipy.lib.lapack` is deprecated, use
> `scipy.linalg.lapack
> `" and a few others.
>
> How we are suppose to fix that in using scipy?
>

You're supposed to fix the warning, but if you have old code that imports
from scipy.lib you have to switch it over to scipy.linalg to avoid it
breaking with a future release.

Cheers,
Ralf



>
> Sergio
> [1]
>
> ======================================================================^M
> FAIL: test_qz_complex64 (test_decomp.TestQZ)^M
> ----------------------------------------------------------------------^M
> Traceback (most recent call last):^M
>   File
> "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/scipy/li
> nalg/tests/test_decomp.py", line 1781, in test_qz_complex64^M
>     assert_array_almost_equal(dot(dot(Q,AA),Z.conjugate().T), A)^M
>   File
> "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
> sting/utils.py", line 812, in assert_array_almost_equal^M
>     header=('Arrays are not almost equal to %d decimals' % decimal))^M
>   File
> "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
> sting/utils.py", line 645, in assert_array_compare^M
>     raise AssertionError(msg)^M
> AssertionError: ^M
> Arrays are not almost equal to 6 decimals^M
> ^M
> (mismatch 4.0%)^M
>  x: array([[ 0.92961568+0.729689j  ,  0.31637624+0.99401343j,^M
>          0.18391913+0.67687303j,  0.20456031+0.79082209j,^M
>          0.56772494+0.17091393j],...^M
>  y: array([[ 0.92961609+0.72968906j,  0.31637555+0.99401456j,^M
>          0.18391882+0.67687368j,  0.20456028+0.79082251j,^M
>          0.56772500+0.17091426j],...^M
> ^M
> ----------------------------------------------------------------------^M
> Ran 9902 tests in 895.284s^M
> ^M
> FAILED (KNOWNFAIL=131, SKIP=324, failures=1)^M
> <nose.result.TextTestResult run=9902 errors=0 failures=1>^M
>
> Python 2.7.3 (default, Sep 30 2013, 13:55:58) ^M
> [GCC 4.6.3] on linux2^M
> Type "help", "copyright", "credits" or "license" for more information.^M
>
> Type "help", "copyright", "credits" or "license" for more information.^M
> >>> import scipy^M
> >>> scipy.show_config()^M
> amd_info:^M
>     libraries = ['amd']^M
>     library_dirs = ['/home/myProg/NumLibs64b/lib']^M
>     define_macros = [('SCIPY_AMD_H', None)]^M
>     swig_opts = ['-I/home/myProg/NumLibs64b/include']^M
>     include_dirs = ['/home/myProg/NumLibs64b/include']^M
> umfpack_info:^M
>     libraries = ['umfpack', 'amd']^M
>     library_dirs = ['/home/myProg/NumLibs64b/lib']^M
>     define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]^M
>     swig_opts = ['-I/home/myProg/NumLibs64b/include',
> '-I/home/myProg/NumLibs64
> b/include']^M
>     include_dirs = ['/home/myProg/NumLibs64b/include']^M
> atlas_threads_info:^M
>     libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']^M
>     library_dirs = ['/home/myProg/NumLibs64b/lib']^M
>     define_macros = [('NO_ATLAS_INFO', -1)]^M
>     language = f77^M
>     include_dirs = ['/home/myProg/NumLibs64b/include']^M
> blas_opt_info:^M
>     libraries = ['ptf77blas', 'ptcblas', 'atlas']^M
>     library_dirs = ['/home/myProg/NumLibs64b/lib']^M
>     define_macros = [('NO_ATLAS_INFO', -1)]^M
>     language = c^M
>     include_dirs = ['/home/myProg/NumLibs64b/include']^M
> atlas_blas_threads_info:^M
>     libraries = ['ptf77blas', 'ptcblas', 'atlas']^M
>     library_dirs = ['/home/myProg/NumLibs64b/lib']^M
>     define_macros = [('NO_ATLAS_INFO', -1)]^M
>     language = c^M
>     include_dirs = ['/home/myProg/NumLibs64b/include']^M
> lapack_opt_info:^M
>     libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']^M
>     library_dirs = ['/home/myProg/NumLibs64b/lib']^M
>     define_macros = [('NO_ATLAS_INFO', -1)]^M
>     language = f77^M
>     include_dirs = ['/home/myProg/NumLibs64b/include']^M
> lapack_mkl_info:^M
>   NOT AVAILABLE^M
> blas_mkl_info:^M
>   NOT AVAILABLE^M
> mkl_info:^M
>   NOT AVAILABLE^M
> >>> scipy.test('full', verbose=2)^M
> Running unit tests for scipy^M
> NumPy version 1.7.0^M
> NumPy is installed in
> /home/myProg/Python273GNU/Linux64b/lib/python2.7/site-pac
> kages/numpy^M
> SciPy version 0.13.0b1^M
> SciPy is installed in
> /home/myProg/Python273GNU/Linux64b/lib/python2.7/site-pac
> kages/scipy^M
> Python version 2.7.3 (default, Sep 30 2013, 13:55:58) [GCC 4.6.3]^M
> nose version 1.3.0^M
>
> /home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/lib/utils.
> py:139: DeprecationWarning: `scipy.lib.blas` is deprecated, use
> `scipy.linalg.b
> las` instead!^M
>   warnings.warn(depdoc, DeprecationWarning)^M
>
> /home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/lib/utils.
> py:139: DeprecationWarning: `scipy.lib.lapack` is deprecated, use
> `scipy.linalg
> .lapack` instead!^M
> ...
> ...
> ======================================================================
> FAIL: test_qz_complex64 (test_decomp.TestQZ)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/scipy/li
> nalg/tests/test_decomp.py", line 1781, in test_qz_complex64
>     assert_array_almost_equal(dot(dot(Q,AA),Z.conjugate().T), A)
>   File
> "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
> sting/utils.py", line 812, in assert_array_almost_equal
>     header=('Arrays are not almost equal to %d decimals' % decimal))
>   File
> "/home/myProg/Python273GNU/Linux64b/lib/python2.7/site-packages/numpy/te
> sting/utils.py", line 645, in assert_array_compare
>     raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 6 decimals
>
> (mismatch 4.0%)
>  x: array([[ 0.92961568+0.729689j  ,  0.31637624+0.99401343j,
>          0.18391913+0.67687303j,  0.20456031+0.79082209j,
>          0.56772494+0.17091393j],...
>  y: array([[ 0.92961609+0.72968906j,  0.31637555+0.99401456j,
>          0.18391882+0.67687368j,  0.20456028+0.79082251j,
>          0.56772500+0.17091426j],...
>
> ----------------------------------------------------------------------
> Ran 9902 tests in 895.284s
>
> FAILED (KNOWNFAIL=131, SKIP=324, failures=1)
> <nose.result.TextTestResult run=9902 errors=0 failures=1>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131007/9c645217/attachment.html>

From piet at vanoostrum.org  Mon Oct  7 17:34:53 2013
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Mon, 07 Oct 2013 17:34:53 -0400
Subject: [SciPy-User] 1.8.0rc1
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
	<m2eh801jc5.fsf@cochabamba.vanoostrum.org>
	<CABL7CQjF50vyPG5TwqnFaBLfGSbq_YSZdCfsyAdEGKE1NLTO_A@mail.gmail.com>
	<m2bo31z4h6.fsf@cochabamba.vanoostrum.org>
Message-ID: <m238oczrwi.fsf@cochabamba.vanoostrum.org>

On Python 2.7.5 the test runs without errors, so this might be a Python3 problem (maybe bytes/string confusion?).
-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]



From charlesr.harris at gmail.com  Mon Oct  7 18:12:09 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 7 Oct 2013 16:12:09 -0600
Subject: [SciPy-User] 1.8.0rc1
In-Reply-To: <m238oczrwi.fsf@cochabamba.vanoostrum.org>
References: <CAB6mnxJ+WAucyTEoj4w6nN67ja=jWH3kU+b7AZ+K4M1B37HH0g@mail.gmail.com>
	<m2siwjjtxp.fsf@cochabamba.vanoostrum.org>
	<CAB6mnxJR2wVrZ5hE5iM=PPN3ia5gJtvxMC-5Yq8nowLjOtTn6A@mail.gmail.com>
	<CAH6Pt5rS4WL5gcsONR5TTKgt2RCHW=iJM-NAAp=+hhkahd0geQ@mail.gmail.com>
	<CAB6mnxJAnr1KpTPG42hNUkWn1zypsFo4dcX+nYi6h2hSqga4pw@mail.gmail.com>
	<CABL7CQguSvRWQz8-B2qbS7dzxcsxyX9+fEmbP-mQop_Vq=86YA@mail.gmail.com>
	<m2eh801jc5.fsf@cochabamba.vanoostrum.org>
	<CABL7CQjF50vyPG5TwqnFaBLfGSbq_YSZdCfsyAdEGKE1NLTO_A@mail.gmail.com>
	<m2bo31z4h6.fsf@cochabamba.vanoostrum.org>
	<m238oczrwi.fsf@cochabamba.vanoostrum.org>
Message-ID: <CAB6mnxKwz=wKpFmdkho9JgbAAc690VyRovNrF_-7YG3JnOgWwA@mail.gmail.com>

On Mon, Oct 7, 2013 at 3:34 PM, Piet van Oostrum <piet at vanoostrum.org>wrote:

> On Python 2.7.5 the test runs without errors, so this might be a Python3
> problem (maybe bytes/string confusion?).
>

There is a suspicion that it may be failing silently on 2.7.5.

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131007/db59fa1b/attachment.html>

From sgarcia at olfac.univ-lyon1.fr  Tue Oct  8 05:58:44 2013
From: sgarcia at olfac.univ-lyon1.fr (Samuel Garcia)
Date: Tue, 08 Oct 2013 11:58:44 +0200
Subject: [SciPy-User] [ANN] Release python-neo 0.3.1
Message-ID: <5253D754.5000304@olfac.univ-lyon1.fr>

Hi all,
Neo 0.3.1 have been released!!

Neo is a package for representing electrophysiology data in Python, 
together with support for reading a wide range of neurophysiology file 
formats, including Spike2, NeuroExplorer, AlphaOmega, Axon, Blackrock, 
Plexon, Tdt, and support for writing to a subset of these formats plus 
non-proprietary formats including HDF5.

http://pythonhosted.org/neo/


New:
   * lazy/cascading improvement
   * load_lazy_olbject() in neo.io added
   * added NeuroscopeIO



Have a good day.


The neo team.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samuel Garcia
Lyon Neuroscience
CNRS - UMR5292 -  INSERM U1028 -  Universite Claude Bernard LYON 1
Equipe R et D
50, avenue Tony Garnier
69366 LYON Cedex 07
FRANCE
T?l : 04 37 28 74 24
Fax : 04 37 28 76 01
http://olfac.univ-lyon1.fr/unite/equipe-07/
http://neuralensemble.org/trac/OpenElectrophy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131008/53645855/attachment.html>

From timmichelsen at gmx-topmail.de  Tue Oct  8 07:34:59 2013
From: timmichelsen at gmx-topmail.de (Timmie)
Date: Tue, 8 Oct 2013 11:34:59 +0000 (UTC)
Subject: [SciPy-User] Euo Scipy 2013 Proceedings
Message-ID: <loom.20131008T133351-451@post.gmane.org>

Hello,
is there a page where I can download the processings from the conferenece?

I cannot find them at:
https://www.euroscipy.org/schedule/general-sessions/

Thanks in advance.

Kind regards,
Timmie



From nelle.varoquaux at gmail.com  Tue Oct  8 08:09:07 2013
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Tue, 8 Oct 2013 14:09:07 +0200
Subject: [SciPy-User] Euo Scipy 2013 Proceedings
In-Reply-To: <loom.20131008T133351-451@post.gmane.org>
References: <loom.20131008T133351-451@post.gmane.org>
Message-ID: <CAE-UAvR-dDZ5iZH75--NMc9N3PesBGWGBJdyBm1EZDVgn9e1Vw@mail.gmail.com>

Hello,

We are currently reviewing the papers. Hence, there's nothing yet online
for the proceedings.

Thanks,
N


On 8 October 2013 13:34, Timmie <timmichelsen at gmx-topmail.de> wrote:

> Hello,
> is there a page where I can download the processings from the conferenece?
>
> I cannot find them at:
> https://www.euroscipy.org/schedule/general-sessions/
>
> Thanks in advance.
>
> Kind regards,
> Timmie
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131008/88faf151/attachment.html>

From timmichelsen at gmx-topmail.de  Tue Oct  8 08:15:06 2013
From: timmichelsen at gmx-topmail.de (Timmie)
Date: Tue, 8 Oct 2013 12:15:06 +0000 (UTC)
Subject: [SciPy-User] Euo Scipy 2013 Proceedings
References: <loom.20131008T133351-451@post.gmane.org>
	<CAE-UAvR-dDZ5iZH75--NMc9N3PesBGWGBJdyBm1EZDVgn9e1Vw@mail.gmail.com>
Message-ID: <loom.20131008T141441-194@post.gmane.org>

> We are currently reviewing the papers. Hence, there's nothing yet online 
OK, thanks for your answer and looking forward to it.

Thanks for your efforts.



From boost.subscribing at gmail.com  Wed Oct  9 06:53:43 2013
From: boost.subscribing at gmail.com (cat fa)
Date: Wed, 9 Oct 2013 18:53:43 +0800
Subject: [SciPy-User] Fwd: Can scipy.sparse add support to other numeric
	type?
In-Reply-To: <CAMbARA5Jigqq-xJU8F0LSyCiHcON6z3gh1Z-TK80z7gQos3-5A@mail.gmail.com>
References: <CAMbARA5Jigqq-xJU8F0LSyCiHcON6z3gh1Z-TK80z7gQos3-5A@mail.gmail.com>
Message-ID: <CAMbARA6my6iPsCSaLB9RWRLC=Z8mZjSC+EY0+v21mXh79igDHw@mail.gmail.com>

Hi everyone,
    In the source code of ..\scipy\sparse\sputils.py, the upcast
function only support these types

int8, uint8,
short, ushort,
intc, uintc,
longlong, ulonglong,
single, double, longdouble,
csingle, cdouble, clongdouble.

Now I want to use sparse matrix to store ad(an automatic
differentiation object) type. When I do some calculation operation, I
got TypeError exception:

TypeError: no supported conversion for types: object


Is there a easy way to get sparse matrix to support other numeric type?


From mnewcomb at wisc.edu  Mon Oct  7 14:55:43 2013
From: mnewcomb at wisc.edu (Matt Newcomb)
Date: Mon, 7 Oct 2013 13:55:43 -0500
Subject: [SciPy-User] scipy IFFT question ( time N+1 wraps back to time 0 )
Message-ID: <CAHsmP0LVn67fxnika_qWkKS64e97gV_xT-DC4m=07xVD+jX-+A@mail.gmail.com>

Hi,

I've got the transfer function of an  LTI system  (H(s)).  The input to the
system is a 1 ns pulse delayed by X ns ( x(t) )  If I compute the response
function by taking the fft of the input to the system multiplying and then
taking the ifft I see the impulse response to the system just shifted by X
ns.  That's expected but the problem is that the tail of the system
response wraps around and appears at time 0 in the ifft.   NOT what I
wanted.  How do I get rid of this?

Thank you,

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131007/a3e5d0bc/attachment.html>

From Jean-Francois.Moulin at hzg.de  Wed Oct  9 09:43:17 2013
From: Jean-Francois.Moulin at hzg.de (Jean-Francois.Moulin at hzg.de)
Date: Wed, 9 Oct 2013 15:43:17 +0200
Subject: [SciPy-User] optimize.fmin_slsqp bounds problem
Message-ID: <OF98DF3BEE.A477FC71-ONC1257BFF.004B6000-C1257BFF.004B6003@LocalDomain>

 Hi Everyone,

I am having trouble with scipy.optimize.fmin_slsqp, I get a bounds problem:

my objective function objfn returns the sum of the squared deviations 

bounds = [(-1e-09, 1e-08), (1e-07, 1e-05), (1e-07, 1e-05), (1e-10, 1e-08), (1e-10, 1e-08), (1e-10, 1e-08), (80.0, 200.0), (1.0, 5.0), (1.0, 5.0)]
x0 = array([  0.00000000e+00,   1.01000000e-06,   3.03000000e-06,
              1.00000000e-09,   1.00000000e-09,   1.00000000e-09,
              1.50000000e+02,   2.00000000e+00,   2.00000000e+00])
res = fmin_slsqp(objfn,p.array(x0,dtype=float),bounds=bounds,full_output=True)
...
Inequality constraints incompatible    (Exit mode 4)
            Current function value: 450.575453753
            Iterations: 1
            Function evaluations: 11
            Gradient evaluations: 1

Looking at what happens inside slsqp.py, in _minimize_slsqp I checked that the bounds and the trial value of the variable make sense:
(xl<xu).all()
True
(x>xl).all()
True
(x<xu).all()
True

I have not used anything else than the bounds...

Any clue?

Thanks in advance!
Helmholtz-Zentrum Geesthacht 
Zentrum f?r Material- und K?stenforschung GmbH 
Max-Planck-Stra?e 1 I 21502 Geesthacht I Deutschland/Germany 

Gesch?ftsf?hrer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. Michael Gan? 
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: MinDirig Wilfried Kraus 
Amtsgericht L?beck HRB 285 GE (Register Court) 
Internet: http://www.hzg.de  


From sgarcia at olfac.univ-lyon1.fr  Wed Oct  9 09:56:43 2013
From: sgarcia at olfac.univ-lyon1.fr (Samuel Garcia)
Date: Wed, 09 Oct 2013 15:56:43 +0200
Subject: [SciPy-User] ANN: OpenElectrophy 0.3.3
Message-ID: <5255609B.10303@olfac.univ-lyon1.fr>

Hi all,
pleased to announce the release of OpenElectrophy 0.3.3

OpenElectrophy is a python module for electrophysioly data analysis 
(intra- and extra-cellular).

http://pythonhosted.org/OpenElectrophy/


But OpenElectrophy provide:
   * A complete offline spikesorting tool chain = GUI and/or command line.
   * A timefrequency toolbox = fast wavelet scalogram plotting + 
transient oscillation in LFP detection.
   * Viewers for neo objects.
   * A database for storage.


Best,


Samuel

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samuel Garcia
Lyon Neuroscience
CNRS - UMR5292 -  INSERM U1028 -  Universite Claude Bernard LYON 1
Equipe R et D
50, avenue Tony Garnier
69366 LYON Cedex 07
FRANCE
T?l : 04 37 28 74 24
Fax : 04 37 28 76 01
http://olfac.univ-lyon1.fr/unite/equipe-07/
http://neuralensemble.org/trac/OpenElectrophy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131009/be23dead/attachment.html>

From pav at iki.fi  Wed Oct  9 13:07:37 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 09 Oct 2013 20:07:37 +0300
Subject: [SciPy-User] optimize.fmin_slsqp bounds problem
In-Reply-To: <OF98DF3BEE.A477FC71-ONC1257BFF.004B6000-C1257BFF.004B6003@LocalDomain>
References: <OF98DF3BEE.A477FC71-ONC1257BFF.004B6000-C1257BFF.004B6003@LocalDomain>
Message-ID: <l342gh$mr5$1@ger.gmane.org>

09.10.2013 16:43, Jean-Francois.Moulin at hzg.de kirjoitti:
[clip]
> my objective function objfn returns the sum of the squared deviations 
> 
> bounds = [(-1e-09, 1e-08), (1e-07, 1e-05), (1e-07, 1e-05), (1e-10, 1e-08), (1e-10, 1e-08), (1e-10, 1e-08), (80.0, 200.0), (1.0, 5.0), (1.0, 5.0)]
> x0 = array([  0.00000000e+00,   1.01000000e-06,   3.03000000e-06,
>               1.00000000e-09,   1.00000000e-09,   1.00000000e-09,
>               1.50000000e+02,   2.00000000e+00,   2.00000000e+00])
> res = fmin_slsqp(objfn,p.array(x0,dtype=float),bounds=bounds,full_output=True)
> ...
> Inequality constraints incompatible    (Exit mode 4)
>             Current function value: 450.575453753
>             Iterations: 1
>             Function evaluations: 11
>             Gradient evaluations: 1

http://sscce.org/

Please provide a self-contained reproducible example. What is the exact
objfn?

I don't get any errors with

------------------------------
import numpy as np
from scipy.optimize import fmin_slsqp

np.random.seed(1234)
y = np.random.randn(9) * 100
def objfn(x):
        return ((x - y)**2).sum()

bounds = [(-1e-09, 1e-08), (1e-07, 1e-05), (1e-07, 1e-05), (1e-10,
1e-08), (1e-10, 1e-08), (1e-10, 1e-08), (80.0, 200.0), (1.0, 5.0), (1.0,
5.0)]
x0 = np.array([  0.00000000e+00,   1.01000000e-06,   3.03000000e-06,
                 1.00000000e-09,   1.00000000e-09,   1.00000000e-09,
                 1.50000000e+02,   2.00000000e+00,   2.00000000e+00])
res = fmin_slsqp(objfn,
np.array(x0,dtype=float),bounds=bounds,full_output=True)
------------------------------

The algorithm and code used (with permission from ACM) is this:
http://dl.acm.org/citation.cfm?id=192124

The only way to understand what goes wrong is probably to look in the
Fortran code and see what it does.

-- 
Pauli Virtanen



From Jean-Francois.Moulin at hzg.de  Wed Oct  9 16:43:18 2013
From: Jean-Francois.Moulin at hzg.de (Jean-Francois.Moulin at hzg.de)
Date: Wed, 9 Oct 2013 22:43:18 +0200
Subject: [SciPy-User] optimize.fmin_slsqp bounds problem
Message-ID: <OF9D241814.E110C311-ONC1257BFF.0071D429-C1257BFF.0071D42A@LocalDomain>

 

>http://sscce.org/
>
>Please provide a self-contained reproducible example. What is the exact objfn?
>
>I don't get any errors with
>
>------------------------------
>import numpy as np
>from scipy.optimize import fmin_slsqp>
>
>np.random.seed(1234)
>y = np.random.randn(9) * 100
>def objfn(x):
>        return ((x - y)**2).sum()
>
>bounds = [(-1e-09, 1e-08), (1e-07, 1e-05), (1e-07, 1e-05), (1e-10,
>1e-08), (1e-10, 1e-08), (1e-10, 1e-08), (80.0, 200.0), (1.0, 5.0), (1.0,
>5.0)]
>x0 = np.array([  0.00000000e+00,   1.01000000e-06,   3.03000000e-06,
>                 1.00000000e-09,   1.00000000e-09,   1.00000000e-09,
>                 1.50000000e+02,   2.00000000e+00,   2.00000000e+00])
>res = fmin_slsqp(objfn,
>np.array(x0,dtype=float),bounds=bounds,full_output=True)
>------------------------------

>The algorithm and code used (with permission from ACM) is this:
>http://dl.acm.org/citation.cfm?id=192124
>
>The only way to understand what goes wrong is probably to look in the
>Fortran code and see what it does.
>
>-- 
>Pauli Virtanen

Well my objective function is a quite complex recursive function of the 9 input parameters which in the end returns the sum of the squared deviation as expected by fmin_slsqp (it involves several of my own modules and a large dataset, so too long to be posted). I have checked that the return value is valid (not NAN eg) and as you see there is a single iteration done. 
I also have checked the minimizer with examples similar to yours, and it worked.
I'll have to get my hand Fortran dirty it seems, I just hoped someone had alreay had this kind of symptom and found a "trivial" error.
Thanks anyway!

JF
Helmholtz-Zentrum Geesthacht 
Zentrum f?r Material- und K?stenforschung GmbH 
Max-Planck-Stra?e 1 I 21502 Geesthacht I Deutschland/Germany 

Gesch?ftsf?hrer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. Michael Gan? 
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: MinDirig Wilfried Kraus 
Amtsgericht L?beck HRB 285 GE (Register Court) 
Internet: http://www.hzg.de  


From pav at iki.fi  Wed Oct  9 17:10:11 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 10 Oct 2013 00:10:11 +0300
Subject: [SciPy-User] optimize.fmin_slsqp bounds problem
In-Reply-To: <OF9D241814.E110C311-ONC1257BFF.0071D429-C1257BFF.0071D42A@LocalDomain>
References: <OF9D241814.E110C311-ONC1257BFF.0071D429-C1257BFF.0071D42A@LocalDomain>
Message-ID: <l34gna$vta$1@ger.gmane.org>

09.10.2013 23:43, Jean-Francois.Moulin at hzg.de kirjoitti:
[clip]
> Well my objective function is a quite complex recursive function of the 9 input
> parameters which in the end returns the sum of the squared deviation
as expected
> by fmin_slsqp (it involves several of my own modules and a large
dataset, so too long to be posted).

In such a case, you can record the values of the objective function and
coordinates for each call in a file. Assuming the rounding error is not
too bad, the result should be reproducible.

-- 
Pauli Virtanen



From pav at iki.fi  Wed Oct  9 17:19:25 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 10 Oct 2013 00:19:25 +0300
Subject: [SciPy-User] optimize.fmin_slsqp bounds problem
In-Reply-To: <l34gna$vta$1@ger.gmane.org>
References: <OF9D241814.E110C311-ONC1257BFF.0071D429-C1257BFF.0071D42A@LocalDomain>
	<l34gna$vta$1@ger.gmane.org>
Message-ID: <l34h8k$6lq$1@ger.gmane.org>

10.10.2013 00:10, Pauli Virtanen kirjoitti:
> 09.10.2013 23:43, Jean-Francois.Moulin at hzg.de kirjoitti: [clip]
>> Well my objective function is a quite complex recursive function
>> of the 9 input parameters which in the end returns the sum of the
>> squared deviation
> as expected
>> by fmin_slsqp (it involves several of my own modules and a large
> dataset, so too long to be posted).
> 
[clip]
> In such a case, you can record the values of the objective function
> and coordinates for each call in a file. Assuming the rounding
> error is not too bad, the result should be reproducible.

... but if you manage to find the reason why it fails yourself, please
follow up.

It seems possible that the issue is a bug in the original Fortran
code, as the conditions that lead to MODE=4 exit are not all that
clearly laid out there.

E.g. stuff like this

      IF(diff(one+fac,one).LE.ZERO) GOTO 50    # -> exit with mode=4

that apparently tries to work around rounding errors, but which
optimizing compilers may just optimize away.

-- 
Pauli Virtanen



From Jean-Francois.Moulin at hzg.de  Thu Oct 10 04:32:04 2013
From: Jean-Francois.Moulin at hzg.de (Jean-Francois.Moulin at hzg.de)
Date: Thu, 10 Oct 2013 10:32:04 +0200
Subject: [SciPy-User] optimize.fmin_slsqp bounds problem
In-Reply-To: <l34h8k$6lq$1@ger.gmane.org>
References: <l34h8k$6lq$1@ger.gmane.org>,
	<OF9D241814.E110C311-ONC1257BFF.0071D429-C1257BFF.0071D42A@LocalDomain><l34gna$vta$1@ger.gmane.org>
Message-ID: <OF3B103317.1E5FFF91-ONC1257C00.002EE193-C1257C00.002EE195@LocalDomain>


>... but if you manage to find the reason why it fails yourself, please
>follow up.

>It seems possible that the issue is a bug in the original Fortran
>code, as the conditions that lead to MODE=4 exit are not all that
>clearly laid out there.

>E.g. stuff like this
>
>?? ? ?IF(diff(one+fac,one).LE.ZERO) GOTO 50 ? ?# -> exit with mode=4
>
>that apparently tries to work around rounding errors, but which
>optimizing compilers may just optimize away.
>
>-- 
>Pauli Virtanen

Here is some follow up (I would not have dropped the topic whithout mentioning the results of my dayly commute work ;0)
It seems that although my X0 respects the initial conditions, during the evaluation of the gradients some forbidden regions of the parameter space are explored. The affected parameters seem to have a very weak (maybe down to zero) influence on the function output. So the chi2 landscape is very very flat in these directions. While performing the first iteration the function is then evaluated outside of the bounds for these parameters or I fall in one of these rounding traps you mention.
I will try to rewrite my model without these apparently irrelevant parameters and see if it converges to something physically reasonable.
I'll keep posting...
Helmholtz-Zentrum Geesthacht 
Zentrum f?r Material- und K?stenforschung GmbH 
Max-Planck-Stra?e 1 I 21502 Geesthacht I Deutschland/Germany 

Gesch?ftsf?hrer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. Michael Gan? 
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: MinDirig Wilfried Kraus 
Amtsgericht L?beck HRB 285 GE (Register Court) 
Internet: http://www.hzg.de  


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-User] 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.scipy.org/pipermail/scipy-user/attachments/20131011/a8afd8c5/attachment.html>

From mueller at pitt.edu  Fri Oct 11 11:57:02 2013
From: mueller at pitt.edu (Mueller, James A.)
Date: Fri, 11 Oct 2013 11:57:02 -0400
Subject: [SciPy-User] fixed_quad documentation
Message-ID: <B16AFEDB-53F8-412D-A19B-558766E94C72@pitt.edu>

In my undergraduate Computational Physics class we are have been doing integration, and some of my students were trying out scipy.integrate.fixed_quad.  They got a little fouled up because the documentation says it returns a float, while it actually returns a tuple.  I just took a look at docs.scipy.org and see that for scipy-0.7, it says it returns (val, None), which appears to still be correct.  Oh well, it gave them a chance to see the error message when you try to multiply a tuple with a float.

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-User] 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.scipy.org/pipermail/scipy-user/attachments/20131012/eab9fb9a/attachment.html>

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-User] 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.scipy.org/pipermail/scipy-user/attachments/20131014/efea3a8e/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-User] [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-User] [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.scipy.org/pipermail/scipy-user/attachments/20131015/ed44cff4/attachment.html>

From subhabangalore at gmail.com  Tue Oct 15 22:28:09 2013
From: subhabangalore at gmail.com (Subhabrata Banerjee)
Date: Wed, 16 Oct 2013 07:58:09 +0530
Subject: [SciPy-User] [ANN] CFP: SciPy India 2013: Dec 13 - 15,
	IIT Bombay
Message-ID: <CADBiVjF2cW8v1E8aHixa=ooFpcQa9HfC4-F1qLfuLd3m_JhQSQ@mail.gmail.com>

Dear Sir,
I have few questions.

I use Numpy and Scipy for my work, but now if I have to consider writing a
paper, it would be an interesting aspect.

My questions are,

(i) If I can get any paper on Scipy implementation, it may help me to
write. I implement Python but never thought writing paper on
implementation. What I can think of any problem like eigenvalue etc how I
used Scipy. But that is two/three lines, how to write paper, bit confused?
Are you looking for describing eigenvalue how it calculates, how scipy
implements, the algorithm, pseudocode, my input with Scipy and results? But
won't that be a paper on eigenvalue? Please let me know.

(ii) I stay in Delhi. If I reach to IIT Bombay how would you arrange the
accomodation?

Regards,
Subhabrata Banerjee.


On Tue, Oct 15, 2013 at 10:22 PM, Prabhu Ramachandran <
prabhu at aero.iitb.ac.in> wrote:

> 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
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>



-- 
*Sree Subhabrata Banerjee*
*PDF(2007-2010)[IISc, Bangalore]*
Call:09873237945
Member, IEEE(USA), ACM(USA).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131016/a19a0ead/attachment.html>

From Vittorio.Braga at roma2.infn.it  Wed Oct 16 05:19:20 2013
From: Vittorio.Braga at roma2.infn.it (braga)
Date: Wed, 16 Oct 2013 11:19:20 +0200
Subject: [SciPy-User] [Astropy] Can't write a table in a format other than
	plain ascii
Message-ID: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>

Dear all

I am not only new to Astropy but I'm totally new to python itself

I need to read a csv table and rewrite it as an ipac table. I do this 
with astropy 0.24 ...

zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ python -V
Python 2.7.2
zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ sudo python
[sudo] password for zaamus:
Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from astropy.io import ascii
>>> rdr=ascii.get_reader(Reader=ascii.Basic)
>>> rdr.header.splitter.delimiter=','
>>> rdr.data.splitter.delimiter=','
>>> t1=ascii.read('match_2MASS+nomi')
>>> t2=ascii.read('RRLyr_PLZK.dat')

all is nice until here and I also manage to write to file in a plain 
ascii format

>>> ascii.write(t2,'RRLyr_PLZK.dat_2')

Fine. But if I do...

>>> ascii.write(t2,'RRLyr_PLZK.dat_2',format='ipac')
ERROR: TypeError: __init__() got an unexpected keyword argument 
'format' [astropy.io.ascii.core]
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py", 
line 277, in write
     writer = get_writer(Writer=Writer, **kwargs)
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py", 
line 244, in get_writer
     writer = core._get_writer(Writer, **kwargs)
   File 
"/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/core.py", line 
1015, in _get_writer
     writer = Writer(**writer_kwargs)
TypeError: __init__() got an unexpected keyword argument 'format'

Same thing with format='latex'
Also trying to write to sys.stdout (after importing sys) works only 
with no format specification

I've also tried to

>>> from astropy.io.ascii import ipac
>>> ipac.write(t2,'RRLyr_PLZK.dat_2')
ERROR: AttributeError: 'module' object has no attribute 'write' 
[unknown]
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'write'

>>> from astropy.table import Table
>>> t3=Table.read('match_2MASS+nomi',format='ascii')
>>> Table.write(t3,'match_2MASS+nomi_2',format='ascii')

fine, again it works...
then I try

>>> Table.write(t3,'match_2MASS+nomi_2',format='ascii.ipac')
ERROR: Exception: No writer defined for format 'ascii.ipac' and class 
'Table' [astropy.io.registry]
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py", 
line 200, in write
     writer = get_writer(format, data.__class__)
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py", 
line 138, in get_writer
     '{1!r}'.format(data_format, data_class.__name__))
Exception: No writer defined for format 'ascii.ipac' and class 'Table'
>>> Table.write(t3,'match_2MASS+nomi_2',format='ipac')
ERROR: Exception: No writer defined for format 'ipac' and class 'Table' 
[astropy.io.registry]
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py", 
line 200, in write
     writer = get_writer(format, data.__class__)
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py", 
line 138, in get_writer
     '{1!r}'.format(data_format, data_class.__name__))
Exception: No writer defined for format 'ipac' and class 'Table'

Am I missing something? Am I not importing something?

Thank you, Vittorio

-- 
Vittorio Francesco Braga
PhD student in Tor Vergata University of Rome
Mobile: +393203753307, Office (PhD room): +390672594868


From davidmenhur at gmail.com  Wed Oct 16 05:30:01 2013
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Wed, 16 Oct 2013 11:30:01 +0200
Subject: [SciPy-User] [Astropy] Can't write a table in a format other
 than plain ascii
In-Reply-To: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
References: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
Message-ID: <CAJhcF=3LzNTRXsYD=7TSzwL=YA3POZZNLAFP7jkg7Dz=MMRHsw@mail.gmail.com>

Hi

Welcome to Python. The Astropy experts can be found in their mailing list:

http://mail.scipy.org/mailman/listinfo/astropy

You will find better answers there.

In any case, if you haven't done it already, take a look at:

http://docs.astropy.org/en/latest/io/ascii/write.html
http://docs.astropy.org/en/latest/io/ascii/index.html#supported-formats


/David.




On 16 October 2013 11:19, braga <Vittorio.Braga at roma2.infn.it> wrote:

> Dear all
>
> I am not only new to Astropy but I'm totally new to python itself
>
> I need to read a csv table and rewrite it as an ipac table. I do this
> with astropy 0.24 ...
>
> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ python -V
> Python 2.7.2
> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ sudo python
> [sudo] password for zaamus:
> Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
> [GCC 4.6.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from astropy.io import ascii
> >>> rdr=ascii.get_reader(Reader=ascii.Basic)
> >>> rdr.header.splitter.delimiter=','
> >>> rdr.data.splitter.delimiter=','
> >>> t1=ascii.read('match_2MASS+nomi')
> >>> t2=ascii.read('RRLyr_PLZK.dat')
>
> all is nice until here and I also manage to write to file in a plain
> ascii format
>
> >>> ascii.write(t2,'RRLyr_PLZK.dat_2')
>
> Fine. But if I do...
>
> >>> ascii.write(t2,'RRLyr_PLZK.dat_2',format='ipac')
> ERROR: TypeError: __init__() got an unexpected keyword argument
> 'format' [astropy.io.ascii.core]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
> line 277, in write
>      writer = get_writer(Writer=Writer, **kwargs)
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
> line 244, in get_writer
>      writer = core._get_writer(Writer, **kwargs)
>    File
> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/core.py", line
> 1015, in _get_writer
>      writer = Writer(**writer_kwargs)
> TypeError: __init__() got an unexpected keyword argument 'format'
>
> Same thing with format='latex'
> Also trying to write to sys.stdout (after importing sys) works only
> with no format specification
>
> I've also tried to
>
> >>> from astropy.io.ascii import ipac
> >>> ipac.write(t2,'RRLyr_PLZK.dat_2')
> ERROR: AttributeError: 'module' object has no attribute 'write'
> [unknown]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'write'
>
> >>> from astropy.table import Table
> >>> t3=Table.read('match_2MASS+nomi',format='ascii')
> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii')
>
> fine, again it works...
> then I try
>
> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii.ipac')
> ERROR: Exception: No writer defined for format 'ascii.ipac' and class
> 'Table' [astropy.io.registry]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 200, in write
>      writer = get_writer(format, data.__class__)
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 138, in get_writer
>      '{1!r}'.format(data_format, data_class.__name__))
> Exception: No writer defined for format 'ascii.ipac' and class 'Table'
> >>> Table.write(t3,'match_2MASS+nomi_2',format='ipac')
> ERROR: Exception: No writer defined for format 'ipac' and class 'Table'
> [astropy.io.registry]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 200, in write
>      writer = get_writer(format, data.__class__)
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 138, in get_writer
>      '{1!r}'.format(data_format, data_class.__name__))
> Exception: No writer defined for format 'ipac' and class 'Table'
>
> Am I missing something? Am I not importing something?
>
> Thank you, Vittorio
>
> --
> Vittorio Francesco Braga
> PhD student in Tor Vergata University of Rome
> Mobile: +393203753307, Office (PhD room): +390672594868
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131016/212f8a64/attachment.html>

From Vittorio.Braga at roma2.infn.it  Wed Oct 16 05:33:42 2013
From: Vittorio.Braga at roma2.infn.it (braga)
Date: Wed, 16 Oct 2013 11:33:42 +0200
Subject: [SciPy-User] [Astropy] Can't write a table in a format other
 than plain ascii
In-Reply-To: <CAJhcF=3LzNTRXsYD=7TSzwL=YA3POZZNLAFP7jkg7Dz=MMRHsw@mail.gmail.com>
References: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
	<CAJhcF=3LzNTRXsYD=7TSzwL=YA3POZZNLAFP7jkg7Dz=MMRHsw@mail.gmail.com>
Message-ID: <f6d5f427e9b138fe58f54544c72ea14c@imap.roma2.infn.it>

Thanks, Dapid, sorry for writing in the wrong mailing list

> Hi
>
> Welcome to Python. The Astropy experts can be found in their mailing 
> list:
>
> http://mail.scipy.org/mailman/listinfo/astropy [5]
>
> You will find better answers there.
>
> In any case, if you haven't done it already, take a look at:
>
> http://docs.astropy.org/en/latest/io/ascii/write.html [6]
>  
> http://docs.astropy.org/en/latest/io/ascii/index.html#supported-formats 
> [7]
>
> /David.
>
> On 16 October 2013 11:19, braga <Vittorio.Braga at roma2.infn.it> wrote:
>
>> Dear all
>>
>> I am not only new to Astropy but I'm totally new to python itself
>>
>> I need to read a csv table and rewrite it as an ipac table. I do 
>> this
>> with astropy 0.24 ...
>>
>> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ python -V
>> Python 2.7.2
>> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ sudo python
>> [sudo] password for zaamus:
>> Python 2.7.2+ (default, Oct ?4 2011, 20:03:08)
>> [GCC 4.6.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more 
>> information.
>> >>> from astropy.io [1] import ascii
>> >>> rdr=ascii.get_reader(Reader=ascii.Basic)
>> >>> rdr.header.splitter.delimiter=','
>> >>> rdr.data.splitter.delimiter=','
>> >>> t1=ascii.read('match_2MASS+nomi')
>> >>> t2=ascii.read('RRLyr_PLZK.dat')
>>
>> all is nice until here and I also manage to write to file in a plain
>> ascii format
>>
>> >>> ascii.write(t2,'RRLyr_PLZK.dat_2')
>>
>> Fine. But if I do...
>>
>> >>> ascii.write(t2,'RRLyr_PLZK.dat_2',format='ipac')
>> ERROR: TypeError: __init__() got an unexpected keyword argument
>> 'format' [astropy.io.ascii.core]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
>> line 277, in write
>> ? ? ?writer = get_writer(Writer=Writer, **kwargs)
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
>> line 244, in get_writer
>> ? ? ?writer = core._get_writer(Writer, **kwargs)
>> ? ?File
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/core.py", 
>> line
>> 1015, in _get_writer
>> ? ? ?writer = Writer(**writer_kwargs)
>> TypeError: __init__() got an unexpected keyword argument 'format'
>>
>> Same thing with format='latex'
>> Also trying to write to sys.stdout (after importing sys) works only
>> with no format specification
>>
>> I've also tried to
>>
>> >>> from astropy.io.ascii import ipac
>> >>> ipac.write(t2,'RRLyr_PLZK.dat_2')
>> ERROR: AttributeError: 'module' object has no attribute 'write'
>> [unknown]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> AttributeError: 'module' object has no attribute 'write'
>>
>> >>> from astropy.table import Table
>> >>> t3=Table.read('match_2MASS+nomi',format='ascii')
>> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii')
>>
>> fine, again it works...
>> then I try
>>
>> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii.ipac')
>> ERROR: Exception: No writer defined for format 'ascii.ipac' and 
>> class
>> 'Table' [astropy.io.registry]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 200, in write
>> ? ? ?writer = get_writer(format, data.__class__)
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 138, in get_writer
>> ? ? ?'{1!r}'.format(data_format, data_class.__name__))
>> Exception: No writer defined for format 'ascii.ipac' and class 
>> 'Table'
>> >>> Table.write(t3,'match_2MASS+nomi_2',format='ipac')
>> ERROR: Exception: No writer defined for format 'ipac' and class 
>> 'Table'
>> [astropy.io.registry]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 200, in write
>> ? ? ?writer = get_writer(format, data.__class__)
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 138, in get_writer
>> ? ? ?'{1!r}'.format(data_format, data_class.__name__))
>> Exception: No writer defined for format 'ipac' and class 'Table'
>>
>> Am I missing something? Am I not importing something?
>>
>> Thank you, Vittorio
>>
>> --
>> Vittorio Francesco Braga
>> PhD student in Tor Vergata University of Rome
>> Mobile: +393203753307 [2], Office (PhD room): +390672594868 [3]
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user [4]
>
>
>
> Links:
> ------
> [1] http://astropy.io
> [2] tel:%2B393203753307
> [3] tel:%2B390672594868
> [4] http://mail.scipy.org/mailman/listinfo/scipy-user
> [5] http://mail.scipy.org/mailman/listinfo/astropy
> [6] http://docs.astropy.org/en/latest/io/ascii/write.html
> [7] 
> http://docs.astropy.org/en/latest/io/ascii/index.html#supported-formats
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user

-- 
Vittorio Francesco Braga
PhD student in Tor Vergata University of Rome
Mobile: +393203753307, Office (PhD room): +390672594868


From deshpande.jaidev at gmail.com  Wed Oct 16 05:49:56 2013
From: deshpande.jaidev at gmail.com (Jaidev Deshpande)
Date: Wed, 16 Oct 2013 15:19:56 +0530
Subject: [SciPy-User] [ANN] CFP: SciPy India 2013: Dec 13 - 15,
	IIT Bombay
In-Reply-To: <CADBiVjF2cW8v1E8aHixa=ooFpcQa9HfC4-F1qLfuLd3m_JhQSQ@mail.gmail.com>
References: <CADBiVjF2cW8v1E8aHixa=ooFpcQa9HfC4-F1qLfuLd3m_JhQSQ@mail.gmail.com>
Message-ID: <CAB=suEnWg5qQApD+nPc7kXZ5Dn44r9bOzXgr1xmMx6dFBzG_vQ@mail.gmail.com>

Dear Subrata,

On Wed, Oct 16, 2013 at 7:58 AM, Subhabrata Banerjee
<subhabangalore at gmail.com> wrote:
> Dear Sir,
> I have few questions.
>
> I use Numpy and Scipy for my work, but now if I have to consider writing a
> paper, it would be an interesting aspect.
>
> My questions are,
>
> (i) If I can get any paper on Scipy implementation, it may help me to write.
> I implement Python but never thought writing paper on implementation. What I
> can think of any problem like eigenvalue etc how I used Scipy. But that is
> two/three lines, how to write paper, bit confused? Are you looking for
> describing eigenvalue how it calculates, how scipy implements, the
> algorithm, pseudocode, my input with Scipy and results? But won't that be a
> paper on eigenvalue? Please let me know.

Personally, I think a talk is a good fit at SciPy if it deals with a
scientific problem you had, and if the scipy stack helped you solve
that problem, and if people can learn from it. Other than that, I'm
sorry, but how to write a paper is entirely at your discretion. I
suggest that you take a look at previous SciPy (India, Europe and US)
conferences and the presentations made there.

>
> (ii) I stay in Delhi. If I reach to IIT Bombay how would you arrange the
> accomodation?

Please send a mail to Hardik Ghaghada at hardik at fossee.in for more details.


>
> Regards,
> Subhabrata Banerjee.
>
>
> On Tue, Oct 15, 2013 at 10:22 PM, Prabhu Ramachandran
> <prabhu at aero.iitb.ac.in> wrote:
>>
>> 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
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>
>
>
> --
> Sree Subhabrata Banerjee
> PDF(2007-2010)[IISc, Bangalore]
> Call:09873237945
> Member, IEEE(USA), ACM(USA).
>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>



-- 
JD


From aldcroft at head.cfa.harvard.edu  Wed Oct 16 07:42:31 2013
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Wed, 16 Oct 2013 07:42:31 -0400
Subject: [SciPy-User] [Astropy] Can't write a table in a format other
 than plain ascii
In-Reply-To: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
References: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
Message-ID: <CAMtEP6zmrvi0g6q+kQxcJMfbuJ+C0bzxnqjq+e3i-NC87JVqkg@mail.gmail.com>

On Wed, Oct 16, 2013 at 5:19 AM, braga <Vittorio.Braga at roma2.infn.it> wrote:

> Dear all
>
> I am not only new to Astropy but I'm totally new to python itself
>
> I need to read a csv table and rewrite it as an ipac table. I do this
> with astropy 0.24 ...
>
> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ python -V
> Python 2.7.2
> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ sudo python
> [sudo] password for zaamus:
> Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
> [GCC 4.6.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from astropy.io import ascii
> >>> rdr=ascii.get_reader(Reader=ascii.Basic)
> >>> rdr.header.splitter.delimiter=','
> >>> rdr.data.splitter.delimiter=','
> >>> t1=ascii.read('match_2MASS+nomi')
> >>> t2=ascii.read('RRLyr_PLZK.dat')
>
> all is nice until here and I also manage to write to file in a plain
> ascii format
>
> >>> ascii.write(t2,'RRLyr_PLZK.dat_2')
>
> Fine. But if I do...
>
> >>> ascii.write(t2,'RRLyr_PLZK.dat_2',format='ipac')
> ERROR: TypeError: __init__() got an unexpected keyword argument
> 'format' [astropy.io.ascii.core]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
> line 277, in write
>      writer = get_writer(Writer=Writer, **kwargs)
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
> line 244, in get_writer
>      writer = core._get_writer(Writer, **kwargs)
>    File
> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/core.py", line
> 1015, in _get_writer
>      writer = Writer(**writer_kwargs)
> TypeError: __init__() got an unexpected keyword argument 'format'
>
> Same thing with format='latex'
> Also trying to write to sys.stdout (after importing sys) works only
> with no format specification
>
> I've also tried to
>
> >>> from astropy.io.ascii import ipac
> >>> ipac.write(t2,'RRLyr_PLZK.dat_2')
> ERROR: AttributeError: 'module' object has no attribute 'write'
> [unknown]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'write'
>
> >>> from astropy.table import Table
> >>> t3=Table.read('match_2MASS+nomi',format='ascii')
> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii')
>
> fine, again it works...
> then I try
>
> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii.ipac')
> ERROR: Exception: No writer defined for format 'ascii.ipac' and class
> 'Table' [astropy.io.registry]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 200, in write
>      writer = get_writer(format, data.__class__)
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 138, in get_writer
>      '{1!r}'.format(data_format, data_class.__name__))
> Exception: No writer defined for format 'ascii.ipac' and class 'Table'
> >>> Table.write(t3,'match_2MASS+nomi_2',format='ipac')
> ERROR: Exception: No writer defined for format 'ipac' and class 'Table'
> [astropy.io.registry]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 200, in write
>      writer = get_writer(format, data.__class__)
>    File "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
> line 138, in get_writer
>      '{1!r}'.format(data_format, data_class.__name__))
> Exception: No writer defined for format 'ipac' and class 'Table'
>
> Am I missing something? Am I not importing something?
>

Hi Vittorio,

I see you haven't posted to astropy so I'll answer here.  It appears you
are looking at the latest developer docs but running the stable release
0.2.4.  If you hover over the icon on the lower-right of the docs page you
can get to the 0.2.4 docs:

http://astropy.readthedocs.org/en/v0.2.4/index.html

Unfortunately the "format=" functionality you are trying to use is only in
the development version.  Astropy is planning for a 0.3 release in the next
month or two which includes this stuff.  In the meantime you can use the
older interface where you provide a class to specify the writer format:

 from astropy.io import ascii
 table = <your table>
 ascii.write(table, 'ipac.dat', Writer=ascii.Ipac)

Cheers,
Tom




>
> Thank you, Vittorio
>
> --
> Vittorio Francesco Braga
> PhD student in Tor Vergata University of Rome
> Mobile: +393203753307, Office (PhD room): +390672594868
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131016/0991a9a8/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-User] [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 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-User] [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 subhabangalore at gmail.com  Wed Oct 16 14:34:02 2013
From: subhabangalore at gmail.com (Subhabrata Banerjee)
Date: Thu, 17 Oct 2013 00:04:02 +0530
Subject: [SciPy-User] [ANN] CFP: SciPy India 2013: Dec 13 - 15,
	IIT Bombay
In-Reply-To: <CAB=suEnWg5qQApD+nPc7kXZ5Dn44r9bOzXgr1xmMx6dFBzG_vQ@mail.gmail.com>
References: <CADBiVjF2cW8v1E8aHixa=ooFpcQa9HfC4-F1qLfuLd3m_JhQSQ@mail.gmail.com>
	<CAB=suEnWg5qQApD+nPc7kXZ5Dn44r9bOzXgr1xmMx6dFBzG_vQ@mail.gmail.com>
Message-ID: <CADBiVjFk75DLo6Q=YjhkCjiPsJOEjGV2v+Rdq35w2mf+wZ7aQw@mail.gmail.com>

Dear Jaidev,

Thank you for your kind reply.
I am trying to see older papers and presentations for a good overview.
Based on this I would decide whether to give a talk or submit a paper.
I am also contacting Mr. Hardik Ghaghada in his given e-mail id for
accomodation etc.

Regards,
Subhabrata.


On Wed, Oct 16, 2013 at 3:19 PM, Jaidev Deshpande <
deshpande.jaidev at gmail.com> wrote:

> Dear Subrata,
>
> On Wed, Oct 16, 2013 at 7:58 AM, Subhabrata Banerjee
> <subhabangalore at gmail.com> wrote:
> > Dear Sir,
> > I have few questions.
> >
> > I use Numpy and Scipy for my work, but now if I have to consider writing
> a
> > paper, it would be an interesting aspect.
> >
> > My questions are,
> >
> > (i) If I can get any paper on Scipy implementation, it may help me to
> write.
> > I implement Python but never thought writing paper on implementation.
> What I
> > can think of any problem like eigenvalue etc how I used Scipy. But that
> is
> > two/three lines, how to write paper, bit confused? Are you looking for
> > describing eigenvalue how it calculates, how scipy implements, the
> > algorithm, pseudocode, my input with Scipy and results? But won't that
> be a
> > paper on eigenvalue? Please let me know.
>
> Personally, I think a talk is a good fit at SciPy if it deals with a
> scientific problem you had, and if the scipy stack helped you solve
> that problem, and if people can learn from it. Other than that, I'm
> sorry, but how to write a paper is entirely at your discretion. I
> suggest that you take a look at previous SciPy (India, Europe and US)
> conferences and the presentations made there.
>
> >
> > (ii) I stay in Delhi. If I reach to IIT Bombay how would you arrange the
> > accomodation?
>
> Please send a mail to Hardik Ghaghada at hardik at fossee.in for more
> details.
>
>
> >
> > Regards,
> > Subhabrata Banerjee.
> >
> >
> > On Tue, Oct 15, 2013 at 10:22 PM, Prabhu Ramachandran
> > <prabhu at aero.iitb.ac.in> wrote:
> >>
> >> 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
> >> _______________________________________________
> >> SciPy-User mailing list
> >> SciPy-User at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-user
> >
> >
> >
> >
> > --
> > Sree Subhabrata Banerjee
> > PDF(2007-2010)[IISc, Bangalore]
> > Call:09873237945
> > Member, IEEE(USA), ACM(USA).
> >
> >
> > _______________________________________________
> > SciPy-User mailing list
> > SciPy-User at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-user
> >
>
>
>
> --
> JD
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>



-- 
*Sree Subhabrata Banerjee*
*PDF(2007-2010)[IISc, Bangalore]*
Call:09873237945
Member, IEEE(USA), ACM(USA).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131017/bd844b35/attachment.html>

From Vittorio.Braga at roma2.infn.it  Thu Oct 17 06:57:56 2013
From: Vittorio.Braga at roma2.infn.it (braga)
Date: Thu, 17 Oct 2013 12:57:56 +0200
Subject: [SciPy-User] [Astropy] Can't write a table in a format other
 than plain ascii
In-Reply-To: <CAMtEP6zmrvi0g6q+kQxcJMfbuJ+C0bzxnqjq+e3i-NC87JVqkg@mail.gmail.com>
References: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
	<CAMtEP6zmrvi0g6q+kQxcJMfbuJ+C0bzxnqjq+e3i-NC87JVqkg@mail.gmail.com>
Message-ID: <b0b2a8403c71b9b9ddf6e58fa0328f21@imap.roma2.infn.it>

Dear Thomas

thank you for your reply. I was actually looking at 0.24 docs but I 
probably didn't understand. However your solution doesn't work, or I am 
missing something

>>> ascii.write(t1, 'ipac.dat', Writer=ascii.Ipac)
ERROR: NotImplementedError [astropy.io.ascii.ipac]
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py", 
line 278, in write
     lines = writer.write(table)
   File 
"/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ipac.py", line 
84, in write
     raise NotImplementedError
NotImplementedError



> On Wed, Oct 16, 2013 at 5:19 AM, braga <Vittorio.Braga at roma2.infn.it> 
> wrote:
>
>> Dear all
>>
>> I am not only new to Astropy but I'm totally new to python itself
>>
>> I need to read a csv table and rewrite it as an ipac table. I do 
>> this
>> with astropy 0.24 ...
>>
>> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ python -V
>> Python 2.7.2
>> zaamus at zaamuspc:~/Documenti/Dottorato/RRLyr/temp$ sudo python
>> [sudo] password for zaamus:
>> Python 2.7.2+ (default, Oct ?4 2011, 20:03:08)
>> [GCC 4.6.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more 
>> information.
>> >>> from astropy.io [1] import ascii
>> >>> rdr=ascii.get_reader(Reader=ascii.Basic)
>> >>> rdr.header.splitter.delimiter=','
>> >>> rdr.data.splitter.delimiter=','
>> >>> t1=ascii.read('match_2MASS+nomi')
>> >>> t2=ascii.read('RRLyr_PLZK.dat')
>>
>> all is nice until here and I also manage to write to file in a plain
>> ascii format
>>
>> >>> ascii.write(t2,'RRLyr_PLZK.dat_2')
>>
>> Fine. But if I do...
>>
>> >>> ascii.write(t2,'RRLyr_PLZK.dat_2',format='ipac')
>> ERROR: TypeError: __init__() got an unexpected keyword argument
>> 'format' [astropy.io.ascii.core]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
>> line 277, in write
>> ? ? ?writer = get_writer(Writer=Writer, **kwargs)
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/ui.py",
>> line 244, in get_writer
>> ? ? ?writer = core._get_writer(Writer, **kwargs)
>> ? ?File
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/ascii/core.py", 
>> line
>> 1015, in _get_writer
>> ? ? ?writer = Writer(**writer_kwargs)
>> TypeError: __init__() got an unexpected keyword argument 'format'
>>
>> Same thing with format='latex'
>> Also trying to write to sys.stdout (after importing sys) works only
>> with no format specification
>>
>> I've also tried to
>>
>> >>> from astropy.io.ascii import ipac
>> >>> ipac.write(t2,'RRLyr_PLZK.dat_2')
>> ERROR: AttributeError: 'module' object has no attribute 'write'
>> [unknown]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> AttributeError: 'module' object has no attribute 'write'
>>
>> >>> from astropy.table import Table
>> >>> t3=Table.read('match_2MASS+nomi',format='ascii')
>> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii')
>>
>> fine, again it works...
>> then I try
>>
>> >>> Table.write(t3,'match_2MASS+nomi_2',format='ascii.ipac')
>> ERROR: Exception: No writer defined for format 'ascii.ipac' and 
>> class
>> 'Table' [astropy.io.registry]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 200, in write
>> ? ? ?writer = get_writer(format, data.__class__)
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 138, in get_writer
>> ? ? ?'{1!r}'.format(data_format, data_class.__name__))
>> Exception: No writer defined for format 'ascii.ipac' and class 
>> 'Table'
>> >>> Table.write(t3,'match_2MASS+nomi_2',format='ipac')
>> ERROR: Exception: No writer defined for format 'ipac' and class 
>> 'Table'
>> [astropy.io.registry]
>> Traceback (most recent call last):
>> ? ?File "<stdin>", line 1, in <module>
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 200, in write
>> ? ? ?writer = get_writer(format, data.__class__)
>> ? ?File 
>> "/usr/local/lib/python2.7/dist-packages/astropy/io/registry.py",
>> line 138, in get_writer
>> ? ? ?'{1!r}'.format(data_format, data_class.__name__))
>> Exception: No writer defined for format 'ipac' and class 'Table'
>>
>> Am I missing something? Am I not importing something?
>
> Hi Vittorio,
>
> I see you haven't posted to astropy so I'll answer here. ?It appears
> you are looking at the latest developer docs but running the stable
> release 0.2.4. ?If you hover over the icon on the lower-right of the
> docs page you can get to the 0.2.4 docs:
>
> http://astropy.readthedocs.org/en/v0.2.4/index.html [5]
>
> Unfortunately the "format=" functionality you are trying to use is
> only in the development version. ?Astropy is planning for a 0.3
> release in the next month or two which includes this stuff. ?In the
> meantime you can use the older interface where you provide a class to
> specify the writer format:
>
> ?from astropy.io [1] import ascii
> ?table = <your table>
> ?ascii.write(table, 'ipac.dat', Writer=ascii.Ipac)
>
> Cheers,
> Tom
>
> ?
>
>> Thank you, Vittorio
>>
>> --
>> Vittorio Francesco Braga
>> PhD student in Tor Vergata University of Rome
>> Mobile: +393203753307 [2], Office (PhD room): +390672594868 [3]
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user [4]
>
>
>
> Links:
> ------
> [1] http://astropy.io
> [2] tel:%2B393203753307
> [3] tel:%2B390672594868
> [4] http://mail.scipy.org/mailman/listinfo/scipy-user
> [5] http://astropy.readthedocs.org/en/v0.2.4/index.html
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user

-- 
Vittorio Francesco Braga
PhD student in Tor Vergata University of Rome
Mobile: +393203753307, Office (PhD room): +390672594868


From aldcroft at head.cfa.harvard.edu  Thu Oct 17 07:57:09 2013
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Thu, 17 Oct 2013 07:57:09 -0400
Subject: [SciPy-User] [Astropy] Can't write a table in a format other
 than plain ascii
In-Reply-To: <b0b2a8403c71b9b9ddf6e58fa0328f21@imap.roma2.infn.it>
References: <5e50502c5ea6710601c6c27c71a63196@imap.roma2.infn.it>
	<CAMtEP6zmrvi0g6q+kQxcJMfbuJ+C0bzxnqjq+e3i-NC87JVqkg@mail.gmail.com>
	<b0b2a8403c71b9b9ddf6e58fa0328f21@imap.roma2.infn.it>
Message-ID: <CAMtEP6zO9ux7JVbeT5VaHjrOwJ+6P5zVT1E=LT=+guvo=p8xDA@mail.gmail.com>

On Thu, Oct 17, 2013 at 6:57 AM, braga <Vittorio.Braga at roma2.infn.it> wrote:

> Dear Thomas
>
> thank you for your reply. I was actually looking at 0.24 docs but I
> probably didn't understand. However your solution doesn't work, or I am
> missing something
>
>  ascii.write(t1, 'ipac.dat', Writer=ascii.Ipac)
>>>>
>>> ERROR: NotImplementedError [astropy.io.ascii.ipac]
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**ascii/ui.py",
> line 278, in write
>     lines = writer.write(table)
>   File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**ascii/ipac.py",
> line 84, in write
>     raise NotImplementedError
> NotImplementedError
>

Sorry about that, 0.2.4 does not support writing Ipac tables [1], this is
only available in the development version (which I was using inadvertently
in my example).

- Tom

[1]:
http://astropy.readthedocs.org/en/v0.2.4/_generated/astropy.io.ascii.ipac.Ipac.html#astropy.io.ascii.ipac.Ipac.write


>
>
>
>  On Wed, Oct 16, 2013 at 5:19 AM, braga <Vittorio.Braga at roma2.infn.it>
>> wrote:
>>
>>  Dear all
>>>
>>> I am not only new to Astropy but I'm totally new to python itself
>>>
>>> I need to read a csv table and rewrite it as an ipac table. I do this
>>> with astropy 0.24 ...
>>>
>>> zaamus at zaamuspc:~/Documenti/**Dottorato/RRLyr/temp$ python -V
>>> Python 2.7.2
>>> zaamus at zaamuspc:~/Documenti/**Dottorato/RRLyr/temp$ sudo python
>>> [sudo] password for zaamus:
>>> Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
>>> [GCC 4.6.1] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> from astropy.io [1] import ascii
>>>
>>> >>> rdr=ascii.get_reader(Reader=**ascii.Basic)
>>> >>> rdr.header.splitter.delimiter=**','
>>> >>> rdr.data.splitter.delimiter=',**'
>>> >>> t1=ascii.read('match_2MASS+**nomi')
>>> >>> t2=ascii.read('RRLyr_PLZK.dat'**)
>>>
>>> all is nice until here and I also manage to write to file in a plain
>>> ascii format
>>>
>>> >>> ascii.write(t2,'RRLyr_PLZK.**dat_2')
>>>
>>> Fine. But if I do...
>>>
>>> >>> ascii.write(t2,'RRLyr_PLZK.**dat_2',format='ipac')
>>> ERROR: TypeError: __init__() got an unexpected keyword argument
>>> 'format' [astropy.io.ascii.core]
>>> Traceback (most recent call last):
>>>    File "<stdin>", line 1, in <module>
>>>    File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**
>>> ascii/ui.py",
>>> line 277, in write
>>>      writer = get_writer(Writer=Writer, **kwargs)
>>>    File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**
>>> ascii/ui.py",
>>> line 244, in get_writer
>>>      writer = core._get_writer(Writer, **kwargs)
>>>    File
>>> "/usr/local/lib/python2.7/**dist-packages/astropy/io/**ascii/core.py",
>>> line
>>> 1015, in _get_writer
>>>      writer = Writer(**writer_kwargs)
>>> TypeError: __init__() got an unexpected keyword argument 'format'
>>>
>>> Same thing with format='latex'
>>> Also trying to write to sys.stdout (after importing sys) works only
>>> with no format specification
>>>
>>> I've also tried to
>>>
>>> >>> from astropy.io.ascii import ipac
>>> >>> ipac.write(t2,'RRLyr_PLZK.dat_**2')
>>> ERROR: AttributeError: 'module' object has no attribute 'write'
>>> [unknown]
>>> Traceback (most recent call last):
>>>    File "<stdin>", line 1, in <module>
>>> AttributeError: 'module' object has no attribute 'write'
>>>
>>> >>> from astropy.table import Table
>>> >>> t3=Table.read('match_2MASS+**nomi',format='ascii')
>>> >>> Table.write(t3,'match_2MASS+**nomi_2',format='ascii')
>>>
>>> fine, again it works...
>>> then I try
>>>
>>> >>> Table.write(t3,'match_2MASS+**nomi_2',format='ascii.ipac')
>>> ERROR: Exception: No writer defined for format 'ascii.ipac' and class
>>> 'Table' [astropy.io.registry]
>>> Traceback (most recent call last):
>>>    File "<stdin>", line 1, in <module>
>>>    File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**
>>> registry.py",
>>> line 200, in write
>>>      writer = get_writer(format, data.__class__)
>>>    File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**
>>> registry.py",
>>> line 138, in get_writer
>>>      '{1!r}'.format(data_format, data_class.__name__))
>>> Exception: No writer defined for format 'ascii.ipac' and class 'Table'
>>> >>> Table.write(t3,'match_2MASS+**nomi_2',format='ipac')
>>> ERROR: Exception: No writer defined for format 'ipac' and class 'Table'
>>> [astropy.io.registry]
>>> Traceback (most recent call last):
>>>    File "<stdin>", line 1, in <module>
>>>    File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**
>>> registry.py",
>>> line 200, in write
>>>      writer = get_writer(format, data.__class__)
>>>    File "/usr/local/lib/python2.7/**dist-packages/astropy/io/**
>>> registry.py",
>>> line 138, in get_writer
>>>      '{1!r}'.format(data_format, data_class.__name__))
>>> Exception: No writer defined for format 'ipac' and class 'Table'
>>>
>>> Am I missing something? Am I not importing something?
>>>
>>
>> Hi Vittorio,
>>
>> I see you haven't posted to astropy so I'll answer here.  It appears
>> you are looking at the latest developer docs but running the stable
>> release 0.2.4.  If you hover over the icon on the lower-right of the
>> docs page you can get to the 0.2.4 docs:
>>
>> http://astropy.readthedocs.**org/en/v0.2.4/index.html<http://astropy.readthedocs.org/en/v0.2.4/index.html>[5]
>>
>>
>> Unfortunately the "format=" functionality you are trying to use is
>> only in the development version.  Astropy is planning for a 0.3
>> release in the next month or two which includes this stuff.  In the
>> meantime you can use the older interface where you provide a class to
>> specify the writer format:
>>
>>  from astropy.io [1] import ascii
>>
>>  table = <your table>
>>  ascii.write(table, 'ipac.dat', Writer=ascii.Ipac)
>>
>> Cheers,
>> Tom
>>
>>
>>
>>  Thank you, Vittorio
>>>
>>> --
>>> Vittorio Francesco Braga
>>> PhD student in Tor Vergata University of Rome
>>> Mobile: +393203753307 [2], Office (PhD room): +390672594868 [3]
>>> ______________________________**_________________
>>> SciPy-User mailing list
>>> SciPy-User at scipy.org
>>> http://mail.scipy.org/mailman/**listinfo/scipy-user<http://mail.scipy.org/mailman/listinfo/scipy-user>[4]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] http://astropy.io
>> [2] tel:%2B393203753307
>> [3] tel:%2B390672594868
>> [4] http://mail.scipy.org/mailman/**listinfo/scipy-user<http://mail.scipy.org/mailman/listinfo/scipy-user>
>> [5] http://astropy.readthedocs.**org/en/v0.2.4/index.html<http://astropy.readthedocs.org/en/v0.2.4/index.html>
>>
>>
>> ______________________________**_________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/**listinfo/scipy-user<http://mail.scipy.org/mailman/listinfo/scipy-user>
>>
>
> --
> Vittorio Francesco Braga
> PhD student in Tor Vergata University of Rome
> Mobile: +393203753307, Office (PhD room): +390672594868
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131017/7519409c/attachment.html>

From anastasi.fr at gmail.com  Fri Oct 18 09:28:20 2013
From: anastasi.fr at gmail.com (Francesco)
Date: Fri, 18 Oct 2013 13:28:20 +0000 (UTC)
Subject: [SciPy-User] Matlab and Python Problem
Message-ID: <loom.20131018T152620-210@post.gmane.org>

Hello...
my name is Francesco,
i don't know to obtain python code from this matlab code:

molle.m   :

function u = molle(tspan,u0,A,l,k,m)
%N=3
N=size(A,1)

x=u0(1:3:3*N)
y=u0(2:3:3*N);
z=u0(3:3:3*N);
vx=u0(3*N+1:3:6*N);
vy=u0(3*N+2:3:6*N);
vz=u0(3*N+3:3:6*N);

for i = 1 : N
    Fx=0;
    Fy=0;
    Fz=0;
    for j = 1 : N
        if A(i,j) ~= 0
        d=((x(i)-x(j))^2+(y(i)-y(j))^2+(z(i)-z(j))^2)^0.5;
        Fx=Fx+k(i,j)*(abs(x(j)-x(i))-l(i,j))*(x(j)-x(i))*A(i,j)/d;
        Fy=Fy+k(i,j)*(abs(y(j)-y(i))-l(i,j))*(y(j)-y(i))*A(i,j)/d; 
        Fz=Fz+k(i,j)*(abs(z(j)-z(i))-l(i,j))*(z(j)-z(i))*A(i,j)/d;
        end
    end
    u(1+3*(i-1))=u0(3*N+1+3*(i-1)); % dx
    u(2+3*(i-1))=u0(3*N+2+3*(i-1)); % dy
    u(3+3*(i-1))=u0(3*N+3+3*(i-1)); % dz
    u(3*N+1+3*(i-1))=Fx/m(i) ;  % ax=F/m
    u(3*N+2+3*(i-1))=Fy/m(i) ;  % ay=F/m
    u(3*N+3+3*(i-1))=Fz/m(i) ;  % az=F/m
end
u=u';

test.m  :

% esempio di 3 molle
clc
close all
clear

x0=[-1 0 1];
y0=[0 1/2 0];
z0=[0 0 0];

Vx0=[0 0 0];
Vy0=[0 1 0];
Vz0=[0 0 0];

A=[0 1 0; 1 0 1; 0 1 0];

l = A ;

k = A ;

m = [1 1 1];

u0 = [x0';y0';z0';Vx0';Vy0';Vz0'];
tspan=[0 10];
[t,u] = ode45(@molle,tspan,u0,[],A,l,k,m)


x=u(:,1:3:3*size(A,1));
y=u(:,2:3:3*size(A,1));
z=u(:,3:3:3*size(A,1));
vx=u(:,3*size(A,1)+1:3:6*size(A,1));
vy=u(:,3*size(A,1)+2:3:6*size(A,1));
vz=u(:,3*size(A,1)+3:3:6*size(A,1));

maxX=max(max(x));
maxY=max(max(y));
maxZ=max(max(z));
minX=min(min(x));
minY=min(min(y));
minZ=min(min(z));


figure,
for k = 1 : length(t)
    [aa bb]=view;
    plot3(x(k,:),y(k,:),z(k,:),'*')
    view(aa,bb)
    axis([minX maxX minY maxY minZ maxZ])
    grid on
    pause(0.5)
end

could help me?



From msuzen at gmail.com  Fri Oct 18 10:04:13 2013
From: msuzen at gmail.com (Suzen, Mehmet)
Date: Fri, 18 Oct 2013 16:04:13 +0200
Subject: [SciPy-User] Matlab and Python Problem
In-Reply-To: <loom.20131018T152620-210@post.gmane.org>
References: <loom.20131018T152620-210@post.gmane.org>
Message-ID: <CAPtbhHwKq=YN2KNTS=-682iZ7YX+bL2gMjz6=qEhETwHsh8eLA@mail.gmail.com>

This documentation might help:
http://wiki.scipy.org/NumPy_for_Matlab_Users

On 18 October 2013 15:28, Francesco <anastasi.fr at gmail.com> wrote:
> Hello...
> my name is Francesco,
> i don't know to obtain python code from this matlab code:
>
> molle.m   :
>
> function u = molle(tspan,u0,A,l,k,m)
> %N=3
> N=size(A,1)
>
> x=u0(1:3:3*N)
> y=u0(2:3:3*N);
> z=u0(3:3:3*N);
> vx=u0(3*N+1:3:6*N);
> vy=u0(3*N+2:3:6*N);
> vz=u0(3*N+3:3:6*N);
>
> for i = 1 : N
>     Fx=0;
>     Fy=0;
>     Fz=0;
>     for j = 1 : N
>         if A(i,j) ~= 0
>         d=((x(i)-x(j))^2+(y(i)-y(j))^2+(z(i)-z(j))^2)^0.5;
>         Fx=Fx+k(i,j)*(abs(x(j)-x(i))-l(i,j))*(x(j)-x(i))*A(i,j)/d;
>         Fy=Fy+k(i,j)*(abs(y(j)-y(i))-l(i,j))*(y(j)-y(i))*A(i,j)/d;
>         Fz=Fz+k(i,j)*(abs(z(j)-z(i))-l(i,j))*(z(j)-z(i))*A(i,j)/d;
>         end
>     end
>     u(1+3*(i-1))=u0(3*N+1+3*(i-1)); % dx
>     u(2+3*(i-1))=u0(3*N+2+3*(i-1)); % dy
>     u(3+3*(i-1))=u0(3*N+3+3*(i-1)); % dz
>     u(3*N+1+3*(i-1))=Fx/m(i) ;  % ax=F/m
>     u(3*N+2+3*(i-1))=Fy/m(i) ;  % ay=F/m
>     u(3*N+3+3*(i-1))=Fz/m(i) ;  % az=F/m
> end
> u=u';
>
> test.m  :
>
> % esempio di 3 molle
> clc
> close all
> clear
>
> x0=[-1 0 1];
> y0=[0 1/2 0];
> z0=[0 0 0];
>
> Vx0=[0 0 0];
> Vy0=[0 1 0];
> Vz0=[0 0 0];
>
> A=[0 1 0; 1 0 1; 0 1 0];
>
> l = A ;
>
> k = A ;
>
> m = [1 1 1];
>
> u0 = [x0';y0';z0';Vx0';Vy0';Vz0'];
> tspan=[0 10];
> [t,u] = ode45(@molle,tspan,u0,[],A,l,k,m)
>
>
> x=u(:,1:3:3*size(A,1));
> y=u(:,2:3:3*size(A,1));
> z=u(:,3:3:3*size(A,1));
> vx=u(:,3*size(A,1)+1:3:6*size(A,1));
> vy=u(:,3*size(A,1)+2:3:6*size(A,1));
> vz=u(:,3*size(A,1)+3:3:6*size(A,1));
>
> maxX=max(max(x));
> maxY=max(max(y));
> maxZ=max(max(z));
> minX=min(min(x));
> minY=min(min(y));
> minZ=min(min(z));
>
>
> figure,
> for k = 1 : length(t)
>     [aa bb]=view;
>     plot3(x(k,:),y(k,:),z(k,:),'*')
>     view(aa,bb)
>     axis([minX maxX minY maxY minZ maxZ])
>     grid on
>     pause(0.5)
> end
>
> could help me?
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user


From josef.pktd at gmail.com  Fri Oct 18 22:16:28 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 18 Oct 2013 22:16:28 -0400
Subject: [SciPy-User] optimization with ill conditioned Hessian
Message-ID: <CAMMTP+AVZbKmuA60K0dMnWN0nWzKmX1Sg4U5bd1zxM2UwHM1aQ@mail.gmail.com>

Does scipy have another optimizer besides fmin (Nelder-Mead) that is
robust to near-singular, high condition number Hessian?

fmin_bfgs goes into neverland, values become huge until I get some
nans in my calculations.

What would be nice is an optimizer that uses derivatives, but
regularizes, forces Hessian or equivalent to be positive definite.


Background
I'm trying to replicate a textbook example that has data and matrix
inverses that are "not nice". fmin (Nelder-Mead) is getting pretty
close to the Stata numbers. However fmin_bfgs has been my preferred
default optimizer for some time.

Aside:
It looks like it's a good test case to make my linear algebra more robust.
np.linalg.pinv(x.T.dot(x)) doesn't seem to be robust enough for this case.
And no idea why a textbook would use an example like that.
And no idea if Stata doesn't just make up the numbers.

Thanks,

Josef


From charlesr.harris at gmail.com  Fri Oct 18 23:47:46 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 18 Oct 2013 21:47:46 -0600
Subject: [SciPy-User] optimization with ill conditioned Hessian
In-Reply-To: <CAMMTP+AVZbKmuA60K0dMnWN0nWzKmX1Sg4U5bd1zxM2UwHM1aQ@mail.gmail.com>
References: <CAMMTP+AVZbKmuA60K0dMnWN0nWzKmX1Sg4U5bd1zxM2UwHM1aQ@mail.gmail.com>
Message-ID: <CAB6mnxKaHoLks3aS+4Uq5=Wu3ntzWaz38E0QDoU96aREAXxJPQ@mail.gmail.com>

On Fri, Oct 18, 2013 at 8:16 PM, <josef.pktd at gmail.com> wrote:

> Does scipy have another optimizer besides fmin (Nelder-Mead) that is
> robust to near-singular, high condition number Hessian?
>
> fmin_bfgs goes into neverland, values become huge until I get some
> nans in my calculations.
>
> What would be nice is an optimizer that uses derivatives, but
> regularizes, forces Hessian or equivalent to be positive definite.
>
>
> Background
> I'm trying to replicate a textbook example that has data and matrix
> inverses that are "not nice". fmin (Nelder-Mead) is getting pretty
> close to the Stata numbers. However fmin_bfgs has been my preferred
> default optimizer for some time.
>
> Aside:
> It looks like it's a good test case to make my linear algebra more robust.
> np.linalg.pinv(x.T.dot(x)) doesn't seem to be robust enough for this case.
> And no idea why a textbook would use an example like that.
> And no idea if Stata doesn't just make up the numbers.
>

This would be better if you used the svd decomposition of x and did your
own pinv. Might also try scaling the columns of x.

Unscaled, that would be

u*d*v = svd(x)
pinv(x.T.dot(x)) = v.T * (1/d**2) * v

where elements of 1/d**2  are set to zero if the corresponding term of d is
below a cutoff. Scaling adds diagonal terms at both ends of that.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131018/9116a580/attachment.html>

From charlesr.harris at gmail.com  Sat Oct 19 01:04:31 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 18 Oct 2013 23:04:31 -0600
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAPJVwBkuHw-6bvw1dgJXYbAyzwb7daZgBc+r6cx+6JXWF+C=iA@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
	<CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
	<CAPJVwBkuHw-6bvw1dgJXYbAyzwb7daZgBc+r6cx+6JXWF+C=iA@mail.gmail.com>
Message-ID: <CAB6mnxL5PwRdzbvFsv2Cguv3Mgoc3_Fw4_D2GC8o9Y51FourVw@mail.gmail.com>

On Wed, Oct 2, 2013 at 1:58 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Oct 1, 2013 at 10:45 PM,  <josef.pktd at gmail.com> wrote:
> > On Tue, Oct 1, 2013 at 5:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
> >> Here are several ways to solve the least squares problem XB = Y:
> >>
> >> scipy.linalg.lstsq(x, y)
> >> np.linalg.lstsq(x, y)
> >> np.dot(scipy.linalg.pinv(x), y)
> >> np.dot(np.linalg.pinv(x), y)
> >>
> >> >From the documentation, I would expect these to be ordered by speed,
> >> fastest up top and slowest at the bottom. It turns out they *are*
> >> ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
> >> scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
> >> very substantial differences (more than a factor of 20!):
> >>
> >> # Typical smallish problem for me:
> >> In [40]: x = np.random.randn(780, 2)
> >>
> >> In [41]: y = np.random.randn(780, 32 * 275)
> >>
> >> In [42]: %timeit scipy.linalg.lstsq(x, y)
> >> 1 loops, best of 3: 494 ms per loop
> >>
> >> In [43]: %timeit np.linalg.lstsq(x, y)
> >> 1 loops, best of 3: 356 ms per loop
> >>
> >> In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
> >> 10 loops, best of 3: 62.2 ms per loop
> >>
> >> In [45]: %timeit np.dot(np.linalg.pinv(x), y)
> >> 10 loops, best of 3: 23.2 ms per loop
> >>
> >> Is this expected? I'm particularly confused at why scipy's lstsq
> >> should be almost 40% slower than numpy's. (And shouldn't we have a
> >> fast one-function way to solve least squares problems?)
> >>
> >> Any reason not to use the last option? Is it as numerically stable as
> lstsq?
> >>
> >> Is there any other version that's even faster or even more numerically
> stable?
> >
> > If you have very long x, then using normal equation is faster for
> univariate y.
> >
> > There are many different ways to calculate pinv
> > https://github.com/scipy/scipy/pull/289
> >
> > np.lstsq breaks on rank deficient x IIRC, uses different Lapack
> > functions than scipy's lstsq
> >
> > In very badly scaled cases (worst NIST case), scipy's pinv was a bit
> > more accurate than numpy's, but maybe just different defaults.
> > numpy's pinv was also faster than scipy's in the cases that I tried.
> >
> > There is only a single NIST case that can fail using the defaults with
> > numpy pinv.
> >
> > (what about using qr or chol_solve ?)
> >
> > Lots of different ways to solve this and I never figured out a ranking
> > across different cases, speed, precision, robustness to
> > near-singularity.
>
> Amazingly enough, in this case doing a full rank-revealing QR,
> including calculating the rank via condition number of submatrices, is
> tied for the fastest method:
>
> In [66]: %timeit q, r, p = scipy.linalg.qr(x, mode="economic",
> pivoting=True); [np.linalg.cond(r[:i, :i]) for i in xrange(1,
> r.shape[0])]; np.linalg.solve(r[:, p], np.dot(q.T, y))
> 10 loops, best of 3: 22 ms per loop
>
> Also tied for fastest with np.linalg.pinv (above) are the direct
> method, cho_solve, and a non-rank-revealing QR with lower-triangular
> backsolve:
>
> In [70]: %timeit np.linalg.solve(np.dot(x.T, x), np.dot(x.T, y))
> 10 loops, best of 3: 21.4 ms per loop
>
> In [71]: %timeit c = scipy.linalg.cho_factor(np.dot(x.T, x));
> scipy.linalg.cho_solve(c, np.dot(x.T, y))
> 10 loops, best of 3: 21.2 ms per loop
>
> In [72]: %timeit q, r = scipy.linalg.qr(x, mode="economic");
> scipy.linalg.solve_triangular(r, np.dot(q.T, y))
> 10 loops, best of 3: 22.4 ms per loop
>
> But AFAIK QR is the gold standard for precision on the kinds of linear
> regression problems I care about (and definitely has better numerical
> stability than the versions that involve dot(x.T, x)), and in my case
> I actually want to detect and reject ill-conditioned problems rather
> than impose some secondary disambiguating constraint, so... RRQR seems
> to be the obvious choice.
>
> Not sure if there's anything that could or should be done to make
> these trade-offs more obvious to people less obsessive than me...
>
>
Numpy's lstsqr computes the sum of the squared residuals, which probablly
adds significant time. It also applies Householder reflections to the rhs,
which keeps the full dimensions of the rhs with the transformed residuals
in the bottom, reduces the problem to a bidiagonal least squares problem,
and solves that. Supposedly the bidiagonal method is sometimes superior to
the truncated SVD (as used in pinv), but I'll bet it is more expensive.
Keeping the full rhs dimensions will also be slower than a matrix
multiplication that reduces the dimensions to match the solution
dimensions, i.e, 780 preserved vs 2 reduced. Omitting the sum of the
squared residuals does speed things up somewhat.

Current:

In [3]: %timeit np.linalg.lstsq(x, y)
1 loops, best of 3: 355 ms per loop

No sum of squared residuals:

In [3]: %timeit np.linalg.lstsq(x, y)
1 loops, best of 3: 268 ms per loop

Personally, I don't much care for the transformed residuals and always end
up computing the residuals at the actual data points when I need them.

I think the moral of the story is know your problem and choose an
appropriate method. For well conditioned problems where you aren't
concerned about the transformed residuals, QR is probably the best. The
np.linalg.lstsq method is probably a bit safer for naive least squares.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131018/e2471fa5/attachment.html>

From charlesr.harris at gmail.com  Sat Oct 19 01:18:11 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 18 Oct 2013 23:18:11 -0600
Subject: [SciPy-User] Least squares speed
In-Reply-To: <CAB6mnxL5PwRdzbvFsv2Cguv3Mgoc3_Fw4_D2GC8o9Y51FourVw@mail.gmail.com>
References: <CAPJVwBm_q+bTtkGiJwrR8QGUWqF8MTvHO94TpZtGiNaRGO4KaA@mail.gmail.com>
	<CAMMTP+Dv6z=Pi72PKDyJ5kiOotDJSUCq-CC7=m2NTUsYSWNnsw@mail.gmail.com>
	<CAPJVwBkuHw-6bvw1dgJXYbAyzwb7daZgBc+r6cx+6JXWF+C=iA@mail.gmail.com>
	<CAB6mnxL5PwRdzbvFsv2Cguv3Mgoc3_Fw4_D2GC8o9Y51FourVw@mail.gmail.com>
Message-ID: <CAB6mnxKdqpHnY8KFeuFGU5rSydRv3FUCA2uDh3m7prYrBa9wuA@mail.gmail.com>

On Fri, Oct 18, 2013 at 11:04 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
>
> On Wed, Oct 2, 2013 at 1:58 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Tue, Oct 1, 2013 at 10:45 PM,  <josef.pktd at gmail.com> wrote:
>> > On Tue, Oct 1, 2013 at 5:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> >> Here are several ways to solve the least squares problem XB = Y:
>> >>
>> >> scipy.linalg.lstsq(x, y)
>> >> np.linalg.lstsq(x, y)
>> >> np.dot(scipy.linalg.pinv(x), y)
>> >> np.dot(np.linalg.pinv(x), y)
>> >>
>> >> >From the documentation, I would expect these to be ordered by speed,
>> >> fastest up top and slowest at the bottom. It turns out they *are*
>> >> ordered by speed, except, on my system (linux x86-64, numpy 1.7.1,
>> >> scipy 0.12.0, ubuntu-installed atlas), it's exactly backwards, with
>> >> very substantial differences (more than a factor of 20!):
>> >>
>> >> # Typical smallish problem for me:
>> >> In [40]: x = np.random.randn(780, 2)
>> >>
>> >> In [41]: y = np.random.randn(780, 32 * 275)
>> >>
>> >> In [42]: %timeit scipy.linalg.lstsq(x, y)
>> >> 1 loops, best of 3: 494 ms per loop
>> >>
>> >> In [43]: %timeit np.linalg.lstsq(x, y)
>> >> 1 loops, best of 3: 356 ms per loop
>> >>
>> >> In [44]: %timeit np.dot(scipy.linalg.pinv(x), y)
>> >> 10 loops, best of 3: 62.2 ms per loop
>> >>
>> >> In [45]: %timeit np.dot(np.linalg.pinv(x), y)
>> >> 10 loops, best of 3: 23.2 ms per loop
>> >>
>> >> Is this expected? I'm particularly confused at why scipy's lstsq
>> >> should be almost 40% slower than numpy's. (And shouldn't we have a
>> >> fast one-function way to solve least squares problems?)
>> >>
>> >> Any reason not to use the last option? Is it as numerically stable as
>> lstsq?
>> >>
>> >> Is there any other version that's even faster or even more numerically
>> stable?
>> >
>> > If you have very long x, then using normal equation is faster for
>> univariate y.
>> >
>> > There are many different ways to calculate pinv
>> > https://github.com/scipy/scipy/pull/289
>> >
>> > np.lstsq breaks on rank deficient x IIRC, uses different Lapack
>> > functions than scipy's lstsq
>> >
>> > In very badly scaled cases (worst NIST case), scipy's pinv was a bit
>> > more accurate than numpy's, but maybe just different defaults.
>> > numpy's pinv was also faster than scipy's in the cases that I tried.
>> >
>> > There is only a single NIST case that can fail using the defaults with
>> > numpy pinv.
>> >
>> > (what about using qr or chol_solve ?)
>> >
>> > Lots of different ways to solve this and I never figured out a ranking
>> > across different cases, speed, precision, robustness to
>> > near-singularity.
>>
>> Amazingly enough, in this case doing a full rank-revealing QR,
>> including calculating the rank via condition number of submatrices, is
>> tied for the fastest method:
>>
>> In [66]: %timeit q, r, p = scipy.linalg.qr(x, mode="economic",
>> pivoting=True); [np.linalg.cond(r[:i, :i]) for i in xrange(1,
>> r.shape[0])]; np.linalg.solve(r[:, p], np.dot(q.T, y))
>> 10 loops, best of 3: 22 ms per loop
>>
>> Also tied for fastest with np.linalg.pinv (above) are the direct
>> method, cho_solve, and a non-rank-revealing QR with lower-triangular
>> backsolve:
>>
>> In [70]: %timeit np.linalg.solve(np.dot(x.T, x), np.dot(x.T, y))
>> 10 loops, best of 3: 21.4 ms per loop
>>
>> In [71]: %timeit c = scipy.linalg.cho_factor(np.dot(x.T, x));
>> scipy.linalg.cho_solve(c, np.dot(x.T, y))
>> 10 loops, best of 3: 21.2 ms per loop
>>
>> In [72]: %timeit q, r = scipy.linalg.qr(x, mode="economic");
>> scipy.linalg.solve_triangular(r, np.dot(q.T, y))
>> 10 loops, best of 3: 22.4 ms per loop
>>
>> But AFAIK QR is the gold standard for precision on the kinds of linear
>> regression problems I care about (and definitely has better numerical
>> stability than the versions that involve dot(x.T, x)), and in my case
>> I actually want to detect and reject ill-conditioned problems rather
>> than impose some secondary disambiguating constraint, so... RRQR seems
>> to be the obvious choice.
>>
>> Not sure if there's anything that could or should be done to make
>> these trade-offs more obvious to people less obsessive than me...
>>
>>
> Numpy's lstsqr computes the sum of the squared residuals, which probablly
> adds significant time. It also applies Householder reflections to the rhs,
> which keeps the full dimensions of the rhs with the transformed residuals
> in the bottom, reduces the problem to a bidiagonal least squares problem,
> and solves that. Supposedly the bidiagonal method is sometimes superior to
> the truncated SVD (as used in pinv), but I'll bet it is more expensive.
> Keeping the full rhs dimensions will also be slower than a matrix
> multiplication that reduces the dimensions to match the solution
> dimensions, i.e, 780 preserved vs 2 reduced. Omitting the sum of the
> squared residuals does speed things up somewhat.
>
> Current:
>
> In [3]: %timeit np.linalg.lstsq(x, y)
> 1 loops, best of 3: 355 ms per loop
>
> No sum of squared residuals:
>
> In [3]: %timeit np.linalg.lstsq(x, y)
> 1 loops, best of 3: 268 ms per loop
>
> Personally, I don't much care for the transformed residuals and always end
> up computing the residuals at the actual data points when I need them.
>
> I think the moral of the story is know your problem and choose an
> appropriate method. For well conditioned problems where you aren't
> concerned about the transformed residuals, QR is probably the best. The
> np.linalg.lstsq method is probably a bit safer for naive least squares.
>
>
And if you don't care about the residuals but want the bidiagonal method,
qr is safe for dimension reduction.

In [2]: def mylstsq(x, y):
    q, r = np.linalg.qr(x, 'reduced')
    y = np.dot(q.T, y)
    return np.linalg.lstsq(r, y)
   ...:

In [3]: x = np.random.randn(780, 2)

In [4]: y = np.random.randn(780, 32 * 275)

In [5]: %timeit mylstsq(x, y)
100 loops, best of 3: 15.8 ms per loop

The 'reduced' keyword is new in 1.8.0

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131018/daa5fb9e/attachment.html>

From vaggi.federico at gmail.com  Sat Oct 19 17:09:16 2013
From: vaggi.federico at gmail.com (federico vaggi)
Date: Sat, 19 Oct 2013 23:09:16 +0200
Subject: [SciPy-User] optimization with ill conditioned Hessian
	(josef.pktd@gmail.com)
Message-ID: <CAGvd0=iOxQmt1PDhO3RytuBkY2v+EgyAXD0-JyOf+X026d2LbQ@mail.gmail.com>

Hey Josef,

If the problem you are dealing with is some kind of least square problem,
you might find this paper helpful:

http://arxiv.org/abs/1201.5885

Federico


> Message: 1
> Date: Fri, 18 Oct 2013 22:16:28 -0400
> From: josef.pktd at gmail.com
> Subject: [SciPy-User] optimization with ill conditioned Hessian
> To: SciPy Users List <scipy-user at scipy.org>
> Message-ID:
>         <
> CAMMTP+AVZbKmuA60K0dMnWN0nWzKmX1Sg4U5bd1zxM2UwHM1aQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Does scipy have another optimizer besides fmin (Nelder-Mead) that is
> robust to near-singular, high condition number Hessian?
>
> fmin_bfgs goes into neverland, values become huge until I get some
> nans in my calculations.
>
> What would be nice is an optimizer that uses derivatives, but
> regularizes, forces Hessian or equivalent to be positive definite.
>
>
> Background
> I'm trying to replicate a textbook example that has data and matrix
> inverses that are "not nice". fmin (Nelder-Mead) is getting pretty
> close to the Stata numbers. However fmin_bfgs has been my preferred
> default optimizer for some time.
>
> Aside:
> It looks like it's a good test case to make my linear algebra more robust.
> np.linalg.pinv(x.T.dot(x)) doesn't seem to be robust enough for this case.
> And no idea why a textbook would use an example like that.
> And no idea if Stata doesn't just make up the numbers.
>
> Thanks,
>
> Josef
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131019/2d479382/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-User] 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.scipy.org/pipermail/scipy-user/attachments/20131019/e215d455/attachment.html>

From robfalck at gmail.com  Sun Oct 20 21:59:36 2013
From: robfalck at gmail.com (Rob Falck)
Date: Sun, 20 Oct 2013 21:59:36 -0400
Subject: [SciPy-User] Linear Programming via Simplex Algorithm
Message-ID: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>

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.

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).

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.

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)

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.

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)

Thanks,

Rob Falck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131020/67e5c9ca/attachment.html>

From jsch at demuc.de  Mon Oct 21 03:31:34 2013
From: jsch at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=)
Date: Mon, 21 Oct 2013 09:31:34 +0200
Subject: [SciPy-User] ANN: scikit-image 0.9 release
Message-ID: <646BF94A-F53B-46CD-A2E8-E417D51D9F58@demuc.de>

We're happy to announce the release of scikit-image v0.9.0!

scikit-image is an image processing toolbox for SciPy that includes algorithms
for segmentation, geometric transformations, color space manipulation,
analysis, filtering, morphology, feature detection, and more.

For more information, examples, and documentation, please visit our website:

    
http://scikit-image.org



New Features
------------

`scikit-image` now runs without translation under both Python 2 and 3.

In addition to several bug fixes, speed improvements and examples, the 204 pull
requests merged for this release include the following new features (PR number
in brackets):

Segmentation:

- 3D support in SLIC segmentation (#546)
- SLIC voxel spacing (#719)
- Generalized anisotropic spacing support for random_walker (#775)
- Yen threshold method (#686)

Transforms and filters:

- SART algorithm for tomography reconstruction (#584)
- Gabor filters (#371)
- Hough transform for ellipses (#597)
- Fast resampling of nD arrays (#511)
- Rotation axis center for Radon transforms with inverses. (#654)
- Reconstruction circle in inverse Radon transform (#567)
- Pixelwise image adjustment curves and methods (#505)

Feature detection:

- [experimental API] BRIEF feature descriptor (#591)
- [experimental API] Censure (STAR) Feature Detector (#668)
- Octagon structural element (#669)
- Add non rotation invariant uniform LBPs (#704)

Color and noise:

- Add deltaE color comparison and lab2lch conversion (#665)
- Isotropic denoising (#653)
- Generator to add various types of random noise to images (#625)
- Color deconvolution for immunohistochemical images (#441)
- Color label visualization (#485)

Drawing and visualization:

- Wu's anti-aliased circle, line, bezier curve (#709)
- Linked image viewers and docked plugins (#575)
- Rotated ellipse + bezier curve drawing (#510)
- PySide & PyQt4 compatibility in skimage-viewer (#551)

Other:

- Python 3 support without 2to3. (#620)
- 3D Marching Cubes (#469)
- Line, Circle, Ellipse total least squares fitting and RANSAC algorithm (#440)
- N-dimensional array padding (#577)
- Add a wrapper around `scipy.ndimage.gaussian_filter` with useful
default behaviors. (#712)
- Predefined structuring elements for 3D morphology (#484)


API changes
-----------

The following backward-incompatible API changes were made between 0.8 and 0.9:

- No longer wrap ``imread`` output in an ``Image`` class
- Change default value of `sigma` parameter in ``skimage.segmentation.slic``
  to 0
- ``hough_circle`` now returns a stack of arrays that are the same size as the
  input image. Set the ``full_output`` flag to True for the old behavior.
- The following functions were deprecated over two releases:
  `skimage.filter.denoise_tv_chambolle`,
  `skimage.morphology.is_local_maximum`, `skimage.transform.hough`,
  `skimage.transform.probabilistic_hough`,`skimage.transform.hough_peaks`.
  Their functionality still exists, but under different names.


Contributors to this release
----------------------------

This release was made possible by the collaborative efforts of many
contributors, both new and old.  They are listed in alphabetical order by
surname:

- Ankit Agrawal
- K.-Michael Aye
- Chris Beaumont
- Fran?ois Boulogne
- Luis Pedro Coelho
- Marianne Corvellec
- Olivier Debeir
- Ferdinand Deger
- Kemal Eren
- Jostein B? Fl?ystad
- Christoph Gohlke
- Emmanuelle Gouillart
- Christian Horea
- Thouis (Ray) Jones
- Almar Klein
- Xavier Moles Lopez
- Alexis Mignon
- Juan Nunez-Iglesias
- Zachary Pincus
- Nicolas Pinto
- Davin Potts
- Malcolm Reynolds
- Umesh Sharma
- Johannes Sch?nberger
- Chintak Sheth
- Kirill Shklovsky
- Steven Silvester
- Matt Terry
- Riaan van den Dool
- St?fan van der Walt
- Josh Warner
- Adam Wisniewski
- Yang Zetian
- Tony S Yu

From josef.pktd at gmail.com  Mon Oct 21 22:36:51 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 21 Oct 2013 22:36:51 -0400
Subject: [SciPy-User] optimization with ill conditioned Hessian
In-Reply-To: <CAB6mnxKaHoLks3aS+4Uq5=Wu3ntzWaz38E0QDoU96aREAXxJPQ@mail.gmail.com>
References: <CAMMTP+AVZbKmuA60K0dMnWN0nWzKmX1Sg4U5bd1zxM2UwHM1aQ@mail.gmail.com>
	<CAB6mnxKaHoLks3aS+4Uq5=Wu3ntzWaz38E0QDoU96aREAXxJPQ@mail.gmail.com>
Message-ID: <CAMMTP+Dy-+197nDiKh0YySr=o-P6HizK-rBGOfMKzy7n_VrqYg@mail.gmail.com>

On Fri, Oct 18, 2013 at 11:47 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
>
> On Fri, Oct 18, 2013 at 8:16 PM, <josef.pktd at gmail.com> wrote:
>>
>> Does scipy have another optimizer besides fmin (Nelder-Mead) that is
>> robust to near-singular, high condition number Hessian?
>>
>> fmin_bfgs goes into neverland, values become huge until I get some
>> nans in my calculations.
>>
>> What would be nice is an optimizer that uses derivatives, but
>> regularizes, forces Hessian or equivalent to be positive definite.
>>
>>
>> Background
>> I'm trying to replicate a textbook example that has data and matrix
>> inverses that are "not nice". fmin (Nelder-Mead) is getting pretty
>> close to the Stata numbers. However fmin_bfgs has been my preferred
>> default optimizer for some time.
>>
>> Aside:
>> It looks like it's a good test case to make my linear algebra more robust.
>> np.linalg.pinv(x.T.dot(x)) doesn't seem to be robust enough for this case.
>> And no idea why a textbook would use an example like that.
>> And no idea if Stata doesn't just make up the numbers.
>
>
> This would be better if you used the svd decomposition of x and did your own
> pinv. Might also try scaling the columns of x.
>
> Unscaled, that would be
>
> u*d*v = svd(x)
> pinv(x.T.dot(x)) = v.T * (1/d**2) * v
>
> where elements of 1/d**2  are set to zero if the corresponding term of d is
> below a cutoff. Scaling adds diagonal terms at both ends of that.

I thought I will have to do something like this, but I would have to
redesign my code because now I just hand x.T.dot(x) or similar
matrices around as function arguments. (I took some notes, but will
postpone this for now.)

It turns out that one of the variables is very badly scaled, which
caused that exp(x beta) easily overflows and that the condition number
is so high. It's the strongest case that I have seen so far where
scaling the data has a large influence on the numerical results.

I thought textbook examples should be "nice". (I don't have the
textbook just the Stata results).
After rescaling, I don't have problems with near singularities, and
fmin_bfgs works well again.

Also my numbers are now pretty close to those of Stata.
---

Still, in scipy 0.12.0rc1 (which I'm using for this) fmin_bfgs doesn't
avoid climbing up the hill instead of down.

Thanks,

Josef

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


From josef.pktd at gmail.com  Mon Oct 21 23:00:48 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 21 Oct 2013 23:00:48 -0400
Subject: [SciPy-User] optimization with ill conditioned Hessian
	(josef.pktd@gmail.com)
In-Reply-To: <CAGvd0=iOxQmt1PDhO3RytuBkY2v+EgyAXD0-JyOf+X026d2LbQ@mail.gmail.com>
References: <CAGvd0=iOxQmt1PDhO3RytuBkY2v+EgyAXD0-JyOf+X026d2LbQ@mail.gmail.com>
Message-ID: <CAMMTP+AVvn1Cb8yUW-X3p7i=_w9peHeV6K-7ThCz_-eNUd9a+Q@mail.gmail.com>

On Sat, Oct 19, 2013 at 5:09 PM, federico vaggi
<vaggi.federico at gmail.com> wrote:
> Hey Josef,
>
> If the problem you are dealing with is some kind of least square problem,
> you might find this paper helpful:
>
> http://arxiv.org/abs/1201.5885

Thanks for the link.

My problem has a quadratic form but it cannot be rewritten as a least
squares problem, at least not in it's general form.
That's the reason I'm using the general optimizers, mainly fmin and fmin_bfgs.

Josef

>
> Federico
>
>>
>> Message: 1
>> Date: Fri, 18 Oct 2013 22:16:28 -0400
>> From: josef.pktd at gmail.com
>> Subject: [SciPy-User] optimization with ill conditioned Hessian
>> To: SciPy Users List <scipy-user at scipy.org>
>> Message-ID:
>>
>> <CAMMTP+AVZbKmuA60K0dMnWN0nWzKmX1Sg4U5bd1zxM2UwHM1aQ at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Does scipy have another optimizer besides fmin (Nelder-Mead) that is
>> robust to near-singular, high condition number Hessian?
>>
>> fmin_bfgs goes into neverland, values become huge until I get some
>> nans in my calculations.
>>
>> What would be nice is an optimizer that uses derivatives, but
>> regularizes, forces Hessian or equivalent to be positive definite.
>>
>>
>> Background
>> I'm trying to replicate a textbook example that has data and matrix
>> inverses that are "not nice". fmin (Nelder-Mead) is getting pretty
>> close to the Stata numbers. However fmin_bfgs has been my preferred
>> default optimizer for some time.
>>
>> Aside:
>> It looks like it's a good test case to make my linear algebra more robust.
>> np.linalg.pinv(x.T.dot(x)) doesn't seem to be robust enough for this case.
>> And no idea why a textbook would use an example like that.
>> And no idea if Stata doesn't just make up the numbers.
>>
>> Thanks,
>>
>> Josef
>>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>


From ralf.gommers at gmail.com  Tue Oct 22 14:08:13 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 22 Oct 2013 20:08:13 +0200
Subject: [SciPy-User] Linear Programming via Simplex Algorithm
In-Reply-To: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>
References: <CAEQapLqEi390tL=6pQtthp0hGH23i15xNpib8zp68+b9xDtSzg@mail.gmail.com>
Message-ID: <CABL7CQiUY_hR_F35SBp0bPR2xWvydr-CDhJnu_+nCQwYk0g1RA@mail.gmail.com>

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.


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

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?


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


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

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131022/b76744c3/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-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.scipy.org/pipermail/scipy-user/attachments/20131022/bc09a073/attachment.html>

From ehermes at chem.wisc.edu  Thu Oct 24 19:55:40 2013
From: ehermes at chem.wisc.edu (Eric Hermes)
Date: Thu, 24 Oct 2013 18:55:40 -0500
Subject: [SciPy-User] Statically linking NumPy/SciPy against serial MKL
Message-ID: <5269B37C.5070204@chem.wisc.edu>

Hello,

I am re-sending this message because I don't believe it went through the 
first time.

I have spent a large amount of time in the past attempting to compile 
NumPy and SciPy in such a way that it can be used on clusters that do 
not have access to the Intel compiler and MKL libraries.  Specifically, 
one of the resources that I use utilizes the HTCondor distributed 
computing platform, where little can be guaranteed about the node that 
my jobs end up running on, and consequently any shared libraries that my 
code uses must be submitted along with the job itself.

As such, statically linking MKL libraries into NumPy and SciPy will make 
the code that I use substantially more portable (without recompiling), 
and less difficult to work with.  I have in the past managed to 
statically link in the MKL libraries that NumPy and SciPy need, but only 
by manually re-linking the libraries that these codes create, adding in 
the linker commands that the Intel Link Advisor suggests.

The official way to link against MKL in NumPy is to add an [mkl] section 
to the site.cfg configuration script, and pass the libraries that you 
wish to link against to mkl_libs (e.g. mkl_libs = mkl_intel_lp64, 
mkl_sequential, mkl_core).  I have glanced through the distutils scripts 
that NumPy uses, but I am not particularly familiar with distutils and 
as such I am having a difficult time figuring out how I would go about 
modifying the linker commands that the build script uses away from 
"-lmkl_intel_lp64 -lmkl_sequential -lmkl_core" to "-Wl,--start-group 
$(MKLROOT)/lib/intel64/libmkl_intel_lp64.a 
$(MKLROOT)/lib/intel64/libmkl_sequential.a 
$(MKLROOT)/lib/intel64/libmkl_core.a -Wl,--end-group".

Additionally, it would seem that the distutils script adds libguide and 
libmkl_avx to the list of libraries to link against, which I do not want 
because the former is a threading library and I want a serial version of 
NumPy, and the latter does not have a static version to link against.

Basically, I'm wondering if there isn't an easier way to compile NumPy 
and SciPy such that they are statically linked against the serial MKL 
libraries.  I know for example that adding "-static-intel" to the linker 
command statically links in the Intel compiler libraries, but as far as 
I can tell there is no such argument that does the same for MKL libraries.

It would currently seem to me that my only options are to manually 
relink all NumPy and SciPy libraries after they have been built by 
distutils, or to heavily modify the NumPy build scripts in some fashion 
to correctly compile them statically in the first place.  I would like 
to avoid the former, and I have no idea how I would go about doing the 
latter.

I am cross-posting this message to both the Intel MKL support forums, 
and the SciPy-user mailing list.

Thank you,

Eric Hermes

-- 
Eric Hermes
J.R. Schmidt Group
Chemistry Department
University of Wisconsin - Madison



From d.l.goldsmith at gmail.com  Thu Oct 24 23:40:32 2013
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 24 Oct 2013 20:40:32 -0700
Subject: [SciPy-User] Overcoming slow/non-convergence w/ integrate.quad
Message-ID: <CAFtPsZpNuw6HGuT85jJnueteXp_Og_MZUnmQ4XUCu_SE+_gqXQ@mail.gmail.com>

I've written a little function, based on the Cauchy Integral Formula and
utilizing scipy.integrate.quad for the integration, to return whether or
not a point is inside a simple closed curve made up from Bezier pieces.
 For my tests I'm using two quadratic Beziers, one beginning @ (1,0),
having (0,1) as the middle control point, and ending at (-1,0), the
"closer" being its reflection in the x-axis (i.e., (-1,0), (0,-1), (1,0)).
 For my interior test points, all of which pass, I'm using (so far)
(0,0), (1-1e-6,0), (-1+1e-6, 0).  For my exterior test points, I'm trying
to use (1+1e-6,0), (-1-1e-6, 0), and these are where I'm having trouble:
they don't pass (integral of the imaginary part non-zero), but (1+1e-5,0),
(-1-1e-5, 0), (1+5e-6,0), (-1-5e-6, 0) all do pass (integral of the
imaginary part zero to 12 decimal places), so I'm reasonably confident that
I have the algorithm right (I forgot to mention that the integral of the
imaginary part for my interior check points is 2pi, just as it should be).
 (1+2.5e-6,0) & (-1-2.5e-6, 0) don't pass, and full_output=1 returns the
clue (not returned for my "preferred" test points) "The integral is
probably divergent, or slowly convergent," which is what I supposed was the
problem; but I experimented w/ the epsabs, epsrel, and limit arguments,
none of which helped.  The other main clue I have is that, for the 1+1e-6
cases, the first error term in elist is twice as large (in abs val) as the
first integral sub-value in rlist!

Any advice?  Should I try a different quadrature function, and if so, which
one?  Should I just keep cranking down the eps's and/or cranking up the
limit?  Other options/suggestions?

Thanks!

OlyDLG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131024/0aa90ae3/attachment.html>

From d.l.goldsmith at gmail.com  Fri Oct 25 01:45:30 2013
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 24 Oct 2013 22:45:30 -0700
Subject: [SciPy-User] Fwd: Overcoming slow/non-convergence w/ integrate.quad
In-Reply-To: <CAFtPsZpNuw6HGuT85jJnueteXp_Og_MZUnmQ4XUCu_SE+_gqXQ@mail.gmail.com>
References: <CAFtPsZpNuw6HGuT85jJnueteXp_Og_MZUnmQ4XUCu_SE+_gqXQ@mail.gmail.com>
Message-ID: <CAFtPsZr4-t_3aNY-Z0COHb3bTdhETCJgZEQsn+J8i-NfSAyUcQ@mail.gmail.com>

Never mind: it finally dawned on me that as long as all I need to know is
insies or outsies, so I can just integrate f(z)=1--as I am--then my
integral is almost trivial analytically.

Sorry for the noise.

DG
---------- Forwarded message ----------
From: David Goldsmith <d.l.goldsmith at gmail.com>
Date: Thu, Oct 24, 2013 at 8:40 PM
Subject: Overcoming slow/non-convergence w/ integrate.quad
To: scipy-user at scipy.org


I've written a little function, based on the Cauchy Integral Formula and
utilizing scipy.integrate.quad for the integration, to return whether or
not a point is inside a simple closed curve made up from Bezier pieces.
 For my tests I'm using two quadratic Beziers, one beginning @ (1,0),
having (0,1) as the middle control point, and ending at (-1,0), the
"closer" being its reflection in the x-axis (i.e., (-1,0), (0,-1), (1,0)).
 For my interior test points, all of which pass, I'm using (so far)
(0,0), (1-1e-6,0), (-1+1e-6, 0).  For my exterior test points, I'm trying
to use (1+1e-6,0), (-1-1e-6, 0), and these are where I'm having trouble:
they don't pass (integral of the imaginary part non-zero), but (1+1e-5,0),
(-1-1e-5, 0), (1+5e-6,0), (-1-5e-6, 0) all do pass (integral of the
imaginary part zero to 12 decimal places), so I'm reasonably confident that
I have the algorithm right (I forgot to mention that the integral of the
imaginary part for my interior check points is 2pi, just as it should be).
 (1+2.5e-6,0) & (-1-2.5e-6, 0) don't pass, and full_output=1 returns the
clue (not returned for my "preferred" test points) "The integral is
probably divergent, or slowly convergent," which is what I supposed was the
problem; but I experimented w/ the epsabs, epsrel, and limit arguments,
none of which helped.  The other main clue I have is that, for the 1+1e-6
cases, the first error term in elist is twice as large (in abs val) as the
first integral sub-value in rlist!

Any advice?  Should I try a different quadrature function, and if so, which
one?  Should I just keep cranking down the eps's and/or cranking up the
limit?  Other options/suggestions?

Thanks!

OlyDLG



-- 
>From "A Letter From The Future" in "Peak Everything" by Richard Heinberg:

"By the time I was an older teenager, a certain...attitude was developing
among the young people...a feeling of utter contempt for anyone over a
certain age--maybe 30 or 40.  The adults had consumed so many resources,
and now there were none left for their own children...when those adults
were younger, they [were] just doing what everybody else was doing...they
figured it was normal to cut down ancient forests for...phone books, pump
every last gallon of oil to power their SUV's...[but] for...my generation
all that was just a dim memory...We [grew up] living in darkness, with
shortages of food and water, with riots in the streets, with people begging
on street corners...for us, the adults were the enemy."

Want to *really* understand what's *really* going on?  Read "Peak
Everything."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131024/370645f2/attachment.html>

From franz_lambert_engel at yahoo.de  Fri Oct 25 02:40:07 2013
From: franz_lambert_engel at yahoo.de (flambert)
Date: Thu, 24 Oct 2013 23:40:07 -0700 (PDT)
Subject: [SciPy-User] Thin out data
Message-ID: <1382683206055-18816.post@n7.nabble.com>

Hi,

I've a little problem. With an industrial robot and a lasersensor I measure
an edge. That works good, but if the robot stands still I get a higher
measurement noise and a higher amount of "edge-points" in this sector. Here
two images:
<http://scipy-user.10969.n7.nabble.com/file/n18816/wholeEdge.png> 
<http://scipy-user.10969.n7.nabble.com/file/n18816/partOfEdge.png> 

In the image you can see that I try to insert an spline. But in the effected
sector the spline is very bumpy. The data amount in this area is much higher
then the data amount in the "normal" areas. Is there a good method to reduce
the amount of data. I think if I solve this my spline would be smoother. I
also tried to make the spline smoother by its own functions, but the result
is that the spline becomes smoother in the effected area but will be nearly
linear in the "normal" area.

Thanks and regards,
     franz



--
View this message in context: http://scipy-user.10969.n7.nabble.com/Thin-out-data-tp18816.html
Sent from the Scipy-User mailing list archive at Nabble.com.


From davidmenhur at gmail.com  Fri Oct 25 03:29:45 2013
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Fri, 25 Oct 2013 09:29:45 +0200
Subject: [SciPy-User] Thin out data
In-Reply-To: <1382683206055-18816.post@n7.nabble.com>
References: <1382683206055-18816.post@n7.nabble.com>
Message-ID: <CAJhcF=28cR_RWijwX212nGW7DbZbVQRNPk+uNKZKrrXt36h45Q@mail.gmail.com>

You could use binned_statistics, taking the average (mean, median...) over
certain window. This is, in my experience, more robust than using a spline
to smooth data.

In any case, your data seems to have suspicious patterns. Maybe you could
exploit them to get better measurements.

/David.


On 25 October 2013 08:40, flambert <franz_lambert_engel at yahoo.de> wrote:

> Hi,
>
> I've a little problem. With an industrial robot and a lasersensor I measure
> an edge. That works good, but if the robot stands still I get a higher
> measurement noise and a higher amount of "edge-points" in this sector. Here
> two images:
> <http://scipy-user.10969.n7.nabble.com/file/n18816/wholeEdge.png>
> <http://scipy-user.10969.n7.nabble.com/file/n18816/partOfEdge.png>
>
> In the image you can see that I try to insert an spline. But in the
> effected
> sector the spline is very bumpy. The data amount in this area is much
> higher
> then the data amount in the "normal" areas. Is there a good method to
> reduce
> the amount of data. I think if I solve this my spline would be smoother. I
> also tried to make the spline smoother by its own functions, but the result
> is that the spline becomes smoother in the effected area but will be nearly
> linear in the "normal" area.
>
> Thanks and regards,
>      franz
>
>
>
> --
> View this message in context:
> http://scipy-user.10969.n7.nabble.com/Thin-out-data-tp18816.html
> Sent from the Scipy-User mailing list archive at Nabble.com.
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131025/854e941a/attachment.html>

From newville at cars.uchicago.edu  Fri Oct 25 07:36:18 2013
From: newville at cars.uchicago.edu (Matt Newville)
Date: Fri, 25 Oct 2013 06:36:18 -0500
Subject: [SciPy-User] Thin out data
In-Reply-To: <1382683206055-18816.post@n7.nabble.com>
References: <1382683206055-18816.post@n7.nabble.com>
Message-ID: <CA+7ESbqwLONtz+PnA+QYToCMmhJR7HaA5JMur3N9bCUd-s1zgw@mail.gmail.com>

Hi,

On Fri, Oct 25, 2013 at 1:40 AM, flambert <franz_lambert_engel at yahoo.de> wrote:
> Hi,
>
> I've a little problem. With an industrial robot and a lasersensor I measure
> an edge. That works good, but if the robot stands still I get a higher
> measurement noise and a higher amount of "edge-points" in this sector. Here
> two images:
> <http://scipy-user.10969.n7.nabble.com/file/n18816/wholeEdge.png>
> <http://scipy-user.10969.n7.nabble.com/file/n18816/partOfEdge.png>
>
> In the image you can see that I try to insert an spline. But in the effected
> sector the spline is very bumpy. The data amount in this area is much higher
> then the data amount in the "normal" areas. Is there a good method to reduce
> the amount of data. I think if I solve this my spline would be smoother. I
> also tried to make the spline smoother by its own functions, but the result
> is that the spline becomes smoother in the effected area but will be nearly
> linear in the "normal" area.
>
> Thanks and regards,
>      franz

If you haven't done so already, try a Savitsky-Golay filter to smooth
the data: http://wiki.scipy.org/Cookbook/SavitzkyGolay
If the data in the very spiky section is oversampled, you may want to
interpolate (the filtered data) onto a uniform grid.

--Matt


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-User] [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 a.klein at science-applied.nl  Sat Oct 26 08:18:12 2013
From: a.klein at science-applied.nl (Almar Klein)
Date: Sat, 26 Oct 2013 14:18:12 +0200
Subject: [SciPy-User] ANN: Visvis 1.9 - The object oriented approach to
	visualization
Message-ID: <CAB_T6=nRLb=YVjL2OSU9PLY+WOvRq9PLPyjXF7veCeiE+VCW3g@mail.gmail.com>

On behalf of the Visvis development team, I'm pleased to announce version
1.9 of Visvis - the object oriented approach to visualization.

Essentially, visvis is an object oriented layer of Python on top of OpenGl,
thereby combining the power of OpenGl with the usability of Python. A
Matlab-like interface in the form of a set of functions allows easy
creation of objects (e.g. plot(), imshow(), volshow(), surf()).

This is mostly a maintenance release. Note that development of Visvis will
be limited to basic maintenance, as I now focus my time on
Vispy<http://vispy.org>
.

Website: https://code.google.com/p/visvis/
Discussion group: http://groups.google.com/group/visvis
Release notes: https://code.google.com/p/visvis/wiki/releaseNotes

Regards,
  Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131026/d39a0e18/attachment.html>

From francois-xavier.thomas at airinov.fr  Wed Oct 16 13:24:42 2013
From: francois-xavier.thomas at airinov.fr (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Thomas?=)
Date: Wed, 16 Oct 2013 19:24:42 +0200
Subject: [SciPy-User] SciPy leastsq behavior
Message-ID: <CAEwRaO7x1P4Ho5mUUGzfR1bO3MUVkJ3A2HiiZRWrpw=g9V2+Qw@mail.gmail.com>

Hi all,

I am trying to debug precision errors in an optimization process using
ScipPy's leastsq method.

Attached is a log of the start of the optimization process, showing
mean errors and differences between consecutive X values for each f(X)
call.

  * Why is f(X) computed even though X hasn't moved at all? Did I miss
something obvious?
  * I set the "diag" parameter to [0.1, 0.1, 0.1, 1000, 500, 500, 0.1,
0.1, 0.01, 0.01, 0.01, 0.01], which roughly corresponds to the order
of magnitude of my X values. Should that help the optimizer?
  * Can leastsq work well on higher floating point precisions (i.e.
numpy.float128)? What is the underlying precision of the MINPACK
libraries?

I realise you might not know the answers to all of these questions,
but any hint or caveat you might have from your own experience would
be useful!

Thanks!
Fran?ois-Xavier

-- 
Fran?ois-Xavier Thomas -- Image Processing

AIRINOV
Incubateur PRINE
110 rue des Poissonniers -  48 voie CI18
75899 Paris Cedex 18
09 72 39 75 82
www.airinov.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: optimization.log
Type: application/octet-stream
Size: 6970 bytes
Desc: not available
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131016/3ee4d02d/attachment.obj>

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-User] [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.scipy.org/pipermail/scipy-user/attachments/20131017/e5cc61a5/attachment.html>

From simon.michnowicz at monash.edu  Fri Oct 18 01:38:07 2013
From: simon.michnowicz at monash.edu (Simon Michnowicz)
Date: Fri, 18 Oct 2013 16:38:07 +1100
Subject: [SciPy-User] Unit Test Seg Fault on SciPy
Message-ID: <CACmKtinHA5uOv+RFvo_zuU7WKu1SNhu6v=OV3qBxeOQDhQpPvQ@mail.gmail.com>

Dear Group
I just built Scipy with python 2.7.5 but the unit test produce an error
which I can not resolve
test_nonlin.TestJacobianDotSolve.test_broyden1 ... Segmentation fault

 When I googled the error, one site implied that MKL should not be used.
http://mail.scipy.org/pipermail/scipy-dev/2011-September/016588.html

Your advice would be most appreciated. Is this still the case?

I used gcc (4.5.3) with the MKL (2013)
I found I had to set "LDFLAGS=-shared" for the linker to work correctly.
numpy.test() worked OK,

The following system information is provided for you below.
During the build, the system seemed to see all libraries

blas_opt_info:
blas_mkl_info:
  FOUND:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/opt/sw/intel-2013.3/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/sw/intel-2013.3/mkl/include']

  FOUND:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/opt/sw/intel-2013.3/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/sw/intel-2013.3/mkl/include']

lapack_opt_info:
lapack_mkl_info:
mkl_info:
  FOUND:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/opt/sw/intel-2013.3/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/sw/intel-2013.3/mkl/include']

  FOUND:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/opt/sw/intel-2013.3/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/sw/intel-2013.3/mkl/include']

  FOUND:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/opt/sw/intel-2013.3/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/sw/intel-2013.3/mkl/include']

regards
Simon Michnowicz

 python -c 'from numpy.f2py.diagnose import run; run()'
------
os.name='posix'
------
sys.platform='linux2'
------
sys.version:
2.7.5 (default, Oct 16 2013, 18:02:53)
[GCC 4.5.3]
------
sys.prefix:
/opt/sw/python-2.7.5
------
sys.path=':/opt/sw/python-2.7.5/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/Cython-0.19.2-py2.7-linux-x86_64.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/python_dateutil-1.5-py2.7.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/tornado-3.1.1-py2.7.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/pyparsing-2.0.1-py2.7.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/distribute-0.6.28-py2.7.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg:/opt/sw/python-2.7.5/lib/python2.7/site-packages:/opt/sw/python-2.7.5/lib/python27.zip:/opt/sw/python-2.7.5/lib/python2.7:/opt/sw/python-2.7.5/lib/python2.7/plat-linux2:/opt/sw/python-2.7.5/lib/python2.7/lib-tk:/opt/sw/python-2.7.5/lib/python2.7/lib-old:/opt/sw/python-2.7.5/lib/python2.7/lib-dynload:/nfs/home/hpcmerc/smichnow/.local/lib/python2.7/site-packages'
------
Found new numpy version '1.7.0' in
/opt/sw/python-2.7.5/lib/python2.7/site-packages/numpy/__init__.pyc
Found f2py2e version '2' in
/opt/sw/python-2.7.5/lib/python2.7/site-packages/numpy/f2py/f2py2e.pyc
Found numpy.distutils version '0.4.0' in
'/opt/sw/python-2.7.5/lib/python2.7/site-packages/numpy/distutils/__init__.pyc'
------
Importing numpy.distutils.fcompiler ... ok
------
Checking availability of supported Fortran compilers:
Gnu95FCompiler instance properties:
  archiver        = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '-cr']
  compile_switch  = '-c'
  compiler_f77    = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '-Wall', '-ffixed
                    -form', '-fno-second-underscore', '-fPIC', '-O3', '-
                    funroll-loops']
  compiler_f90    = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '-Wall', '-fno-
                    second-underscore', '-fPIC', '-O3', '-funroll-loops']
  compiler_fix    = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '-Wall', '-ffixed
                    -form', '-fno-second-underscore', '-Wall', '-fno-second-
                    underscore', '-fPIC', '-O3', '-funroll-loops']
  libraries       = ['gfortran']
  library_dirs    = []
  linker_exe      = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '-Wall', '-
                    L/opt/sw/hdf5-1.8.7-gcc-4.5.3/lib',
'-L/opt/sw/zlib-1.2.5-
                    gcc-4.5.3/lib', '-lz', '-L/opt/sw/mpc-0.9/lib', '-
                    L/opt/sw/mpfr-2.4.2/lib', '-L/opt/sw/gmp-4.3.2/lib']
  linker_so       = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '-Wall', '-
                    L/opt/sw/hdf5-1.8.7-gcc-4.5.3/lib',
'-L/opt/sw/zlib-1.2.5-
                    gcc-4.5.3/lib', '-lz', '-L/opt/sw/mpc-0.9/lib', '-
                    L/opt/sw/mpfr-2.4.2/lib', '-L/opt/sw/gmp-4.3.2/lib']
  object_switch   = '-o '
  ranlib          = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran']
  version         = LooseVersion ('4.5.3')
  version_cmd     = ['/nfs-tmp/sw/gcc-4.5.3/bin/gfortran', '--version']
GnuFCompiler instance properties:
  archiver        = ['/usr/bin/g77', '-cr']
  compile_switch  = '-c'
  compiler_f77    = ['/usr/bin/g77', '-g', '-Wall', '-fno-second-
                    underscore', '-fPIC', '-O3', '-funroll-loops']
  compiler_f90    = None
  compiler_fix    = None
  libraries       = ['g2c']
  library_dirs    = []
  linker_exe      = ['/usr/bin/g77', '-g', '-Wall', '-L/opt/sw/hdf5-1.8.7-
                    gcc-4.5.3/lib', '-L/opt/sw/zlib-1.2.5-gcc-4.5.3/lib', '-
                    lz', '-L/opt/sw/mpc-0.9/lib',
'-L/opt/sw/mpfr-2.4.2/lib',
                    '-L/opt/sw/gmp-4.3.2/lib']
  linker_so       = ['/usr/bin/g77', '-g', '-Wall', '-L/opt/sw/hdf5-1.8.7-
                    gcc-4.5.3/lib', '-L/opt/sw/zlib-1.2.5-gcc-4.5.3/lib', '-
                    lz', '-L/opt/sw/mpc-0.9/lib',
'-L/opt/sw/mpfr-2.4.2/lib',
                    '-L/opt/sw/gmp-4.3.2/lib']
  object_switch   = '-o '
  ranlib          = ['/usr/bin/g77']
  version         = LooseVersion ('3.4.6')
  version_cmd     = ['/usr/bin/g77', '--version']
Fortran compilers found:
  --fcompiler=gnu    GNU Fortran 77 compiler (3.4.6)
  --fcompiler=gnu95  GNU Fortran 95 compiler (4.5.3)
Compilers available for this platform, but not found:
  --fcompiler=absoft   Absoft Corp Fortran Compiler
  --fcompiler=compaq   Compaq Fortran Compiler
  --fcompiler=g95      G95 Fortran Compiler
  --fcompiler=intel    Intel Fortran Compiler for 32-bit apps
  --fcompiler=intele   Intel Fortran Compiler for Itanium apps
  --fcompiler=intelem  Intel Fortran Compiler for 64-bit apps
  --fcompiler=lahey    Lahey/Fujitsu Fortran 95 Compiler
  --fcompiler=nag      NAGWare Fortran 95 Compiler
  --fcompiler=pathf95  PathScale Fortran Compiler
  --fcompiler=pg       Portland Group Fortran Compiler
  --fcompiler=vast     Pacific-Sierra Research Fortran 90 Compiler
Compilers not available on this platform:
  --fcompiler=hpux      HP Fortran 90 Compiler
  --fcompiler=ibm       IBM XL Fortran Compiler
  --fcompiler=intelev   Intel Visual Fortran Compiler for Itanium apps
  --fcompiler=intelv    Intel Visual Fortran Compiler for 32-bit apps
  --fcompiler=intelvem  Intel Visual Fortran Compiler for 64-bit apps
  --fcompiler=mips      MIPSpro Fortran Compiler
  --fcompiler=none      Fake Fortran compiler
  --fcompiler=sun       Sun or Forte Fortran 95 Compiler
For compiler details, run 'config_fc --verbose' setup command.
------
Importing numpy.distutils.cpuinfo ... ok
------
CPU information: CPUInfoBase__get_nbits getNCPUs has_3dnow has_3dnowext
has_mmx has_sse has_sse2 has_sse3 is_64bit is_AMD is_Opteron ------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131018/e0c58c94/attachment.html>

From vidya.setlur at gmail.com  Wed Oct 23 14:20:31 2013
From: vidya.setlur at gmail.com (raghavan)
Date: Wed, 23 Oct 2013 11:20:31 -0700 (PDT)
Subject: [SciPy-User] Constrained optimization algorithm for layout?
Message-ID: <ccc0fa59-aad8-441e-965c-c6ea532d0e04@googlegroups.com>

Hi,

I'm trying to create an arrangement of several UI objects in a layout, each 
having their own constraints in terms of how they need to be placed and 
aligned. What optimization algorithm would be useful for an application 
like this?

Thanks,

Raghavan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131023/6aba8507/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-User] [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 stefan at sun.ac.za  Sat Oct 19 10:28:46 2013
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 19 Oct 2013 16:28:46 +0200
Subject: [SciPy-User] ANN: scikit-image 0.9.0
Message-ID: <CABDkGQk78qeszmTdE4b5WEBiqkBTLZzA1W8_CCjT1QMg6iqWOA@mail.gmail.com>

Announcement: scikits-image 0.9.0
=================================

We're happy to announce the release of scikit-image v0.9.0!

scikit-image is an image processing toolbox for SciPy that includes algorithms
for segmentation, geometric transformations, color space manipulation,
analysis, filtering, morphology, feature detection, and more.

For more information, examples, and documentation, please visit our website:

    http://scikit-image.org


New Features
------------

`scikit-image` now runs without translation under both Python 2 and 3.

In addition to several bug fixes, speed improvements and examples, the 204 pull
requests merged for this release include the following new features (PR number
in brackets):

Segmentation:

- 3D support in SLIC segmentation (#546)
- SLIC voxel spacing (#719)
- Generalized anisotropic spacing support for random_walker (#775)
- Yen threshold method (#686)

Transforms and filters:

- SART algorithm for tomography reconstruction (#584)
- Gabor filters (#371)
- Hough transform for ellipses (#597)
- Fast resampling of nD arrays (#511)
- Rotation axis center for Radon transforms with inverses. (#654)
- Reconstruction circle in inverse Radon transform (#567)
- Pixelwise image adjustment curves and methods (#505)

Feature detection:

- [experimental API] BRIEF feature descriptor (#591)
- [experimental API] Censure (STAR) Feature Detector (#668)
- Octagon structural element (#669)
- Add non rotation invariant uniform LBPs (#704)

Color and noise:

- Add deltaE color comparison and lab2lch conversion (#665)
- Isotropic denoising (#653)
- Generator to add various types of random noise to images (#625)
- Color deconvolution for immunohistochemical images (#441)
- Color label visualization (#485)

Drawing and visualization:

- Wu's anti-aliased circle, line, bezier curve (#709)
- Linked image viewers and docked plugins (#575)
- Rotated ellipse + bezier curve drawing (#510)
- PySide & PyQt4 compatibility in skimage-viewer (#551)

Other:

- Python 3 support without 2to3. (#620)
- 3D Marching Cubes (#469)
- Line, Circle, Ellipse total least squares fitting and RANSAC algorithm (#440)
- N-dimensional array padding (#577)
- Add a wrapper around `scipy.ndimage.gaussian_filter` with useful
default behaviors. (#712)
- Predefined structuring elements for 3D morphology (#484)


API changes
-----------

The following backward-incompatible API changes were made between 0.8 and 0.9:

- No longer wrap ``imread`` output in an ``Image`` class
- Change default value of `sigma` parameter in ``skimage.segmentation.slic``
  to 0
- ``hough_circle`` now returns a stack of arrays that are the same size as the
  input image. Set the ``full_output`` flag to True for the old behavior.
- The following functions were deprecated over two releases:
  `skimage.filter.denoise_tv_chambolle`,
  `skimage.morphology.is_local_maximum`, `skimage.transform.hough`,
  `skimage.transform.probabilistic_hough`,`skimage.transform.hough_peaks`.
  Their functionality still exists, but under different names.


Contributors to this release
----------------------------

This release was made possible by the collaborative efforts of many
contributors, both new and old.  They are listed in alphabetical order by
surname:

- Ankit Agrawal
- K.-Michael Aye
- Chris Beaumont
- Fran?ois Boulogne
- Luis Pedro Coelho
- Marianne Corvellec
- Olivier Debeir
- Ferdinand Deger
- Kemal Eren
- Jostein B? Fl?ystad
- Christoph Gohlke
- Emmanuelle Gouillart
- Christian Horea
- Thouis (Ray) Jones
- Almar Klein
- Xavier Moles Lopez
- Alexis Mignon
- Juan Nunez-Iglesias
- Zachary Pincus
- Nicolas Pinto
- Davin Potts
- Malcolm Reynolds
- Umesh Sharma
- Johannes Sch?nberger
- Chintak Sheth
- Kirill Shklovsky
- Steven Silvester
- Matt Terry
- Riaan van den Dool
- St?fan van der Walt
- Josh Warner
- Adam Wisniewski
- Yang Zetian
- Tony S Yu


From stefan at sun.ac.za  Mon Oct 21 02:48:20 2013
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 21 Oct 2013 08:48:20 +0200
Subject: [SciPy-User] ANN: scikit-image 0.9 release
Message-ID: <CABDkGQk2LpzkaFtMZ9jDRn3D7DSrgPGkPDfAoE1HppTWCA-mcA@mail.gmail.com>

We're happy to announce the release of scikit-image v0.9.0!

scikit-image is an image processing toolbox for SciPy that includes algorithms
for segmentation, geometric transformations, color space manipulation,
analysis, filtering, morphology, feature detection, and more.

For more information, examples, and documentation, please visit our website:

    http://scikit-image.org


New Features
------------

`scikit-image` now runs without translation under both Python 2 and 3.

In addition to several bug fixes, speed improvements and examples, the 204 pull
requests merged for this release include the following new features (PR number
in brackets):

Segmentation:

- 3D support in SLIC segmentation (#546)
- SLIC voxel spacing (#719)
- Generalized anisotropic spacing support for random_walker (#775)
- Yen threshold method (#686)

Transforms and filters:

- SART algorithm for tomography reconstruction (#584)
- Gabor filters (#371)
- Hough transform for ellipses (#597)
- Fast resampling of nD arrays (#511)
- Rotation axis center for Radon transforms with inverses. (#654)
- Reconstruction circle in inverse Radon transform (#567)
- Pixelwise image adjustment curves and methods (#505)

Feature detection:

- [experimental API] BRIEF feature descriptor (#591)
- [experimental API] Censure (STAR) Feature Detector (#668)
- Octagon structural element (#669)
- Add non rotation invariant uniform LBPs (#704)

Color and noise:

- Add deltaE color comparison and lab2lch conversion (#665)
- Isotropic denoising (#653)
- Generator to add various types of random noise to images (#625)
- Color deconvolution for immunohistochemical images (#441)
- Color label visualization (#485)

Drawing and visualization:

- Wu's anti-aliased circle, line, bezier curve (#709)
- Linked image viewers and docked plugins (#575)
- Rotated ellipse + bezier curve drawing (#510)
- PySide & PyQt4 compatibility in skimage-viewer (#551)

Other:

- Python 3 support without 2to3. (#620)
- 3D Marching Cubes (#469)
- Line, Circle, Ellipse total least squares fitting and RANSAC algorithm (#440)
- N-dimensional array padding (#577)
- Add a wrapper around `scipy.ndimage.gaussian_filter` with useful
default behaviors. (#712)
- Predefined structuring elements for 3D morphology (#484)


API changes
-----------

The following backward-incompatible API changes were made between 0.8 and 0.9:

- No longer wrap ``imread`` output in an ``Image`` class
- Change default value of `sigma` parameter in ``skimage.segmentation.slic``
  to 0
- ``hough_circle`` now returns a stack of arrays that are the same size as the
  input image. Set the ``full_output`` flag to True for the old behavior.
- The following functions were deprecated over two releases:
  `skimage.filter.denoise_tv_chambolle`,
  `skimage.morphology.is_local_maximum`, `skimage.transform.hough`,
  `skimage.transform.probabilistic_hough`,`skimage.transform.hough_peaks`.
  Their functionality still exists, but under different names.


Contributors to this release
----------------------------

This release was made possible by the collaborative efforts of many
contributors, both new and old.  They are listed in alphabetical order by
surname:

- Ankit Agrawal
- K.-Michael Aye
- Chris Beaumont
- Fran?ois Boulogne
- Luis Pedro Coelho
- Marianne Corvellec
- Olivier Debeir
- Ferdinand Deger
- Kemal Eren
- Jostein B? Fl?ystad
- Christoph Gohlke
- Emmanuelle Gouillart
- Christian Horea
- Thouis (Ray) Jones
- Almar Klein
- Xavier Moles Lopez
- Alexis Mignon
- Juan Nunez-Iglesias
- Zachary Pincus
- Nicolas Pinto
- Davin Potts
- Malcolm Reynolds
- Umesh Sharma
- Johannes Sch?nberger
- Chintak Sheth
- Kirill Shklovsky
- Steven Silvester
- Matt Terry
- Riaan van den Dool
- St?fan van der Walt
- Josh Warner
- Adam Wisniewski
- Yang Zetian
- Tony S Yu


From ehermes at chem.wisc.edu  Thu Oct 24 14:09:38 2013
From: ehermes at chem.wisc.edu (Eric Hermes)
Date: Thu, 24 Oct 2013 13:09:38 -0500
Subject: [SciPy-User] Statically linking NumPy/SciPy against serial MKL
Message-ID: <52696262.4040504@chem.wisc.edu>

Hello,

I have spent a large amount of time in the past attempting to compile 
NumPy and SciPy in such a way that it can be used on clusters that do 
not have access to the Intel compiler and MKL libraries.  Specifically, 
one of the resources that I use utilizes the HTCondor distributed 
computing platform, where little can be guaranteed about the node that 
my jobs end up running on, and consequently any shared libraries that my 
code uses must be submitted along with the job itself.

As such, statically linking MKL libraries into NumPy and SciPy will make 
the code that I use substantially more portable (without recompiling), 
and less difficult to work with.  I have in the past managed to 
statically link in the MKL libraries that NumPy and SciPy need, but only 
by manually re-linking the libraries that these codes create, adding in 
the linker commands that the Intel Link Advisor suggests.

The official way to link against MKL in NumPy is to add an [mkl] section 
to the site.cfg configuration script, and pass the libraries that you 
wish to link against to mkl_libs (e.g. mkl_libs = mkl_intel_lp64, 
mkl_sequential, mkl_core).  I have glanced through the distutils scripts 
that NumPy uses, but I am not particularly familiar with distutils and 
as such I am having a difficult time figuring out how I would go about 
modifying the linker commands that the build script uses away from 
"-lmkl_intel_lp64 -lmkl_sequential -lmkl_core" to "-Wl,--start-group 
$(MKLROOT)/lib/intel64/libmkl_intel_lp64.a 
$(MKLROOT)/lib/intel64/libmkl_sequential.a 
$(MKLROOT)/lib/intel64/libmkl_core.a -Wl,--end-group".

Additionally, it would seem that the distutils script adds libguide and 
libmkl_avx to the list of libraries to link against, which I do not want 
because the former is a threading library and I want a serial version of 
NumPy, and the latter does not have a static version to link against.

Basically, I'm wondering if there isn't an easier way to compile NumPy 
and SciPy such that they are statically linked against the serial MKL 
libraries.  I know for example that adding "-static-intel" to the linker 
command statically links in the Intel compiler libraries, but as far as 
I can tell there is no such argument that does the same for MKL libraries.

It would currently seem to me that my only options are to manually 
relink all NumPy and SciPy libraries after they have been built by 
distutils, or to heavily modify the NumPy build scripts in some fashion 
to correctly compile them statically in the first place.  I would like 
to avoid the former, and I have no idea how I would go about doing the 
latter.

I am cross-posting this message to both the Intel MKL support forums, 
and the SciPy-user mailing list.

Thank you,

Eric Hermes

-- 
Eric Hermes
J.R. Schmidt Group
Chemistry Department
University of Wisconsin - Madison



From robert.kern at gmail.com  Mon Oct 28 10:05:33 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 28 Oct 2013 14:05:33 +0000
Subject: [SciPy-User] Constrained optimization algorithm for layout?
In-Reply-To: <ccc0fa59-aad8-441e-965c-c6ea532d0e04@googlegroups.com>
References: <ccc0fa59-aad8-441e-965c-c6ea532d0e04@googlegroups.com>
Message-ID: <CAF6FJitH6qms5kkYUphZ5Mx6dMRbB+B0ekihsdkjvXN4UUMZ3Q@mail.gmail.com>

On Wed, Oct 23, 2013 at 7:20 PM, raghavan <vidya.setlur at gmail.com> wrote:
>
> Hi,
>
> I'm trying to create an arrangement of several UI objects in a layout,
each having their own constraints in terms of how they need to be placed
and aligned. What optimization algorithm would be useful for an application
like this?

A specialized version of linear programming works well. Cassowary is the
most widely used solver for this; it implements linear programming with a
hierarchy of constraints. An implementation of Cassowary is used in Apple's
new Auto Layout mechanism.

  http://www.cs.washington.edu/research/constraints/cassowary/

I have Cython bindings to the Cassowary solver here:

  https://pypi.python.org/pypi/casuarius

Casuarius is used in the layout mechanism of Enaml:

  https://github.com/nucleic/enaml/tree/master/enaml/layout

A slightly different variant is the Auckland Layout Model, which uses a
standard linear programming solver without hierarchies (though it does
require one that is optimized for restarts):

  http://aucklandlayout.sourceforge.net/

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131028/4cf83872/attachment.html>

From newville at cars.uchicago.edu  Mon Oct 28 10:48:50 2013
From: newville at cars.uchicago.edu (Matt Newville)
Date: Mon, 28 Oct 2013 09:48:50 -0500
Subject: [SciPy-User] SciPy leastsq behavior
In-Reply-To: <CAEwRaO7x1P4Ho5mUUGzfR1bO3MUVkJ3A2HiiZRWrpw=g9V2+Qw@mail.gmail.com>
References: <CAEwRaO7x1P4Ho5mUUGzfR1bO3MUVkJ3A2HiiZRWrpw=g9V2+Qw@mail.gmail.com>
Message-ID: <CA+7ESbqvfHew0-sZbTzZbx84bBpWDv0dJcYXYs=fW5FbvYhZDQ@mail.gmail.com>

Hi Francois-Xavier,

I'm not sure I can answer all your questions correctly but....

On Wed, Oct 16, 2013 at 12:24 PM, Fran?ois-Xavier Thomas
<francois-xavier.thomas at airinov.fr> wrote:
> Hi all,
>
> I am trying to debug precision errors in an optimization process using
> ScipPy's leastsq method.
>
> Attached is a log of the start of the optimization process, showing
> mean errors and differences between consecutive X values for each f(X)
> call.
>
>   * Why is f(X) computed even though X hasn't moved at all? Did I miss
> something obvious?

The objective function will be called many times to compute the
Jacobian with values varying at the level of machine tolerance.
Depending on how you print out the values, it may appear the values
aren't changing.    Providing a small script that shows the problem is
always beneficial here -- we don't know where the output you've sent
is coming from.

It appears your initial values are all close to zero -- is that
correct?  What if you change the initial values to small random
numbers?

>   * I set the "diag" parameter to [0.1, 0.1, 0.1, 1000, 500, 500, 0.1,
> 0.1, 0.01, 0.01, 0.01, 0.01], which roughly corresponds to the order
> of magnitude of my X values. Should that help the optimizer?

I think so, but I believe it should not be necessary in most cases.
Have you tried not using it?

>   * Can leastsq work well on higher floating point precisions (i.e.
> numpy.float128)? What is the underlying precision of the MINPACK
> libraries?

I believe the answer is No, everything is done at double precision.

Cheers,

--Matt Newville


From a.klein at science-applied.nl  Tue Oct 29 07:22:25 2013
From: a.klein at science-applied.nl (Almar Klein)
Date: Tue, 29 Oct 2013 12:22:25 +0100
Subject: [SciPy-User] ANN: IEP 3.3 - the Interactive Editor for Python
Message-ID: <CAB_T6=m91Dir3eCJCR5MLqiwLSAPHCeJYuT0HxYvxJqkPEr=4A@mail.gmail.com>

Dear all,

We're pleased to announce version 3.3 of the Interactive Editor for Python.
IEP <http://www.iep-project.org> is a cross-platform Python IDE aimed at
interactivity and introspection. Its practical design is aimed at
simplicity and efficiency. IEP consists of an *editor*, a *shell*, and a
set of *tools* to help the programmer in various ways.

Binaries are available for Windows, Linux, and Mac.

A selection of the changes since the last release:

   - Debugging with breakpoints!
   - New magic commands for package management: pip and conda
   - The binaries for Linux are now build without -gtkstyle, making them
   look better or worse, depending on your OS. See release notes for more
   info.
   - Qt backend now runs in native event loop
   - Translations for Russian (in addition to Spanish, Catalan, French and
   Dutch)
   - We have a new website and logo

Website: http;//iep-project.org
Discussion group: http://groups.google.com/group/iep_
Release notes: https://bitbucket.org/iep-project/iep/wiki/Release%20notes

Happy coding!

- Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131029/15788fc6/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-User] 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.scipy.org/pipermail/scipy-user/attachments/20131030/39e4d860/attachment.html>

From francois-xavier.thomas at airinov.fr  Thu Oct 31 04:11:19 2013
From: francois-xavier.thomas at airinov.fr (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Thomas?=)
Date: Thu, 31 Oct 2013 08:11:19 -0000
Subject: [SciPy-User] SciPy leastsq behavior
In-Reply-To: <CA+7ESbqvfHew0-sZbTzZbx84bBpWDv0dJcYXYs=fW5FbvYhZDQ@mail.gmail.com>
References: <CAEwRaO7x1P4Ho5mUUGzfR1bO3MUVkJ3A2HiiZRWrpw=g9V2+Qw@mail.gmail.com>
	<CA+7ESbqvfHew0-sZbTzZbx84bBpWDv0dJcYXYs=fW5FbvYhZDQ@mail.gmail.com>
Message-ID: <CAEwRaO6PZvV+Am-bv9=ZCd1Cd7Q0mB_mWZeB_UG6ALVhBPd2uQ@mail.gmail.com>

Hi Matt!

On Mon, Oct 28, 2013 at 3:48 PM, Matt Newville
<newville at cars.uchicago.edu>wrote:

> Hi Francois-Xavier,
>
> I'm not sure I can answer all your questions correctly but....
>
> On Wed, Oct 16, 2013 at 12:24 PM, Fran?ois-Xavier Thomas
> <francois-xavier.thomas at airinov.fr> wrote:
> > Hi all,
> >
> > I am trying to debug precision errors in an optimization process using
> > ScipPy's leastsq method.
> >
> > Attached is a log of the start of the optimization process, showing
> > mean errors and differences between consecutive X values for each f(X)
> > call.
> >
> >   * Why is f(X) computed even though X hasn't moved at all? Did I miss
> > something obvious?
>
> The objective function will be called many times to compute the
> Jacobian with values varying at the level of machine tolerance.
> Depending on how you print out the values, it may appear the values
> aren't changing.    Providing a small script that shows the problem is
> always beneficial here -- we don't know where the output you've sent
> is coming from.
>

Unfortunately I won't be able to provide the source code. I'll see if I can
make a small, self-contained example.

I'm using the "format" method to print strings, and they do appear to have
full precision (~15 digits). Is there a better way to print them?
As a workaround, is there a way to print the binary representation of my
numbers?

It appears your initial values are all close to zero -- is that
> correct?  What if you change the initial values to small random
> numbers?
>

No, the initial values are not close to zero. The "dX" values shown are the
differences between the last step and the current step. It's easier to see
what changed this way.


> >   * I set the "diag" parameter to [0.1, 0.1, 0.1, 1000, 500, 500, 0.1,
> > 0.1, 0.01, 0.01, 0.01, 0.01], which roughly corresponds to the order
> > of magnitude of my X values. Should that help the optimizer?
>
> I think so, but I believe it should not be necessary in most cases.
> Have you tried not using it?
>

I didn't see any difference, but I tried to explore every possibility.


> >   * Can leastsq work well on higher floating point precisions (i.e.
> > numpy.float128)? What is the underlying precision of the MINPACK
> > libraries?
>
> I believe the answer is No, everything is done at double precision.
>

That's what I thought. Oh, well. It _should_ work in 64-bit only, there's
probably no need to go that far.

Thanks for taking the time to answer though!

Cheers,
Fran?ois-Xavier

-- 
Fran?ois-Xavier Thomas -- Image Processing

AIRINOV
Incubateur PRINE
110 rue des Poissonniers -  48 voie CI18
75899 Paris Cedex 18
09 72 39 75 82
www.airinov.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131031/a8c8313d/attachment.html>

From robertwb at gmail.com  Thu Oct 31 23:15:39 2013
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 01 Nov 2013 03:15:39 -0000
Subject: [SciPy-User] [cython-users] scipy and cython
In-Reply-To: <9ebdf9c6-06ed-4e95-ac42-21024ca59c86@googlegroups.com>
References: <bf668734-da2e-45cc-938a-477b7144a6bf@googlegroups.com>
	<CADiQ+QDWA6MOKgXQXEhegxYi=4NVx1vBdzx2cN3yfJp15viCyw@mail.gmail.com>
	<9ebdf9c6-06ed-4e95-ac42-21024ca59c86@googlegroups.com>
Message-ID: <CADiQ+QCmBhe5FT1xM0sa2LvmWWfiiFxNBx4EJO-j+tXNcRQkmw@mail.gmail.com>

On Fri, Oct 25, 2013 at 6:13 PM, Menchyshyn Oleh
<oleh.menchyshyn at gmail.com> wrote:
> I am trying to use SciPy and Cython combination but with a little success. I
> know about huge optimization gain when using vectorized versions of
> algorithms based on NumPy, but I guess my problem depends on NumPy
> implicitly only, through 3D integration routine. My bottleneck is Python's
> function overhead passing many times to scipy.integrate.tplquad in the cycle
> of the scipy.optimize.fmin when searching for the roots of a set of
> non-linear equations.
>
> My question is: Is it possible to pass to SciPy's routines non-PyObjects? I
> read on the Stackoverflow that there were some thoughts about implementing
> those issues.
>
> I tried other non-Python libraries for integrating and roots finding of
> non-lineaer sets of equations. But combining interfaces of different libs in
> C++ is error-prone and tedious sometime. I miss simplicity and readability
> of Python much. Please help me, maybe I just don't get something right with
> Cython+SciPy way

If SciPy doesn't expose a C API, then you have to call it via the
Python API, which could very well be a bottleneck. If it does, then
you can call it like any other C library.

- Robert