From cimrman3 at ntc.zcu.cz  Mon Mar  1 12:20:36 2010
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Mon, 01 Mar 2010 18:20:36 +0100
Subject: [SciPy-Dev] ANN: SfePy 2010.1
Message-ID: <4B8BF764.5080305@ntc.zcu.cz>

I am pleased to announce release 2010.1 of SfePy.

Description
-----------

SfePy (simple finite elements in Python) is a software for solving systems of 
coupled partial differential equations by the finite element method. The code 
is based on NumPy and SciPy packages. It is distributed under the new BSD license.

Mailing lists, issue tracking, git repository: http://sfepy.org
Home page: http://sfepy.kme.zcu.cz

Documentation: http://docs.sfepy.org/doc

Contributors to this release: Vladim?r Luke?, Logan Sorenson.

Highlights of this release
--------------------------
- new sphinx-based documentation
- refactoring of base functions (polynomial spaces) and element geometry 
description
- interpolation between different meshes
- terms for describing perfusion and active fibres in the total Lagrangian 
formulation (applicable, for example, to active muscle tissue models)

Major improvements
------------------
Apart from many bug-fixes, let us mention:
- data probing:
   - automatic refinement of probe points, speed-up
- postprocessing and visualization:
   - VTK source construction for any format supported by MeshIO classes:
     - this means displaying meshes in formats Mayavi knows nothing about
- graphical logging:
   - support logging to a text file, vertical line plot, allow several Log 
instances
- new examples:
   - application of the theory of homogenization to elasticity
   - perfusion, active fibres
- new tests and many new terms

For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/2010.1_RELEASE_NOTES.txt
(full release notes, rather long).

Best regards,
Robert Cimrman


From d.l.goldsmith at gmail.com  Wed Mar  3 03:28:55 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Wed, 3 Mar 2010 00:28:55 -0800
Subject: [SciPy-Dev] N.angle(nan)
Message-ID: <45d1ab481003030028y4bd3bb61j56a51db732c26a12@mail.gmail.com>

Hi!  N.angle(z) returns nan if either z.real or z.imag is nan; presently,
this is not documented in its docstring, but it is traceable to the
low-level c functions N.angle uses to do its work, so I'm assuming it's a
bug in the doc, not in the code, i.e., is intended behavior, correct?

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100303/815a5ac3/attachment.html>

From ralf.gommers at googlemail.com  Wed Mar  3 09:14:37 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 3 Mar 2010 22:14:37 +0800
Subject: [SciPy-Dev] build issue on OS X 10.6 - fails on fftpack
In-Reply-To: <4B8B2E65.1030708@silveregg.co.jp>
References: <dde7764a1002270602h3aea67cdo2e0cc9922349a261@mail.gmail.com>
	<4B8B1D65.107@silveregg.co.jp>
	<dde7764a1002281856h7c3b621fs172100803e0b6b4@mail.gmail.com>
	<4B8B2E65.1030708@silveregg.co.jp>
Message-ID: <dde7764a1003030614gad04296sb6ba533dcf60a27d@mail.gmail.com>

On Mon, Mar 1, 2010 at 11:03 AM, David Cournapeau <david at silveregg.co.jp>wrote:

> Ralf Gommers wrote:
> >
> >
> > On Mon, Mar 1, 2010 at 9:50 AM, David Cournapeau <david at silveregg.co.jp
> > <mailto:david at silveregg.co.jp>> wrote:
> >
> >     Ralf Gommers wrote:
> >
> >      > $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
> >
> >     Whenever you redefine one of the CFLAGS/FFLAGS/CXXFLAGS/LDFLAGS, it
> >     *overwrites* the default value (contrary to the usual behavior of
> having
> >     its value appended to the default value).
> >
> >
> > I followed the instructions under "Obtaining and Building NumPy and
> > SciPy on this page: http://www.scipy.org/Installing_SciPy/Mac_OS_X .
> > There it says that the above command *extends* the build flags. So that
> > info is wrong? Or maybe I'm still not understanding something.
>
> Both are true :) If you build with numscons, then the flags are
> extended. If you build with distutils, the flags are overriden.
>
> The wiki could be made clearer there.
>

When everything works for me I'll update the wiki. But first some more
questions.

This command:
$ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
setupscons.py scons --package=scipy.linalg
fails:
Checking for ACCELERATE ... no
Checking for ATLAS ... no
Checking for MKL ... no
Checking for CBLAS ... (cached) no
Checking for CLAPACK ... (cached) no

But without trying to extend the flags:
$ python setupscons.py scons --package=scipy.linalg
it works:
Checking for ACCELERATE ... yes
Checking for CBLAS ... yes - ACCELERATE
Checking for CLAPACK ... (cached) no
Checking gfortran C compatibility runtime
...-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3
-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../.. -lgfortranbegin
-lgfortran
Checking if gfortran needs dummy main - MAIN__.
Checking gfortran name mangling - '_', '', lower-case.
Checking for ACCELERATE ... yes
Checking for F77 BLAS ... yes - ACCELERATE
Checking for ACCELERATE ... yes
Checking for F77 LAPACK ... yes - ACCELERATE


Any idea what is going on here? I'm using numscons 0.12.0, last commit is
76db80c1413d0b8f73761de713797355c7ccf4c0.

The extra flags are needed on SL, since if I build without them:
$ python setupscons.py scons -i
then the build finishes and I can import scipy, but running the test suite
gives a lot of errors like this:
ImportError: dlopen(/Users/rgommers/Code/scipy/_csr.so, 2): no suitable
image found.  Did find:
    /Users/rgommers/Code/scipy/_csr.so: mach-o, but wrong architecture




> >
> >
> >     here, by overwriting LDFLAGS, you remove all the link options
> necessary
> >     to build a bundle, and the linker believes you want to build an
> >     executable (hence the missing main symbol message, and all the
> >     unresolved symbols from libpython.dylib).
> >
> >
> > To be clear, I'm just trying to build scipy on my own machine
>
> The flag issue is a distutils issue, and happens whenever you call
> setup.py. You should not try to edit flags if you build with distutils,
> really - the overriding support implies that it should be used as last
> resort, and otherwise, everything should be handled within distutils.
>
> So is there an easy way to build scipy on SL with distutils, or should I
just stick to numscons if I get that to work?

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100303/712f7dac/attachment.html>

From robert.kern at gmail.com  Wed Mar  3 10:43:01 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 3 Mar 2010 09:43:01 -0600
Subject: [SciPy-Dev] N.angle(nan)
In-Reply-To: <45d1ab481003030028y4bd3bb61j56a51db732c26a12@mail.gmail.com>
References: <45d1ab481003030028y4bd3bb61j56a51db732c26a12@mail.gmail.com>
Message-ID: <3d375d731003030743h6251076cmf384dd532afb9da1@mail.gmail.com>

On Wed, Mar 3, 2010 at 02:28, David Goldsmith <d.l.goldsmith at gmail.com> wrote:
> Hi!? N.angle(z) returns nan if either z.real or z.imag is nan; presently,
> this is not documented in its docstring, but it is traceable to the
> low-level c functions N.angle uses to do its work, so I'm assuming it's a
> bug in the doc, not in the code, i.e., is intended behavior, correct?

It is intended behavior. I'm not sure it *needs* to be documented or
that it's a doc bug that it isn't explicitly mentioned. If we were
explicit about every time an input containing a NaN generates a NaN in
the output, we would document nothing else. I would think this
behavior is obvious once you know how NaNs usually work.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d.l.goldsmith at gmail.com  Wed Mar  3 11:39:04 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Wed, 3 Mar 2010 08:39:04 -0800
Subject: [SciPy-Dev] N.angle(nan)
In-Reply-To: <3d375d731003030743h6251076cmf384dd532afb9da1@mail.gmail.com>
References: <45d1ab481003030028y4bd3bb61j56a51db732c26a12@mail.gmail.com>
	<3d375d731003030743h6251076cmf384dd532afb9da1@mail.gmail.com>
Message-ID: <45d1ab481003030839p601db97fk1adcdc4d193679b4@mail.gmail.com>

On Wed, Mar 3, 2010 at 7:43 AM, Robert Kern <robert.kern at gmail.com> wrote:

> On Wed, Mar 3, 2010 at 02:28, David Goldsmith <d.l.goldsmith at gmail.com>
> wrote:
> > Hi!  N.angle(z) returns nan if either z.real or z.imag is nan; presently,
> > this is not documented in its docstring, but it is traceable to the
> > low-level c functions N.angle uses to do its work, so I'm assuming it's a
> > bug in the doc, not in the code, i.e., is intended behavior, correct?
>
> It is intended behavior. I'm not sure it *needs* to be documented or
> that it's a doc bug that it isn't explicitly mentioned. If we were
> explicit about every time an input containing a NaN generates a NaN in
> the output, we would document nothing else. I would think this
> behavior is obvious once you know how NaNs usually work.
>

I thought you would say something like that.

DG


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100303/f9d4e237/attachment.html>

From robert.kern at gmail.com  Wed Mar  3 12:18:30 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 3 Mar 2010 11:18:30 -0600
Subject: [SciPy-Dev] N.angle(nan)
In-Reply-To: <45d1ab481003030839p601db97fk1adcdc4d193679b4@mail.gmail.com>
References: <45d1ab481003030028y4bd3bb61j56a51db732c26a12@mail.gmail.com> 
	<3d375d731003030743h6251076cmf384dd532afb9da1@mail.gmail.com> 
	<45d1ab481003030839p601db97fk1adcdc4d193679b4@mail.gmail.com>
Message-ID: <3d375d731003030918n1b3f6a1am1147082f6bc2d280@mail.gmail.com>

On Wed, Mar 3, 2010 at 10:39, David Goldsmith <d.l.goldsmith at gmail.com> wrote:
> On Wed, Mar 3, 2010 at 7:43 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Wed, Mar 3, 2010 at 02:28, David Goldsmith <d.l.goldsmith at gmail.com>
>> wrote:
>> > Hi!? N.angle(z) returns nan if either z.real or z.imag is nan;
>> > presently,
>> > this is not documented in its docstring, but it is traceable to the
>> > low-level c functions N.angle uses to do its work, so I'm assuming it's
>> > a
>> > bug in the doc, not in the code, i.e., is intended behavior, correct?
>>
>> It is intended behavior. I'm not sure it *needs* to be documented or
>> that it's a doc bug that it isn't explicitly mentioned. If we were
>> explicit about every time an input containing a NaN generates a NaN in
>> the output, we would document nothing else. I would think this
>> behavior is obvious once you know how NaNs usually work.
>
> I thought you would say something like that.

I long for the day when I can be replaced by a machine that will
predict the appropriate curmudgeonly response I would give.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From kwgoodman at gmail.com  Wed Mar  3 12:25:54 2010
From: kwgoodman at gmail.com (Keith Goodman)
Date: Wed, 3 Mar 2010 09:25:54 -0800
Subject: [SciPy-Dev] N.angle(nan)
In-Reply-To: <3d375d731003030918n1b3f6a1am1147082f6bc2d280@mail.gmail.com>
References: <45d1ab481003030028y4bd3bb61j56a51db732c26a12@mail.gmail.com>
	<3d375d731003030743h6251076cmf384dd532afb9da1@mail.gmail.com>
	<45d1ab481003030839p601db97fk1adcdc4d193679b4@mail.gmail.com>
	<3d375d731003030918n1b3f6a1am1147082f6bc2d280@mail.gmail.com>
Message-ID: <f4f93d421003030925p7cd7d294u7be234bf48ea7eba@mail.gmail.com>

On Wed, Mar 3, 2010 at 9:18 AM, Robert Kern <robert.kern at gmail.com> wrote:
> I long for the day when I can be replaced by a machine that will
> predict the appropriate curmudgeonly response I would give.

The curmudgeonly Turing test (Kern test)?


From D.J.Baker at soton.ac.uk  Thu Mar  4 07:41:29 2010
From: D.J.Baker at soton.ac.uk (Baker D.J.)
Date: Thu, 4 Mar 2010 12:41:29 +0000
Subject: [SciPy-Dev] FW: Scipy failing -- undefined symbol:
	_ZNSt8ios_base4InitD1Ev
Message-ID: <E117AD245282BA48ABE1E16E9712070C956D512789@UOS-CL-EX7-L3.soton.ac.uk>

 
Hello,

I'm just wondering if anyone on this mailing list can help, please. I've just installed scipy on our Linux x86_64 machine using the Intel compilers and MKL. All is not well, however, since when I try to use scipy, for example...

from scipy import linsolve, sparse

I find that there is an unresolved symbol. That is, _ZNSt8ios_base4InitD1Ev. Using c++filt would appear to suggest that I need to add "-lstdc++" to my loader command. 

c++filt _ZNSt8ios_base4InitD1Ev
std::ios_base::Init::~Init()

I'm new to numpy and scipy, and so I'm working in the dark to some degree. I've tried modifying intelccompiler.py in the following way, and recompiling numpy and scipy (the idea being that some of the programs in the scipy build are cxx files)

    compiler_type = 'intel'
    cc_exe = 'icc -O3 -fPIC'
    cxx_exe = 'icpc -O3 -fPIC'
    def __init__ (self, verbose=0, dry_run=0, force=0):
        UnixCCompiler.__init__ (self, verbose,dry_run, force)
        compiler = self.cc_exe
        compiler_cxx = self.cxx_exe
        self.set_executables(compiler=compiler,
                             compiler_so=compiler,
                             compiler_cxx=compiler_cxx,
                             linker_exe=compiler,
                             linker_so=compiler_cxx + ' -shared -lstdc++')

I rebuild scipy using the following command, however the above hasn't helped:

python setup.py config --compiler=intel config_fc --fcompiler=intelem  install --prefix=/local/software/rh53/scipy/0.7.1/intel

Could someone please advise me how to ensure that the "-lstdc++" is successfully passed to the linker as and when I build scipy. This would really be appreciated.

Best -- David.

From oscar.bristol at googlemail.com  Thu Mar  4 08:06:34 2010
From: oscar.bristol at googlemail.com (Oscar Benjamin)
Date: Thu, 04 Mar 2010 13:06:34 +0000
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
Message-ID: <4B8FB05A.102@googlemail.com>

Hi,

I've just discovered that a program of mine (which works on my ubuntu 
karmic machine at home) segfaults on win32 at work.

I've made a short test case:

 > #!/usr/bin/env python
 >
 > from numpy import ones
 > from scipy.signal import lfilter
 >
 > x = ones(100)
 > a = ones(5)
 > b = ones(5)
 > zi = ones(4)
 > #xf = lfilter(b, a, x)
 > xf, zf = lfilter(b, a, x, zi=zi)

Swap the comment on the last two lines to prevent segfault. On my 
machine I get the "Unhandled Exception in python.exe" message box (I 
assume this is a segfault).
versions:
python 2.6.4
numpy 1.3.0
scipy 0.7.1

I can see a few tickets about problems with memory leaks and segfaults 
with lfilter but they seem to be old and marked as closed. Should I 
expect the above to work? Is this a known issue that's already fixed?

Thanks,
Oscar.



From josef.pktd at gmail.com  Thu Mar  4 08:28:29 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 08:28:29 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <4B8FB05A.102@googlemail.com>
References: <4B8FB05A.102@googlemail.com>
Message-ID: <1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com>

On Thu, Mar 4, 2010 at 8:06 AM, Oscar Benjamin
<oscar.bristol at googlemail.com> wrote:
> Hi,
>
> I've just discovered that a program of mine (which works on my ubuntu
> karmic machine at home) segfaults on win32 at work.
>
> I've made a short test case:
>
> ?> #!/usr/bin/env python
> ?>
> ?> from numpy import ones
> ?> from scipy.signal import lfilter
> ?>
> ?> x = ones(100)
> ?> a = ones(5)
> ?> b = ones(5)
> ?> zi = ones(4)
> ?> #xf = lfilter(b, a, x)
> ?> xf, zf = lfilter(b, a, x, zi=zi)
>
> Swap the comment on the last two lines to prevent segfault. On my
> machine I get the "Unhandled Exception in python.exe" message box (I
> assume this is a segfault).
> versions:
> python 2.6.4
> numpy 1.3.0
> scipy 0.7.1
>
> I can see a few tickets about problems with memory leaks and segfaults
> with lfilter but they seem to be old and marked as closed. Should I
> expect the above to work? Is this a known issue that's already fixed?

I don't have a segfault or any other problem with your script on
WindowsXP with python 2.5.2. numpy 1.4.0 and a scipy from a while ago.
>>> numpy.version.version
'1.4.0'
>>> scipy.version.version
'0.8.0.dev6156'

I also think I never had a segfault before with lfilter, and I have
been using it for quite some time.
(The only segfault I have seen is when scipy is not binary compatible
with numpy 1.4.0)

Are your numpy and scipy from the official installers?

I don't know if there were any problems with python 2.6 before.

Josef

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


From oscar.bristol at googlemail.com  Thu Mar  4 09:29:39 2010
From: oscar.bristol at googlemail.com (Oscar Benjamin)
Date: Thu, 04 Mar 2010 14:29:39 +0000
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com>
Message-ID: <4B8FC3D3.5060402@googlemail.com>

Hi,

It seems this was just a problem with my installation somehow. Before 
sending the previous email I had uninstalled and reinstalled both numpy 
and scipy and the problem remained. I've just got back from lunch and 
rebooted, uninstalled and reinstalled both again (using the same 
installer files) and the problem seems now to be fixed. I'm not really 
sure what happened there.

Thanks for your help,
Oscar.

josef.pktd at gmail.com wrote:
> On Thu, Mar 4, 2010 at 8:06 AM, Oscar Benjamin
> <oscar.bristol at googlemail.com> wrote:
>   
>> Hi,
>>
>> I've just discovered that a program of mine (which works on my ubuntu
>> karmic machine at home) segfaults on win32 at work.
>>
>> I've made a short test case:
>>
>>  > #!/usr/bin/env python
>>  >
>>  > from numpy import ones
>>  > from scipy.signal import lfilter
>>  >
>>  > x = ones(100)
>>  > a = ones(5)
>>  > b = ones(5)
>>  > zi = ones(4)
>>  > #xf = lfilter(b, a, x)
>>  > xf, zf = lfilter(b, a, x, zi=zi)
>>
>> Swap the comment on the last two lines to prevent segfault. On my
>> machine I get the "Unhandled Exception in python.exe" message box (I
>> assume this is a segfault).
>> versions:
>> python 2.6.4
>> numpy 1.3.0
>> scipy 0.7.1
>>
>> I can see a few tickets about problems with memory leaks and segfaults
>> with lfilter but they seem to be old and marked as closed. Should I
>> expect the above to work? Is this a known issue that's already fixed?
>>     
>
> I don't have a segfault or any other problem with your script on
> WindowsXP with python 2.5.2. numpy 1.4.0 and a scipy from a while ago.
>   
>>>> numpy.version.version
>>>>         
> '1.4.0'
>   
>>>> scipy.version.version
>>>>         
> '0.8.0.dev6156'
>
> I also think I never had a segfault before with lfilter, and I have
> been using it for quite some time.
> (The only segfault I have seen is when scipy is not binary compatible
> with numpy 1.4.0)
>
> Are your numpy and scipy from the official installers?
>
> I don't know if there were any problems with python 2.6 before.
>
> Josef
>
>   
>> Thanks,
>> Oscar.
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>     
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>   



From josef.pktd at gmail.com  Thu Mar  4 09:39:52 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 09:39:52 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <4B8FC3D3.5060402@googlemail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com>
	<4B8FC3D3.5060402@googlemail.com>
Message-ID: <1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>

On Thu, Mar 4, 2010 at 9:29 AM, Oscar Benjamin
<oscar.bristol at googlemail.com> wrote:
> Hi,
>
> It seems this was just a problem with my installation somehow. Before
> sending the previous email I had uninstalled and reinstalled both numpy
> and scipy and the problem remained. I've just got back from lunch and
> rebooted, uninstalled and reinstalled both again (using the same
> installer files) and the problem seems now to be fixed. I'm not really
> sure what happened there.

good to hear,
It is easy to get some left-over files from a previous install that
create problems.

Josef

>
> Thanks for your help,
> Oscar.
>
> josef.pktd at gmail.com wrote:
>> On Thu, Mar 4, 2010 at 8:06 AM, Oscar Benjamin
>> <oscar.bristol at googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> I've just discovered that a program of mine (which works on my ubuntu
>>> karmic machine at home) segfaults on win32 at work.
>>>
>>> I've made a short test case:
>>>
>>> ?> #!/usr/bin/env python
>>> ?>
>>> ?> from numpy import ones
>>> ?> from scipy.signal import lfilter
>>> ?>
>>> ?> x = ones(100)
>>> ?> a = ones(5)
>>> ?> b = ones(5)
>>> ?> zi = ones(4)
>>> ?> #xf = lfilter(b, a, x)
>>> ?> xf, zf = lfilter(b, a, x, zi=zi)
>>>
>>> Swap the comment on the last two lines to prevent segfault. On my
>>> machine I get the "Unhandled Exception in python.exe" message box (I
>>> assume this is a segfault).
>>> versions:
>>> python 2.6.4
>>> numpy 1.3.0
>>> scipy 0.7.1
>>>
>>> I can see a few tickets about problems with memory leaks and segfaults
>>> with lfilter but they seem to be old and marked as closed. Should I
>>> expect the above to work? Is this a known issue that's already fixed?
>>>
>>
>> I don't have a segfault or any other problem with your script on
>> WindowsXP with python 2.5.2. numpy 1.4.0 and a scipy from a while ago.
>>
>>>>> numpy.version.version
>>>>>
>> '1.4.0'
>>
>>>>> scipy.version.version
>>>>>
>> '0.8.0.dev6156'
>>
>> I also think I never had a segfault before with lfilter, and I have
>> been using it for quite some time.
>> (The only segfault I have seen is when scipy is not binary compatible
>> with numpy 1.4.0)
>>
>> Are your numpy and scipy from the official installers?
>>
>> I don't know if there were any problems with python 2.6 before.
>>
>> Josef
>>
>>
>>> Thanks,
>>> Oscar.
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From arokem at berkeley.edu  Thu Mar  4 13:37:59 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Thu, 4 Mar 2010 10:37:59 -0800
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com> 
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>
Message-ID: <43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>

This is off-topic, but since the problem seems to have been solved, I'll go
ahead and ask: How do you get the revision number in your version number?

All I get is:

In [3]: scipy.version.version
Out[3]: '0.8.0.dev'

Thanks - Ariel

On Thu, Mar 4, 2010 at 6:39 AM, <josef.pktd at gmail.com> wrote:

> On Thu, Mar 4, 2010 at 9:29 AM, Oscar Benjamin
> <oscar.bristol at googlemail.com> wrote:
> > Hi,
> >
> > It seems this was just a problem with my installation somehow. Before
> > sending the previous email I had uninstalled and reinstalled both numpy
> > and scipy and the problem remained. I've just got back from lunch and
> > rebooted, uninstalled and reinstalled both again (using the same
> > installer files) and the problem seems now to be fixed. I'm not really
> > sure what happened there.
>
> good to hear,
> It is easy to get some left-over files from a previous install that
> create problems.
>
> Josef
>
> >
> > Thanks for your help,
> > Oscar.
> >
> > josef.pktd at gmail.com wrote:
> >> On Thu, Mar 4, 2010 at 8:06 AM, Oscar Benjamin
> >> <oscar.bristol at googlemail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> I've just discovered that a program of mine (which works on my ubuntu
> >>> karmic machine at home) segfaults on win32 at work.
> >>>
> >>> I've made a short test case:
> >>>
> >>>  > #!/usr/bin/env python
> >>>  >
> >>>  > from numpy import ones
> >>>  > from scipy.signal import lfilter
> >>>  >
> >>>  > x = ones(100)
> >>>  > a = ones(5)
> >>>  > b = ones(5)
> >>>  > zi = ones(4)
> >>>  > #xf = lfilter(b, a, x)
> >>>  > xf, zf = lfilter(b, a, x, zi=zi)
> >>>
> >>> Swap the comment on the last two lines to prevent segfault. On my
> >>> machine I get the "Unhandled Exception in python.exe" message box (I
> >>> assume this is a segfault).
> >>> versions:
> >>> python 2.6.4
> >>> numpy 1.3.0
> >>> scipy 0.7.1
> >>>
> >>> I can see a few tickets about problems with memory leaks and segfaults
> >>> with lfilter but they seem to be old and marked as closed. Should I
> >>> expect the above to work? Is this a known issue that's already fixed?
> >>>
> >>
> >> I don't have a segfault or any other problem with your script on
> >> WindowsXP with python 2.5.2. numpy 1.4.0 and a scipy from a while ago.
> >>
> >>>>> numpy.version.version
> >>>>>
> >> '1.4.0'
> >>
> >>>>> scipy.version.version
> >>>>>
> >> '0.8.0.dev6156'
> >>
> >> I also think I never had a segfault before with lfilter, and I have
> >> been using it for quite some time.
> >> (The only segfault I have seen is when scipy is not binary compatible
> >> with numpy 1.4.0)
> >>
> >> Are your numpy and scipy from the official installers?
> >>
> >> I don't know if there were any problems with python 2.6 before.
> >>
> >> Josef
> >>
> >>
> >>> Thanks,
> >>> Oscar.
> >>>
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>>
> >>>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >>
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100304/a4fa5092/attachment.html>

From josef.pktd at gmail.com  Thu Mar  4 13:47:41 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 13:47:41 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com>
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
Message-ID: <1cd32cbb1003041047t64918256mf3864d31868fdf72@mail.gmail.com>

On Thu, Mar 4, 2010 at 1:37 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> This is off-topic, but since the problem seems to have been solved, I'll go
> ahead and ask: How do you get the revision number in your version number?
>
> All I get is:
>
> In [3]: scipy.version.version
> Out[3]: '0.8.0.dev'

I think because I was building scipy from the svn checkout. If I
remember correctly, setup.py looks for the svn revision number.

Josef


>
> Thanks - Ariel
>
> On Thu, Mar 4, 2010 at 6:39 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Thu, Mar 4, 2010 at 9:29 AM, Oscar Benjamin
>> <oscar.bristol at googlemail.com> wrote:
>> > Hi,
>> >
>> > It seems this was just a problem with my installation somehow. Before
>> > sending the previous email I had uninstalled and reinstalled both numpy
>> > and scipy and the problem remained. I've just got back from lunch and
>> > rebooted, uninstalled and reinstalled both again (using the same
>> > installer files) and the problem seems now to be fixed. I'm not really
>> > sure what happened there.
>>
>> good to hear,
>> It is easy to get some left-over files from a previous install that
>> create problems.
>>
>> Josef
>>
>> >
>> > Thanks for your help,
>> > Oscar.
>> >
>> > josef.pktd at gmail.com wrote:
>> >> On Thu, Mar 4, 2010 at 8:06 AM, Oscar Benjamin
>> >> <oscar.bristol at googlemail.com> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I've just discovered that a program of mine (which works on my ubuntu
>> >>> karmic machine at home) segfaults on win32 at work.
>> >>>
>> >>> I've made a short test case:
>> >>>
>> >>> ?> #!/usr/bin/env python
>> >>> ?>
>> >>> ?> from numpy import ones
>> >>> ?> from scipy.signal import lfilter
>> >>> ?>
>> >>> ?> x = ones(100)
>> >>> ?> a = ones(5)
>> >>> ?> b = ones(5)
>> >>> ?> zi = ones(4)
>> >>> ?> #xf = lfilter(b, a, x)
>> >>> ?> xf, zf = lfilter(b, a, x, zi=zi)
>> >>>
>> >>> Swap the comment on the last two lines to prevent segfault. On my
>> >>> machine I get the "Unhandled Exception in python.exe" message box (I
>> >>> assume this is a segfault).
>> >>> versions:
>> >>> python 2.6.4
>> >>> numpy 1.3.0
>> >>> scipy 0.7.1
>> >>>
>> >>> I can see a few tickets about problems with memory leaks and segfaults
>> >>> with lfilter but they seem to be old and marked as closed. Should I
>> >>> expect the above to work? Is this a known issue that's already fixed?
>> >>>
>> >>
>> >> I don't have a segfault or any other problem with your script on
>> >> WindowsXP with python 2.5.2. numpy 1.4.0 and a scipy from a while ago.
>> >>
>> >>>>> numpy.version.version
>> >>>>>
>> >> '1.4.0'
>> >>
>> >>>>> scipy.version.version
>> >>>>>
>> >> '0.8.0.dev6156'
>> >>
>> >> I also think I never had a segfault before with lfilter, and I have
>> >> been using it for quite some time.
>> >> (The only segfault I have seen is when scipy is not binary compatible
>> >> with numpy 1.4.0)
>> >>
>> >> Are your numpy and scipy from the official installers?
>> >>
>> >> I don't know if there were any problems with python 2.6 before.
>> >>
>> >> Josef
>> >>
>> >>
>> >>> Thanks,
>> >>> Oscar.
>> >>>
>> >>> _______________________________________________
>> >>> SciPy-Dev mailing list
>> >>> SciPy-Dev at scipy.org
>> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >>>
>> >>>
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From jsseabold at gmail.com  Thu Mar  4 13:49:09 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Thu, 4 Mar 2010 13:49:09 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com> 
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com> 
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
Message-ID: <c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>

On Thu, Mar 4, 2010 at 1:37 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> This is off-topic, but since the problem seems to have been solved, I'll go
> ahead and ask: How do you get the revision number in your version number?
>
> All I get is:
>
> In [3]: scipy.version.version
> Out[3]: '0.8.0.dev'
>

In [5]: scipy.version.svn.version
Out[5]: '6251'

In [6]: scipy.__version__
Out[6]: '0.8.0.dev6251'


From arokem at berkeley.edu  Thu Mar  4 13:53:33 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Thu, 4 Mar 2010 10:53:33 -0800
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com> 
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com> 
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com> 
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>
Message-ID: <43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>

Hi Skipper - thanks!

When I try that, I get:


In [4]: scipy.version.svn.version
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/Users/arokem/<ipython console> in <module>()

AttributeError: 'module' object has no attribute 'svn'

In [5]: scipy.__version__
Out[5]: '0.8.0.dev'



On Thu, Mar 4, 2010 at 10:49 AM, Skipper Seabold <jsseabold at gmail.com>wrote:

> On Thu, Mar 4, 2010 at 1:37 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> > This is off-topic, but since the problem seems to have been solved, I'll
> go
> > ahead and ask: How do you get the revision number in your version number?
> >
> > All I get is:
> >
> > In [3]: scipy.version.version
> > Out[3]: '0.8.0.dev'
> >
>
> In [5]: scipy.version.svn.version
> Out[5]: '6251'
>
> In [6]: scipy.__version__
> Out[6]: '0.8.0.dev6251'
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100304/6c905b32/attachment.html>

From jsseabold at gmail.com  Thu Mar  4 14:00:02 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Thu, 4 Mar 2010 14:00:02 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com> 
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com> 
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com> 
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com> 
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>
Message-ID: <c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>

On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> Hi Skipper - thanks!
>
> When I try that, I get:
>
>
> In [4]: scipy.version.svn.version
> ---------------------------------------------------------------------------
> AttributeError??????????????????????????? Traceback (most recent call last)
>
> /Users/arokem/<ipython console> in <module>()
>
> AttributeError: 'module' object has no attribute 'svn'
>
> In [5]: scipy.__version__
> Out[5]: '0.8.0.dev'
>

Hmm.  Not sure then.  This is on an Ubuntu Linux install from svn trunk.

Skipper


From arokem at berkeley.edu  Thu Mar  4 14:03:20 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Thu, 4 Mar 2010 11:03:20 -0800
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com> 
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com> 
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com> 
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com> 
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com> 
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>
Message-ID: <43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com>

Yes - I thought I was also building from svn trunk (on a Mac OS 10.5.8).
Will look into that.

Cheers - Ariel

On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold <jsseabold at gmail.com>wrote:

> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> > Hi Skipper - thanks!
> >
> > When I try that, I get:
> >
> >
> > In [4]: scipy.version.svn.version
> >
> ---------------------------------------------------------------------------
> > AttributeError                            Traceback (most recent call
> last)
> >
> > /Users/arokem/<ipython console> in <module>()
> >
> > AttributeError: 'module' object has no attribute 'svn'
> >
> > In [5]: scipy.__version__
> > Out[5]: '0.8.0.dev'
> >
>
> Hmm.  Not sure then.  This is on an Ubuntu Linux install from svn trunk.
>
> Skipper
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100304/1652a0eb/attachment.html>

From josef.pktd at gmail.com  Thu Mar  4 14:14:29 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 14:14:29 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com>
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com>
Message-ID: <1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com>

On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> Yes - I thought I was also building from svn trunk (on a Mac OS 10.5.8).
> Will look into that.
>
> Cheers - Ariel
>
> On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold <jsseabold at gmail.com>
> wrote:
>>
>> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
>> > Hi Skipper - thanks!
>> >
>> > When I try that, I get:
>> >
>> >
>> > In [4]: scipy.version.svn.version
>> >
>> > ---------------------------------------------------------------------------
>> > AttributeError??????????????????????????? Traceback (most recent call
>> > last)
>> >
>> > /Users/arokem/<ipython console> in <module>()
>> >
>> > AttributeError: 'module' object has no attribute 'svn'
>> >
>> > In [5]: scipy.__version__
>> > Out[5]: '0.8.0.dev'
>> >
>>
>> Hmm. ?Not sure then. ?This is on an Ubuntu Linux install from svn trunk.

during build, setup.py calls svn info to to check for the revision
number and writes it to a file __svn_version__.py

This requires a .svn subdirectory, otherwise the revision number check
is skipped.

Josef


>>
>> Skipper
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From arokem at berkeley.edu  Thu Mar  4 14:32:49 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Thu, 4 Mar 2010 11:32:49 -0800
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040528q19e2bf7ck6a86cf045b267672@mail.gmail.com> 
	<4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com> 
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com> 
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com> 
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com> 
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com> 
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com> 
	<1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com>
Message-ID: <43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com>

Hi again - I have now rebuilt scipy from a fresh svn update (r6251), but I
have no file called __svn_version__.py anywhere in the source-tree, as far
as I could tell by grinning for "__svn__". I did originally have EPD
installed, but replaced it with the svn build. Could that be the cause?

Cheers - Ariel


On Thu, Mar 4, 2010 at 11:14 AM, <josef.pktd at gmail.com> wrote:

> On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> > Yes - I thought I was also building from svn trunk (on a Mac OS 10.5.8).
> > Will look into that.
> >
> > Cheers - Ariel
> >
> > On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold <jsseabold at gmail.com>
> > wrote:
> >>
> >> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu>
> wrote:
> >> > Hi Skipper - thanks!
> >> >
> >> > When I try that, I get:
> >> >
> >> >
> >> > In [4]: scipy.version.svn.version
> >> >
> >> >
> ---------------------------------------------------------------------------
> >> > AttributeError                            Traceback (most recent call
> >> > last)
> >> >
> >> > /Users/arokem/<ipython console> in <module>()
> >> >
> >> > AttributeError: 'module' object has no attribute 'svn'
> >> >
> >> > In [5]: scipy.__version__
> >> > Out[5]: '0.8.0.dev'
> >> >
> >>
> >> Hmm.  Not sure then.  This is on an Ubuntu Linux install from svn trunk.
>
> during build, setup.py calls svn info to to check for the revision
> number and writes it to a file __svn_version__.py
>
> This requires a .svn subdirectory, otherwise the revision number check
> is skipped.
>
> Josef
>
>
> >>
> >> Skipper
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > --
> > Ariel Rokem
> > Helen Wills Neuroscience Institute
> > University of California, Berkeley
> > http://argentum.ucbso.berkeley.edu/ariel
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100304/cfc48739/attachment.html>

From josef.pktd at gmail.com  Thu Mar  4 14:38:54 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 14:38:54 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com> <4B8FC3D3.5060402@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com>
	<1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com>
	<43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com>
Message-ID: <1cd32cbb1003041138i1d2480d4o39f1f3154b01c732@mail.gmail.com>

On Thu, Mar 4, 2010 at 2:32 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> Hi again - I have now rebuilt scipy from a fresh svn update (r6251), but I
> have no file called __svn_version__.py anywhere in the source-tree,

__svn_version__.py  is created in the install directory,  and under
build/lib.... but not in the source tree.

does svn info give the right information when you call it from the
directory where your scipy setup.py is?

Josef


as far
> as I could tell by grinning for "__svn__". I did originally have EPD
> installed, but replaced it with the svn build. Could that be the cause?
>
> Cheers - Ariel
>
>
> On Thu, Mar 4, 2010 at 11:14 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
>> > Yes - I thought I was also building from svn trunk (on a Mac OS 10.5.8).
>> > Will look into that.
>> >
>> > Cheers - Ariel
>> >
>> > On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold <jsseabold at gmail.com>
>> > wrote:
>> >>
>> >> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu>
>> >> wrote:
>> >> > Hi Skipper - thanks!
>> >> >
>> >> > When I try that, I get:
>> >> >
>> >> >
>> >> > In [4]: scipy.version.svn.version
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------------
>> >> > AttributeError??????????????????????????? Traceback (most recent call
>> >> > last)
>> >> >
>> >> > /Users/arokem/<ipython console> in <module>()
>> >> >
>> >> > AttributeError: 'module' object has no attribute 'svn'
>> >> >
>> >> > In [5]: scipy.__version__
>> >> > Out[5]: '0.8.0.dev'
>> >> >
>> >>
>> >> Hmm. ?Not sure then. ?This is on an Ubuntu Linux install from svn
>> >> trunk.
>>
>> during build, setup.py calls svn info to to check for the revision
>> number and writes it to a file __svn_version__.py
>>
>> This requires a .svn subdirectory, otherwise the revision number check
>> is skipped.
>>
>> Josef
>>
>>
>> >>
>> >> Skipper
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> > --
>> > Ariel Rokem
>> > Helen Wills Neuroscience Institute
>> > University of California, Berkeley
>> > http://argentum.ucbso.berkeley.edu/ariel
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From josef.pktd at gmail.com  Thu Mar  4 14:40:35 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 14:40:35 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <1cd32cbb1003041138i1d2480d4o39f1f3154b01c732@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<1cd32cbb1003040639i5d914c3fo5a0994fff6ad04ad@mail.gmail.com>
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com>
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com>
	<1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com>
	<43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com>
	<1cd32cbb1003041138i1d2480d4o39f1f3154b01c732@mail.gmail.com>
Message-ID: <1cd32cbb1003041140x4041719bq78b4e23ac0df549e@mail.gmail.com>

On Thu, Mar 4, 2010 at 2:38 PM,  <josef.pktd at gmail.com> wrote:
> On Thu, Mar 4, 2010 at 2:32 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
>> Hi again - I have now rebuilt scipy from a fresh svn update (r6251), but I
>> have no file called __svn_version__.py anywhere in the source-tree,
>
> __svn_version__.py ?is created in the install directory, ?and under
> build/lib.... but not in the source tree.
>
> does svn info give the right information when you call it from the
> directory where your scipy setup.py is?

os.path.exists('.svn')  and is this true (same directory as setup.py)?

>
> Josef
>
>
> as far
>> as I could tell by grinning for "__svn__". I did originally have EPD
>> installed, but replaced it with the svn build. Could that be the cause?
>>
>> Cheers - Ariel
>>
>>
>> On Thu, Mar 4, 2010 at 11:14 AM, <josef.pktd at gmail.com> wrote:
>>>
>>> On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
>>> > Yes - I thought I was also building from svn trunk (on a Mac OS 10.5.8).
>>> > Will look into that.
>>> >
>>> > Cheers - Ariel
>>> >
>>> > On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold <jsseabold at gmail.com>
>>> > wrote:
>>> >>
>>> >> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu>
>>> >> wrote:
>>> >> > Hi Skipper - thanks!
>>> >> >
>>> >> > When I try that, I get:
>>> >> >
>>> >> >
>>> >> > In [4]: scipy.version.svn.version
>>> >> >
>>> >> >
>>> >> > ---------------------------------------------------------------------------
>>> >> > AttributeError??????????????????????????? Traceback (most recent call
>>> >> > last)
>>> >> >
>>> >> > /Users/arokem/<ipython console> in <module>()
>>> >> >
>>> >> > AttributeError: 'module' object has no attribute 'svn'
>>> >> >
>>> >> > In [5]: scipy.__version__
>>> >> > Out[5]: '0.8.0.dev'
>>> >> >
>>> >>
>>> >> Hmm. ?Not sure then. ?This is on an Ubuntu Linux install from svn
>>> >> trunk.
>>>
>>> during build, setup.py calls svn info to to check for the revision
>>> number and writes it to a file __svn_version__.py
>>>
>>> This requires a .svn subdirectory, otherwise the revision number check
>>> is skipped.
>>>
>>> Josef
>>>
>>>
>>> >>
>>> >> Skipper
>>> >> _______________________________________________
>>> >> SciPy-Dev mailing list
>>> >> SciPy-Dev at scipy.org
>>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> >
>>> >
>>> > --
>>> > Ariel Rokem
>>> > Helen Wills Neuroscience Institute
>>> > University of California, Berkeley
>>> > http://argentum.ucbso.berkeley.edu/ariel
>>> >
>>> > _______________________________________________
>>> > SciPy-Dev mailing list
>>> > SciPy-Dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> >
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>> --
>> Ariel Rokem
>> Helen Wills Neuroscience Institute
>> University of California, Berkeley
>> http://argentum.ucbso.berkeley.edu/ariel
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>


From arokem at berkeley.edu  Thu Mar  4 15:13:27 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Thu, 4 Mar 2010 12:13:27 -0800
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <1cd32cbb1003041140x4041719bq78b4e23ac0df549e@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<43958ee61003041037j2a90a871yf0b732204f116c13@mail.gmail.com> 
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com> 
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com> 
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com> 
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com> 
	<1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com> 
	<43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com> 
	<1cd32cbb1003041138i1d2480d4o39f1f3154b01c732@mail.gmail.com> 
	<1cd32cbb1003041140x4041719bq78b4e23ac0df549e@mail.gmail.com>
Message-ID: <43958ee61003041213w7e7cc934h7d5041d5620af85b@mail.gmail.com>

Yes. The '.svn' directory is there (in the same directory as setup.py).


On Thu, Mar 4, 2010 at 11:40 AM, <josef.pktd at gmail.com> wrote:

> On Thu, Mar 4, 2010 at 2:38 PM,  <josef.pktd at gmail.com> wrote:
> > On Thu, Mar 4, 2010 at 2:32 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> >> Hi again - I have now rebuilt scipy from a fresh svn update (r6251), but
> I
> >> have no file called __svn_version__.py anywhere in the source-tree,
> >
> > __svn_version__.py  is created in the install directory,  and under
> > build/lib.... but not in the source tree.
> >
> > does svn info give the right information when you call it from the
> > directory where your scipy setup.py is?
>
> os.path.exists('.svn')  and is this true (same directory as setup.py)?
>
> >
> > Josef
> >
> >
> > as far
> >> as I could tell by grinning for "__svn__". I did originally have EPD
> >> installed, but replaced it with the svn build. Could that be the cause?
> >>
> >> Cheers - Ariel
> >>
> >>
> >> On Thu, Mar 4, 2010 at 11:14 AM, <josef.pktd at gmail.com> wrote:
> >>>
> >>> On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu>
> wrote:
> >>> > Yes - I thought I was also building from svn trunk (on a Mac OS
> 10.5.8).
> >>> > Will look into that.
> >>> >
> >>> > Cheers - Ariel
> >>> >
> >>> > On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold <
> jsseabold at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu>
> >>> >> wrote:
> >>> >> > Hi Skipper - thanks!
> >>> >> >
> >>> >> > When I try that, I get:
> >>> >> >
> >>> >> >
> >>> >> > In [4]: scipy.version.svn.version
> >>> >> >
> >>> >> >
> >>> >> >
> ---------------------------------------------------------------------------
> >>> >> > AttributeError                            Traceback (most recent
> call
> >>> >> > last)
> >>> >> >
> >>> >> > /Users/arokem/<ipython console> in <module>()
> >>> >> >
> >>> >> > AttributeError: 'module' object has no attribute 'svn'
> >>> >> >
> >>> >> > In [5]: scipy.__version__
> >>> >> > Out[5]: '0.8.0.dev'
> >>> >> >
> >>> >>
> >>> >> Hmm.  Not sure then.  This is on an Ubuntu Linux install from svn
> >>> >> trunk.
> >>>
> >>> during build, setup.py calls svn info to to check for the revision
> >>> number and writes it to a file __svn_version__.py
> >>>
> >>> This requires a .svn subdirectory, otherwise the revision number check
> >>> is skipped.
> >>>
> >>> Josef
> >>>
> >>>
> >>> >>
> >>> >> Skipper
> >>> >> _______________________________________________
> >>> >> SciPy-Dev mailing list
> >>> >> SciPy-Dev at scipy.org
> >>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Ariel Rokem
> >>> > Helen Wills Neuroscience Institute
> >>> > University of California, Berkeley
> >>> > http://argentum.ucbso.berkeley.edu/ariel
> >>> >
> >>> > _______________________________________________
> >>> > SciPy-Dev mailing list
> >>> > SciPy-Dev at scipy.org
> >>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>> >
> >>> >
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >>
> >>
> >> --
> >> Ariel Rokem
> >> Helen Wills Neuroscience Institute
> >> University of California, Berkeley
> >> http://argentum.ucbso.berkeley.edu/ariel
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >>
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100304/0f89f3a9/attachment.html>

From josef.pktd at gmail.com  Thu Mar  4 15:27:06 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 4 Mar 2010 15:27:06 -0500
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <43958ee61003041213w7e7cc934h7d5041d5620af85b@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<c048da1c1003041049q6c10fed7ra3d1b4dfaa7e00b8@mail.gmail.com>
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com>
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com>
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com>
	<1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com>
	<43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com>
	<1cd32cbb1003041138i1d2480d4o39f1f3154b01c732@mail.gmail.com>
	<1cd32cbb1003041140x4041719bq78b4e23ac0df549e@mail.gmail.com>
	<43958ee61003041213w7e7cc934h7d5041d5620af85b@mail.gmail.com>
Message-ID: <1cd32cbb1003041227u9a963b1n8c068a7e1ebfad18@mail.gmail.com>

On Thu, Mar 4, 2010 at 3:13 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> Yes. The '.svn' directory is there (in the same directory as setup.py).

Then I'm out of ideas. (The only time I see a Mac is in a coffee shop
or in a fast food chain.)

Josef

>
>
> On Thu, Mar 4, 2010 at 11:40 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Thu, Mar 4, 2010 at 2:38 PM, ?<josef.pktd at gmail.com> wrote:
>> > On Thu, Mar 4, 2010 at 2:32 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
>> >> Hi again - I have now rebuilt scipy from a fresh svn update (r6251),
>> >> but I
>> >> have no file called __svn_version__.py anywhere in the source-tree,
>> >
>> > __svn_version__.py ?is created in the install directory, ?and under
>> > build/lib.... but not in the source tree.
>> >
>> > does svn info give the right information when you call it from the
>> > directory where your scipy setup.py is?
>>
>> os.path.exists('.svn') ?and is this true (same directory as setup.py)?
>>
>> >
>> > Josef
>> >
>> >
>> > as far
>> >> as I could tell by grinning for "__svn__". I did originally have EPD
>> >> installed, but replaced it with the svn build. Could that be the cause?
>> >>
>> >> Cheers - Ariel
>> >>
>> >>
>> >> On Thu, Mar 4, 2010 at 11:14 AM, <josef.pktd at gmail.com> wrote:
>> >>>
>> >>> On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu>
>> >>> wrote:
>> >>> > Yes - I thought I was also building from svn trunk (on a Mac OS
>> >>> > 10.5.8).
>> >>> > Will look into that.
>> >>> >
>> >>> > Cheers - Ariel
>> >>> >
>> >>> > On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold
>> >>> > <jsseabold at gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu>
>> >>> >> wrote:
>> >>> >> > Hi Skipper - thanks!
>> >>> >> >
>> >>> >> > When I try that, I get:
>> >>> >> >
>> >>> >> >
>> >>> >> > In [4]: scipy.version.svn.version
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > ---------------------------------------------------------------------------
>> >>> >> > AttributeError??????????????????????????? Traceback (most recent
>> >>> >> > call
>> >>> >> > last)
>> >>> >> >
>> >>> >> > /Users/arokem/<ipython console> in <module>()
>> >>> >> >
>> >>> >> > AttributeError: 'module' object has no attribute 'svn'
>> >>> >> >
>> >>> >> > In [5]: scipy.__version__
>> >>> >> > Out[5]: '0.8.0.dev'
>> >>> >> >
>> >>> >>
>> >>> >> Hmm. ?Not sure then. ?This is on an Ubuntu Linux install from svn
>> >>> >> trunk.
>> >>>
>> >>> during build, setup.py calls svn info to to check for the revision
>> >>> number and writes it to a file __svn_version__.py
>> >>>
>> >>> This requires a .svn subdirectory, otherwise the revision number check
>> >>> is skipped.
>> >>>
>> >>> Josef
>> >>>
>> >>>
>> >>> >>
>> >>> >> Skipper
>> >>> >> _______________________________________________
>> >>> >> SciPy-Dev mailing list
>> >>> >> SciPy-Dev at scipy.org
>> >>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Ariel Rokem
>> >>> > Helen Wills Neuroscience Institute
>> >>> > University of California, Berkeley
>> >>> > http://argentum.ucbso.berkeley.edu/ariel
>> >>> >
>> >>> > _______________________________________________
>> >>> > SciPy-Dev mailing list
>> >>> > SciPy-Dev at scipy.org
>> >>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >>> >
>> >>> >
>> >>> _______________________________________________
>> >>> SciPy-Dev mailing list
>> >>> SciPy-Dev at scipy.org
>> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >>
>> >> --
>> >> Ariel Rokem
>> >> Helen Wills Neuroscience Institute
>> >> University of California, Berkeley
>> >> http://argentum.ucbso.berkeley.edu/ariel
>> >>
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From arokem at berkeley.edu  Thu Mar  4 15:30:28 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Thu, 4 Mar 2010 12:30:28 -0800
Subject: [SciPy-Dev] lfilter segfault with initial condition on windows
In-Reply-To: <1cd32cbb1003041227u9a963b1n8c068a7e1ebfad18@mail.gmail.com>
References: <4B8FB05A.102@googlemail.com>
	<43958ee61003041053r280f48b3oe7913b052cf91c64@mail.gmail.com> 
	<c048da1c1003041100r5ef01145v2f4f493108c4cb6b@mail.gmail.com> 
	<43958ee61003041103p683a86f8j7e2f7c607cab9bc1@mail.gmail.com> 
	<1cd32cbb1003041114s4a410bbbj5c60eed61c01d694@mail.gmail.com> 
	<43958ee61003041132i6b3eebb1k7f29ad65da3cc43a@mail.gmail.com> 
	<1cd32cbb1003041138i1d2480d4o39f1f3154b01c732@mail.gmail.com> 
	<1cd32cbb1003041140x4041719bq78b4e23ac0df549e@mail.gmail.com> 
	<43958ee61003041213w7e7cc934h7d5041d5620af85b@mail.gmail.com> 
	<1cd32cbb1003041227u9a963b1n8c068a7e1ebfad18@mail.gmail.com>
Message-ID: <43958ee61003041230x4732c149o5968a7e4bc54ff45@mail.gmail.com>

And me - the only time I see a fast-food chain, is when I travel outside of
Berkeley :-)

Thanks for your help!

On Thu, Mar 4, 2010 at 12:27 PM, <josef.pktd at gmail.com> wrote:

> On Thu, Mar 4, 2010 at 3:13 PM, Ariel Rokem <arokem at berkeley.edu> wrote:
> > Yes. The '.svn' directory is there (in the same directory as setup.py).
>
> Then I'm out of ideas. (The only time I see a Mac is in a coffee shop
> or in a fast food chain.)
>
> Josef
>
> >
> >
> > On Thu, Mar 4, 2010 at 11:40 AM, <josef.pktd at gmail.com> wrote:
> >>
> >> On Thu, Mar 4, 2010 at 2:38 PM,  <josef.pktd at gmail.com> wrote:
> >> > On Thu, Mar 4, 2010 at 2:32 PM, Ariel Rokem <arokem at berkeley.edu>
> wrote:
> >> >> Hi again - I have now rebuilt scipy from a fresh svn update (r6251),
> >> >> but I
> >> >> have no file called __svn_version__.py anywhere in the source-tree,
> >> >
> >> > __svn_version__.py  is created in the install directory,  and under
> >> > build/lib.... but not in the source tree.
> >> >
> >> > does svn info give the right information when you call it from the
> >> > directory where your scipy setup.py is?
> >>
> >> os.path.exists('.svn')  and is this true (same directory as setup.py)?
> >>
> >> >
> >> > Josef
> >> >
> >> >
> >> > as far
> >> >> as I could tell by grinning for "__svn__". I did originally have EPD
> >> >> installed, but replaced it with the svn build. Could that be the
> cause?
> >> >>
> >> >> Cheers - Ariel
> >> >>
> >> >>
> >> >> On Thu, Mar 4, 2010 at 11:14 AM, <josef.pktd at gmail.com> wrote:
> >> >>>
> >> >>> On Thu, Mar 4, 2010 at 2:03 PM, Ariel Rokem <arokem at berkeley.edu>
> >> >>> wrote:
> >> >>> > Yes - I thought I was also building from svn trunk (on a Mac OS
> >> >>> > 10.5.8).
> >> >>> > Will look into that.
> >> >>> >
> >> >>> > Cheers - Ariel
> >> >>> >
> >> >>> > On Thu, Mar 4, 2010 at 11:00 AM, Skipper Seabold
> >> >>> > <jsseabold at gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Thu, Mar 4, 2010 at 1:53 PM, Ariel Rokem <arokem at berkeley.edu
> >
> >> >>> >> wrote:
> >> >>> >> > Hi Skipper - thanks!
> >> >>> >> >
> >> >>> >> > When I try that, I get:
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > In [4]: scipy.version.svn.version
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> ---------------------------------------------------------------------------
> >> >>> >> > AttributeError                            Traceback (most
> recent
> >> >>> >> > call
> >> >>> >> > last)
> >> >>> >> >
> >> >>> >> > /Users/arokem/<ipython console> in <module>()
> >> >>> >> >
> >> >>> >> > AttributeError: 'module' object has no attribute 'svn'
> >> >>> >> >
> >> >>> >> > In [5]: scipy.__version__
> >> >>> >> > Out[5]: '0.8.0.dev'
> >> >>> >> >
> >> >>> >>
> >> >>> >> Hmm.  Not sure then.  This is on an Ubuntu Linux install from svn
> >> >>> >> trunk.
> >> >>>
> >> >>> during build, setup.py calls svn info to to check for the revision
> >> >>> number and writes it to a file __svn_version__.py
> >> >>>
> >> >>> This requires a .svn subdirectory, otherwise the revision number
> check
> >> >>> is skipped.
> >> >>>
> >> >>> Josef
> >> >>>
> >> >>>
> >> >>> >>
> >> >>> >> Skipper
> >> >>> >> _______________________________________________
> >> >>> >> SciPy-Dev mailing list
> >> >>> >> SciPy-Dev at scipy.org
> >> >>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Ariel Rokem
> >> >>> > Helen Wills Neuroscience Institute
> >> >>> > University of California, Berkeley
> >> >>> > http://argentum.ucbso.berkeley.edu/ariel
> >> >>> >
> >> >>> > _______________________________________________
> >> >>> > SciPy-Dev mailing list
> >> >>> > SciPy-Dev at scipy.org
> >> >>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >>> >
> >> >>> >
> >> >>> _______________________________________________
> >> >>> SciPy-Dev mailing list
> >> >>> SciPy-Dev at scipy.org
> >> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Ariel Rokem
> >> >> Helen Wills Neuroscience Institute
> >> >> University of California, Berkeley
> >> >> http://argentum.ucbso.berkeley.edu/ariel
> >> >>
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >>
> >> >>
> >> >
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > --
> > Ariel Rokem
> > Helen Wills Neuroscience Institute
> > University of California, Berkeley
> > http://argentum.ucbso.berkeley.edu/ariel
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100304/19dbe404/attachment.html>

From e.antero.tammi at gmail.com  Fri Mar  5 18:56:37 2010
From: e.antero.tammi at gmail.com (eat)
Date: Fri, 5 Mar 2010 23:56:37 +0000 (UTC)
Subject: [SciPy-Dev] Seeking help/ advice for applying functions
Message-ID: <loom.20100306T004849-522@post.gmane.org>

"""
Hi,

I would like to ask some advice for a (pretty generic kind of) problem as:

I do have some data which I'll like to put trough several (thousands of)
functions.

I have cooked up a simple demonstration of the problem, and two plausible
solutions for it. However I'm not happy with either 'gproc1' or 'gproc2'.

So, does someone have a more suitable scipy/ numpy solution for this
kind of problem?


Regards,
eat

OK, here is the some code as demonstration:
"""

import numpy as np

data= np.random.random((1, 2))
fncs= np.asarray([np.sin, np.cos, np.tan, np.sinh, np.cosh, np.tanh])
cs= np.asarray(np.random.randint(0, 2, (5, len(fncs))), dtype= bool)

def mid(x): return np.round(x, 3)
def gcntrl(m, cs):
    for k in xrange(m):
        yield cs[k, :]


def gproc1(gcntrl, fncs, data):
    for c in gcntrl:
        yield np.asarray([mid(f(data)) for f in fncs[c]])

def rr(data):
    def f(g): return g(data)
    return f
def gproc2(gcntrl, fncs, data):
    for c in gcntrl:
        yield mid(np.asarray(map(rr(data), fncs[c])))


def a(g, n):
    def p(g, c, cs, f, d):
        for r in g(c(cs.shape[0], cs), f, d):
            print r.squeeze()
    print n+ ' approach:'; p(g, gcntrl, cs, fncs, data); print


if __name__ == '__main__':
    a(gproc1, 'firsth')
    a(gproc2, 'second')
    #??? a(gproc3, 'third')




From warren.weckesser at enthought.com  Sun Mar  7 20:22:50 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 07 Mar 2010 19:22:50 -0600
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
Message-ID: <4B94516A.3030701@enthought.com>

I am going to update linalg.toeplitz to fix the problem reported in
ticket #667, but I have some questions about the desired behavior of
the function when either `c` (the first column) or `r` (the first row)
is complex.  The docstring does not say anything about complex values,
but the code does some undocumented and unexpected things in this
case, one example of which is the bug reported in the ticket #667.

I would like to fix this, but I would first like opinions on exactly
how it *should* handle complex arguments.  I *think* the idea is that
if `c` is complex and `r` is not given, then a Hermitian Toeplitz
matrix is created.  Is that correct?  Note that this requires that
c[0] be real, since c[0] is the value that will be in the diagonal of
the matrix.

While I am fixing this, I would like to remove the printed warning
that occurs when r[0] != c[0].  I would like to change this to raise
a ValueError--that is, adopt the philosophy that either the arguments
are correct (and the code handles them as [not yet, but soon to be]
documented in the docstring, with no warnings needed), or the
arguments are wrong and an exception should be raised.

This means that when `r` is not given, an exception would be raised
if c[0] is not real.

A very different way to handle the case of `r` not being given is to
assume it means a square matrix should be created with r[1:] = 0
(i.e. zeros in all the upper off-diagonals).  This avoids the whole
issue of complex numbers and conjugates, but it is also a more
drastic change.


Warren



From warren.weckesser at enthought.com  Sun Mar  7 20:32:54 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 07 Mar 2010 19:32:54 -0600
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <4B94516A.3030701@enthought.com>
References: <4B94516A.3030701@enthought.com>
Message-ID: <4B9453C6.4000105@enthought.com>

Warren Weckesser wrote:
> I am going to update linalg.toeplitz to fix the problem reported in
> ticket #667, but I have some questions about the desired behavior of
> the function when either `c` (the first column) or `r` (the first row)
> is complex.  The docstring does not say anything about complex values,
> but the code does some undocumented and unexpected things in this
> case, one example of which is the bug reported in the ticket #667.
>
> I would like to fix this, but I would first like opinions on exactly
> how it *should* handle complex arguments.  I *think* the idea is that
> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
> matrix is created.  Is that correct?  Note that this requires that
> c[0] be real, since c[0] is the value that will be in the diagonal of
> the matrix.
>
> While I am fixing this, I would like to remove the printed warning
> that occurs when r[0] != c[0].  I would like to change this to raise
> a ValueError--that is, adopt the philosophy that either the arguments
> are correct (and the code handles them as [not yet, but soon to be]
> documented in the docstring, with no warnings needed), or the
> arguments are wrong and an exception should be raised.
>
> This means that when `r` is not given, an exception would be raised
> if c[0] is not real.
>
> A very different way to handle the case of `r` not being given is to
> assume it means a square matrix should be created with r[1:] = 0
> (i.e. zeros in all the upper off-diagonals).  This avoids the whole
> issue of complex numbers and conjugates, but it is also a more
> drastic change.
>
>   

By the way, that is how linalg.hankel handles the case where `r` is not 
given.


Warren



From josef.pktd at gmail.com  Sun Mar  7 21:05:47 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 7 Mar 2010 21:05:47 -0500
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <4B9453C6.4000105@enthought.com>
References: <4B94516A.3030701@enthought.com> <4B9453C6.4000105@enthought.com>
Message-ID: <1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>

On Sun, Mar 7, 2010 at 8:32 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> Warren Weckesser wrote:
>> I am going to update linalg.toeplitz to fix the problem reported in
>> ticket #667, but I have some questions about the desired behavior of
>> the function when either `c` (the first column) or `r` (the first row)
>> is complex. ?The docstring does not say anything about complex values,
>> but the code does some undocumented and unexpected things in this
>> case, one example of which is the bug reported in the ticket #667.
>>
>> I would like to fix this, but I would first like opinions on exactly
>> how it *should* handle complex arguments. ?I *think* the idea is that
>> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
>> matrix is created. ?Is that correct? ?Note that this requires that
>> c[0] be real, since c[0] is the value that will be in the diagonal of
>> the matrix.
>>
>> While I am fixing this, I would like to remove the printed warning
>> that occurs when r[0] != c[0]. ?I would like to change this to raise
>> a ValueError--that is, adopt the philosophy that either the arguments
>> are correct (and the code handles them as [not yet, but soon to be]
>> documented in the docstring, with no warnings needed), or the
>> arguments are wrong and an exception should be raised.
>>
>> This means that when `r` is not given, an exception would be raised
>> if c[0] is not real.
>>
>> A very different way to handle the case of `r` not being given is to
>> assume it means a square matrix should be created with r[1:] = 0
>> (i.e. zeros in all the upper off-diagonals). ?This avoids the whole
>> issue of complex numbers and conjugates, but it is also a more
>> drastic change.

a lot of code relies on toeplitz of a single argument to build the
symmetric matrix.

>>
>>
>
> By the way, that is how linalg.hankel handles the case where `r` is not
> given.

??

>>> import scipy.linalg
>>> scipy.linalg.toeplitz(np.arange(4))
array([[0, 1, 2, 3],
       [1, 0, 1, 2],
       [2, 1, 0, 1],
       [3, 2, 1, 0]])
>>> scipy.linalg.hankel(np.arange(4))
array([[ 0.,  1.,  2.,  3.],
       [ 1.,  2.,  3.,  0.],
       [ 2.,  3.,  0.,  0.],
       [ 3.,  0.,  0.,  0.]])
>>>
>>> scipy.linalg.hankel(np.arange(4)+1.j)
array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
       [ 1.+1.j,  2.+1.j,  3.+1.j,  0.+0.j],
       [ 2.+1.j,  3.+1.j,  0.+0.j,  0.+0.j],
       [ 3.+1.j,  0.+0.j,  0.+0.j,  0.+0.j]])
>>> scipy.linalg.toeplitz(np.arange(4)+1.j)
Warning: column and row values don't agree; column value used.
array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
       [ 1.-1.j,  0.+1.j,  1.+1.j,  2.+1.j],
       [ 2.-1.j,  1.-1.j,  0.+1.j,  1.+1.j],
       [ 3.-1.j,  2.-1.j,  1.-1.j,  0.+1.j]])


requiring the diagonal to be real might be too tough, I'm not using
complex toeplitz, but for other cases, I often have "almost real"
values, up to numerical imprecision.

>>> scipy.linalg.toeplitz(np.arange(4)*1.j,-np.arange(4)*1.j)
array([[ 0.+0.j,  0.-1.j,  0.-2.j,  0.-3.j],
       [ 0.+1.j,  0.+0.j,  0.-1.j,  0.-2.j],
       [ 0.+2.j,  0.+1.j,  0.+0.j,  0.-1.j],
       [ 0.+3.j,  0.+2.j,  0.+1.j,  0.+0.j]])

also for real values  r[0] != c[0] might not be satisfied if there is
numerical imprecision and they are only almost equal.

Josef

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


From warren.weckesser at enthought.com  Sun Mar  7 22:01:39 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 07 Mar 2010 21:01:39 -0600
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>
References: <4B94516A.3030701@enthought.com> <4B9453C6.4000105@enthought.com>
	<1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>
Message-ID: <4B946893.8090202@enthought.com>


josef.pktd at gmail.com wrote:
> On Sun, Mar 7, 2010 at 8:32 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>   
>> Warren Weckesser wrote:
>>     
>>> I am going to update linalg.toeplitz to fix the problem reported in
>>> ticket #667, but I have some questions about the desired behavior of
>>> the function when either `c` (the first column) or `r` (the first row)
>>> is complex.  The docstring does not say anything about complex values,
>>> but the code does some undocumented and unexpected things in this
>>> case, one example of which is the bug reported in the ticket #667.
>>>
>>> I would like to fix this, but I would first like opinions on exactly
>>> how it *should* handle complex arguments.  I *think* the idea is that
>>> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
>>> matrix is created.  Is that correct?  Note that this requires that
>>> c[0] be real, since c[0] is the value that will be in the diagonal of
>>> the matrix.
>>>
>>>       

It looks like the behavior was copied from Matlab:

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/toeplitz.html

>>> While I am fixing this, I would like to remove the printed warning
>>> that occurs when r[0] != c[0].  I would like to change this to raise
>>> a ValueError--that is, adopt the philosophy that either the arguments
>>> are correct (and the code handles them as [not yet, but soon to be]
>>> documented in the docstring, with no warnings needed), or the
>>> arguments are wrong and an exception should be raised.
>>>
>>> This means that when `r` is not given, an exception would be raised
>>> if c[0] is not real.
>>>
>>> A very different way to handle the case of `r` not being given is to
>>> assume it means a square matrix should be created with r[1:] = 0
>>> (i.e. zeros in all the upper off-diagonals).  This avoids the whole
>>> issue of complex numbers and conjugates, but it is also a more
>>> drastic change.
>>>       
>
> a lot of code relies on toeplitz of a single argument to build the
> symmetric matrix.
>
>   

OK, thanks--that's good to know.

>>>       
>> By the way, that is how linalg.hankel handles the case where `r` is not
>> given.
>>     
>
> ??
>
>   

I'm not sure what your question marks mean.  What I meant by "that is 
how linalg.hankel handles [it]" was that when `r` is not given, hankel 
uses zeros to fill in the bottom row.  Your examples demonstrate this.  
My point is moot, since if there is "a lot of code" that relies on 
creating a symmetric/hermitian matrix, it would be a bad idea to make 
such a significant change to the API.

>>>> import scipy.linalg
>>>> scipy.linalg.toeplitz(np.arange(4))
>>>>         
> array([[0, 1, 2, 3],
>        [1, 0, 1, 2],
>        [2, 1, 0, 1],
>        [3, 2, 1, 0]])
>   
>>>> scipy.linalg.hankel(np.arange(4))
>>>>         
> array([[ 0.,  1.,  2.,  3.],
>        [ 1.,  2.,  3.,  0.],
>        [ 2.,  3.,  0.,  0.],
>        [ 3.,  0.,  0.,  0.]])
>   
>>>> scipy.linalg.hankel(np.arange(4)+1.j)
>>>>         
> array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
>        [ 1.+1.j,  2.+1.j,  3.+1.j,  0.+0.j],
>        [ 2.+1.j,  3.+1.j,  0.+0.j,  0.+0.j],
>        [ 3.+1.j,  0.+0.j,  0.+0.j,  0.+0.j]])
>   
>>>> scipy.linalg.toeplitz(np.arange(4)+1.j)
>>>>         
> Warning: column and row values don't agree; column value used.
> array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
>        [ 1.-1.j,  0.+1.j,  1.+1.j,  2.+1.j],
>        [ 2.-1.j,  1.-1.j,  0.+1.j,  1.+1.j],
>        [ 3.-1.j,  2.-1.j,  1.-1.j,  0.+1.j]])
>
>
> requiring the diagonal to be real might be too tough, I'm not using
> complex toeplitz, but for other cases, I often have "almost real"
> values, up to numerical imprecision.
>
>   

This could be dealt with like Matlab does: don't worry about it, and 
just use c[1:] to fill in r[1:].  If c[0] is has nonzero imaginary part, 
then the matrix is not Hermitian--but that's OK, since that is what the 
user gave to the function.

Your example illustrates one of the bugs: note that, except for the 
first element, the first column is the *conjugate* of the first 
argument.  The docstring says that `c` is the first column (and the 
optional second argument is the first row).  So it is the elements in 
the first row starting in the second column that should be conjugated.  
It also prints that annoying warning.

>>>> scipy.linalg.toeplitz(np.arange(4)*1.j,-np.arange(4)*1.j)
>>>>         
> array([[ 0.+0.j,  0.-1.j,  0.-2.j,  0.-3.j],
>        [ 0.+1.j,  0.+0.j,  0.-1.j,  0.-2.j],
>        [ 0.+2.j,  0.+1.j,  0.+0.j,  0.-1.j],
>        [ 0.+3.j,  0.+2.j,  0.+1.j,  0.+0.j]])
>
> also for real values  r[0] != c[0] might not be satisfied if there is
> numerical imprecision and they are only almost equal.
>
>   


True.  So if the requirement that r[0] == c[0] is strict, a user who 
knows the first values are "close enough", but maybe not exactly equal, 
would have to do something like:

r[0] = c[0]
t = toeplitz(c, r)

I could live with that, but not everyone will agree.

Instead, the function could require that the values be "close", using 
something like numpy.allclose(), but how close is close enough?  Should 
the function then have `atol` and `rtol` arguments to use for the 
comparison?  This feels like overkill, and is not my preference.

So that leaves the behavior used by Matlab: use c[0], and ignore r[0].  
But I don't like the printed warning (or any logged warning) when c[0] 
!= r[0].  If the program is behaving correctly, and as documented, no 
warning should be necessary.

(If I could start from scratch, I would simply define the `r` argument 
to give the values from the second column onward, and so completely 
avoid the issue.)

Warren



From robert.kern at gmail.com  Mon Mar  8 15:24:22 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 8 Mar 2010 14:24:22 -0600
Subject: [SciPy-Dev] Seeking help/ advice for applying functions
In-Reply-To: <loom.20100306T004849-522@post.gmane.org>
References: <loom.20100306T004849-522@post.gmane.org>
Message-ID: <3d375d731003081224g25901ddcrcbe63ddddeef6db3@mail.gmail.com>

On Fri, Mar 5, 2010 at 17:56, eat <e.antero.tammi at gmail.com> wrote:
> """
> Hi,
>
> I would like to ask some advice for a (pretty generic kind of) problem as:
>
> I do have some data which I'll like to put trough several (thousands of)
> functions.
>
> I have cooked up a simple demonstration of the problem, and two plausible
> solutions for it. However I'm not happy with either 'gproc1' or 'gproc2'.
>
> So, does someone have a more suitable scipy/ numpy solution for this
> kind of problem?

Your example is not very clear. Can you write a less cryptic one with
informative variable names and perhaps some comments about what each
part is doing?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From warren.weckesser at enthought.com  Mon Mar  8 22:25:29 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 08 Mar 2010 21:25:29 -0600
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <4B946893.8090202@enthought.com>
References: <4B94516A.3030701@enthought.com>
	<4B9453C6.4000105@enthought.com>	<1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>
	<4B946893.8090202@enthought.com>
Message-ID: <4B95BFA9.4020507@enthought.com>

Two more questions about the toeplitz API:

The signature is toeplitz(c, r=None).  In the current implementation,
if either c or r is a scalar, then c is returned.  This results in the
following:

In [1]: from scipy.linalg import toeplitz

In [2]: toeplitz(1, [1,2,3,4])
Out[2]: 1

In [3]: toeplitz([1], [1,2,3,4])
Out[3]: array([[1, 2, 3, 4]])

I would expect these to produce the same result--the second result,
in fact.

Similarly, the following is surprising:

In [4]: toeplitz([1,2,3,4], 1)
Out[4]: [1, 2, 3, 4]

In [5]: toeplitz([1,2,3,4], [1])
Out[5]:
array([[1],
       [2],
       [3],
       [4]])

I think it makes more sense for toeplitz to simply treat a scalar
as a 1D array of length 1.  Moreover, it seems to me that toeplitz
should *always* return a 2D array.


My second question: does anyone know why toeplitz uses
asarray_chkfinite()?  If, in general, numpy arrays can hold the
values nan and inf, why should this function care if its values
are finite?  Any objections to not using asarray_chkfinite()?


Warren



Warren Weckesser wrote:
> josef.pktd at gmail.com wrote:
>   
>> On Sun, Mar 7, 2010 at 8:32 PM, Warren Weckesser
>> <warren.weckesser at enthought.com> wrote:
>>   
>>     
>>> Warren Weckesser wrote:
>>>     
>>>       
>>>> I am going to update linalg.toeplitz to fix the problem reported in
>>>> ticket #667, but I have some questions about the desired behavior of
>>>> the function when either `c` (the first column) or `r` (the first row)
>>>> is complex.  The docstring does not say anything about complex values,
>>>> but the code does some undocumented and unexpected things in this
>>>> case, one example of which is the bug reported in the ticket #667.
>>>>
>>>> I would like to fix this, but I would first like opinions on exactly
>>>> how it *should* handle complex arguments.  I *think* the idea is that
>>>> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
>>>> matrix is created.  Is that correct?  Note that this requires that
>>>> c[0] be real, since c[0] is the value that will be in the diagonal of
>>>> the matrix.
>>>>
>>>>       
>>>>         
>
> It looks like the behavior was copied from Matlab:
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/toeplitz.html
>
>   
>>>> While I am fixing this, I would like to remove the printed warning
>>>> that occurs when r[0] != c[0].  I would like to change this to raise
>>>> a ValueError--that is, adopt the philosophy that either the arguments
>>>> are correct (and the code handles them as [not yet, but soon to be]
>>>> documented in the docstring, with no warnings needed), or the
>>>> arguments are wrong and an exception should be raised.
>>>>
>>>> This means that when `r` is not given, an exception would be raised
>>>> if c[0] is not real.
>>>>
>>>> A very different way to handle the case of `r` not being given is to
>>>> assume it means a square matrix should be created with r[1:] = 0
>>>> (i.e. zeros in all the upper off-diagonals).  This avoids the whole
>>>> issue of complex numbers and conjugates, but it is also a more
>>>> drastic change.
>>>>       
>>>>         
>> a lot of code relies on toeplitz of a single argument to build the
>> symmetric matrix.
>>
>>   
>>     
>
> OK, thanks--that's good to know.
>
>   
>>>>       
>>>>         
>>> By the way, that is how linalg.hankel handles the case where `r` is not
>>> given.
>>>     
>>>       
>> ??
>>
>>   
>>     
>
> I'm not sure what your question marks mean.  What I meant by "that is 
> how linalg.hankel handles [it]" was that when `r` is not given, hankel 
> uses zeros to fill in the bottom row.  Your examples demonstrate this.  
> My point is moot, since if there is "a lot of code" that relies on 
> creating a symmetric/hermitian matrix, it would be a bad idea to make 
> such a significant change to the API.
>
>   
>>>>> import scipy.linalg
>>>>> scipy.linalg.toeplitz(np.arange(4))
>>>>>         
>>>>>           
>> array([[0, 1, 2, 3],
>>        [1, 0, 1, 2],
>>        [2, 1, 0, 1],
>>        [3, 2, 1, 0]])
>>   
>>     
>>>>> scipy.linalg.hankel(np.arange(4))
>>>>>         
>>>>>           
>> array([[ 0.,  1.,  2.,  3.],
>>        [ 1.,  2.,  3.,  0.],
>>        [ 2.,  3.,  0.,  0.],
>>        [ 3.,  0.,  0.,  0.]])
>>   
>>     
>>>>> scipy.linalg.hankel(np.arange(4)+1.j)
>>>>>         
>>>>>           
>> array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
>>        [ 1.+1.j,  2.+1.j,  3.+1.j,  0.+0.j],
>>        [ 2.+1.j,  3.+1.j,  0.+0.j,  0.+0.j],
>>        [ 3.+1.j,  0.+0.j,  0.+0.j,  0.+0.j]])
>>   
>>     
>>>>> scipy.linalg.toeplitz(np.arange(4)+1.j)
>>>>>         
>>>>>           
>> Warning: column and row values don't agree; column value used.
>> array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
>>        [ 1.-1.j,  0.+1.j,  1.+1.j,  2.+1.j],
>>        [ 2.-1.j,  1.-1.j,  0.+1.j,  1.+1.j],
>>        [ 3.-1.j,  2.-1.j,  1.-1.j,  0.+1.j]])
>>
>>
>> requiring the diagonal to be real might be too tough, I'm not using
>> complex toeplitz, but for other cases, I often have "almost real"
>> values, up to numerical imprecision.
>>
>>   
>>     
>
> This could be dealt with like Matlab does: don't worry about it, and 
> just use c[1:] to fill in r[1:].  If c[0] is has nonzero imaginary part, 
> then the matrix is not Hermitian--but that's OK, since that is what the 
> user gave to the function.
>
> Your example illustrates one of the bugs: note that, except for the 
> first element, the first column is the *conjugate* of the first 
> argument.  The docstring says that `c` is the first column (and the 
> optional second argument is the first row).  So it is the elements in 
> the first row starting in the second column that should be conjugated.  
> It also prints that annoying warning.
>
>   
>>>>> scipy.linalg.toeplitz(np.arange(4)*1.j,-np.arange(4)*1.j)
>>>>>         
>>>>>           
>> array([[ 0.+0.j,  0.-1.j,  0.-2.j,  0.-3.j],
>>        [ 0.+1.j,  0.+0.j,  0.-1.j,  0.-2.j],
>>        [ 0.+2.j,  0.+1.j,  0.+0.j,  0.-1.j],
>>        [ 0.+3.j,  0.+2.j,  0.+1.j,  0.+0.j]])
>>
>> also for real values  r[0] != c[0] might not be satisfied if there is
>> numerical imprecision and they are only almost equal.
>>
>>   
>>     
>
>
> True.  So if the requirement that r[0] == c[0] is strict, a user who 
> knows the first values are "close enough", but maybe not exactly equal, 
> would have to do something like:
>
> r[0] = c[0]
> t = toeplitz(c, r)
>
> I could live with that, but not everyone will agree.
>
> Instead, the function could require that the values be "close", using 
> something like numpy.allclose(), but how close is close enough?  Should 
> the function then have `atol` and `rtol` arguments to use for the 
> comparison?  This feels like overkill, and is not my preference.
>
> So that leaves the behavior used by Matlab: use c[0], and ignore r[0].  
> But I don't like the printed warning (or any logged warning) when c[0] 
> != r[0].  If the program is behaving correctly, and as documented, no 
> warning should be necessary.
>
> (If I could start from scratch, I would simply define the `r` argument 
> to give the values from the second column onward, and so completely 
> avoid the issue.)
>
> Warren
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From benny.malengier at gmail.com  Tue Mar  9 03:35:28 2010
From: benny.malengier at gmail.com (Benny Malengier)
Date: Tue, 9 Mar 2010 09:35:28 +0100
Subject: [SciPy-Dev] Seeking help/ advice for applying functions
In-Reply-To: <3d375d731003081224g25901ddcrcbe63ddddeef6db3@mail.gmail.com>
References: <loom.20100306T004849-522@post.gmane.org>
	<3d375d731003081224g25901ddcrcbe63ddddeef6db3@mail.gmail.com>
Message-ID: <bcafe8291003090035u220a6df8if5094d1376ead61b@mail.gmail.com>

2010/3/8 Robert Kern <robert.kern at gmail.com>:
> On Fri, Mar 5, 2010 at 17:56, eat <e.antero.tammi at gmail.com> wrote:
>> """
>> Hi,
>>
>> I would like to ask some advice for a (pretty generic kind of) problem as:
>>
>> I do have some data which I'll like to put trough several (thousands of)
>> functions.
>>
>> I have cooked up a simple demonstration of the problem, and two plausible
>> solutions for it. However I'm not happy with either 'gproc1' or 'gproc2'.
>>
>> So, does someone have a more suitable scipy/ numpy solution for this
>> kind of problem?
>
> Your example is not very clear. Can you write a less cryptic one with
> informative variable names and perhaps some comments about what each
> part is doing?
>

Yes. I would change that at least. If I'd change something else, it
would be that you still use python arrays for some in between
variables. I'd preassign arrays with empty instead, and then work on
those, to avoid the big list to big array conversions. Also, the use
of mid function is not needed for asking the question, it makes it
just harder to read your code.

Benny
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> ?-- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From josef.pktd at gmail.com  Tue Mar  9 10:05:27 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 9 Mar 2010 10:05:27 -0500
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <4B95BFA9.4020507@enthought.com>
References: <4B94516A.3030701@enthought.com> <4B9453C6.4000105@enthought.com>
	<1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>
	<4B946893.8090202@enthought.com> <4B95BFA9.4020507@enthought.com>
Message-ID: <1cd32cbb1003090705p453e5234h73edd39c1b37f1c6@mail.gmail.com>

On Mon, Mar 8, 2010 at 10:25 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> Two more questions about the toeplitz API:

I did a (partial) search in trac and on the mailing lists and didn't
find any information


>
> The signature is toeplitz(c, r=None). ?In the current implementation,
> if either c or r is a scalar, then c is returned. ?This results in the
> following:
>
> In [1]: from scipy.linalg import toeplitz
>
> In [2]: toeplitz(1, [1,2,3,4])
> Out[2]: 1
>
> In [3]: toeplitz([1], [1,2,3,4])
> Out[3]: array([[1, 2, 3, 4]])
>
> I would expect these to produce the same result--the second result,
> in fact.
>
> Similarly, the following is surprising:
>
> In [4]: toeplitz([1,2,3,4], 1)
> Out[4]: [1, 2, 3, 4]
>
> In [5]: toeplitz([1,2,3,4], [1])
> Out[5]:
> array([[1],
> ? ? ? [2],
> ? ? ? [3],
> ? ? ? [4]])
>
> I think it makes more sense for toeplitz to simply treat a scalar
> as a 1D array of length 1. ?Moreover, it seems to me that toeplitz
> should *always* return a 2D array.

numpy/scipy is not matlab, so the policy is still a bit vague

>>> np.kron(5,3)
15
>>> np.kron([5],[3])
array([15])
>>> np.kron([5],[3]).shape
(1,)
>>> scipy.linalg.hankel(1)
1
>>> scipy.linalg.hankel(1,2)
1
>>> np.triu(3)
Traceback (most recent call last):
  File "C:\Programs\Python25\Lib\site-packages\numpy\lib\twodim_base.py",
line 442, in triu
    out = multiply((1-tri(m.shape[0], m.shape[1], k-1, int)),m)
IndexError: tuple index out of range
>>> np.triu([3])
Traceback (most recent call last):
  File "C:\Programs\Python25\Lib\site-packages\numpy\lib\twodim_base.py",
line 442, in triu
    out = multiply((1-tri(m.shape[0], m.shape[1], k-1, int)),m)
IndexError: tuple index out of range
>>> np.triu([[3]])
array([[3]])

>>> scipy.linalg.kron([-1j], [1.j])
Traceback (most recent call last):
  File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py",
line 835, in kron
AttributeError: 'list' object has no attribute 'flags'

and I filed a ticket for scipy.linalg.block_diag because there I can
see a use for scalar to 2d.

I don't have a strong opinion about always 2d result, but a bit more
consistency in numpy/scipy would be useful.


>
>
> My second question: does anyone know why toeplitz uses
> asarray_chkfinite()? ?If, in general, numpy arrays can hold the
> values nan and inf, why should this function care if its values
> are finite? ?Any objections to not using asarray_chkfinite()?

I agree, I don't think it's the job of toeplitz or hankle to throw an
exception if I want to have a inf or nan in my matrix.

>
>
> Warren
>
>
>
> Warren Weckesser wrote:
>> josef.pktd at gmail.com wrote:
>>
>>> On Sun, Mar 7, 2010 at 8:32 PM, Warren Weckesser
>>> <warren.weckesser at enthought.com> wrote:
>>>
>>>
>>>> Warren Weckesser wrote:
>>>>
>>>>
>>>>> I am going to update linalg.toeplitz to fix the problem reported in
>>>>> ticket #667, but I have some questions about the desired behavior of
>>>>> the function when either `c` (the first column) or `r` (the first row)
>>>>> is complex. ?The docstring does not say anything about complex values,
>>>>> but the code does some undocumented and unexpected things in this
>>>>> case, one example of which is the bug reported in the ticket #667.
>>>>>
>>>>> I would like to fix this, but I would first like opinions on exactly
>>>>> how it *should* handle complex arguments. ?I *think* the idea is that
>>>>> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
>>>>> matrix is created. ?Is that correct? ?Note that this requires that
>>>>> c[0] be real, since c[0] is the value that will be in the diagonal of
>>>>> the matrix.
>>>>>
>>>>>
>>>>>
>>
>> It looks like the behavior was copied from Matlab:
>>
>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/toeplitz.html
>>
>>
>>>>> While I am fixing this, I would like to remove the printed warning
>>>>> that occurs when r[0] != c[0]. ?I would like to change this to raise
>>>>> a ValueError--that is, adopt the philosophy that either the arguments
>>>>> are correct (and the code handles them as [not yet, but soon to be]
>>>>> documented in the docstring, with no warnings needed), or the
>>>>> arguments are wrong and an exception should be raised.
>>>>>
>>>>> This means that when `r` is not given, an exception would be raised
>>>>> if c[0] is not real.
>>>>>
>>>>> A very different way to handle the case of `r` not being given is to
>>>>> assume it means a square matrix should be created with r[1:] = 0
>>>>> (i.e. zeros in all the upper off-diagonals). ?This avoids the whole
>>>>> issue of complex numbers and conjugates, but it is also a more
>>>>> drastic change.
>>>>>
>>>>>
>>> a lot of code relies on toeplitz of a single argument to build the
>>> symmetric matrix.
>>>
>>>
>>>
>>
>> OK, thanks--that's good to know.
>>
>>
>>>>>
>>>>>
>>>> By the way, that is how linalg.hankel handles the case where `r` is not
>>>> given.
>>>>
>>>>
>>> ??
>>>
>>>
>>>
>>
>> I'm not sure what your question marks mean. ?What I meant by "that is
>> how linalg.hankel handles [it]" was that when `r` is not given, hankel
>> uses zeros to fill in the bottom row. ?Your examples demonstrate this.
>> My point is moot, since if there is "a lot of code" that relies on
>> creating a symmetric/hermitian matrix, it would be a bad idea to make
>> such a significant change to the API.
>>
>>
>>>>>> import scipy.linalg
>>>>>> scipy.linalg.toeplitz(np.arange(4))
>>>>>>
>>>>>>
>>> array([[0, 1, 2, 3],
>>> ? ? ? ?[1, 0, 1, 2],
>>> ? ? ? ?[2, 1, 0, 1],
>>> ? ? ? ?[3, 2, 1, 0]])
>>>
>>>
>>>>>> scipy.linalg.hankel(np.arange(4))
>>>>>>
>>>>>>
>>> array([[ 0., ?1., ?2., ?3.],
>>> ? ? ? ?[ 1., ?2., ?3., ?0.],
>>> ? ? ? ?[ 2., ?3., ?0., ?0.],
>>> ? ? ? ?[ 3., ?0., ?0., ?0.]])
>>>
>>>
>>>>>> scipy.linalg.hankel(np.arange(4)+1.j)
>>>>>>
>>>>>>
>>> array([[ 0.+1.j, ?1.+1.j, ?2.+1.j, ?3.+1.j],
>>> ? ? ? ?[ 1.+1.j, ?2.+1.j, ?3.+1.j, ?0.+0.j],
>>> ? ? ? ?[ 2.+1.j, ?3.+1.j, ?0.+0.j, ?0.+0.j],
>>> ? ? ? ?[ 3.+1.j, ?0.+0.j, ?0.+0.j, ?0.+0.j]])
>>>
>>>
>>>>>> scipy.linalg.toeplitz(np.arange(4)+1.j)
>>>>>>
>>>>>>
>>> Warning: column and row values don't agree; column value used.
>>> array([[ 0.+1.j, ?1.+1.j, ?2.+1.j, ?3.+1.j],
>>> ? ? ? ?[ 1.-1.j, ?0.+1.j, ?1.+1.j, ?2.+1.j],
>>> ? ? ? ?[ 2.-1.j, ?1.-1.j, ?0.+1.j, ?1.+1.j],
>>> ? ? ? ?[ 3.-1.j, ?2.-1.j, ?1.-1.j, ?0.+1.j]])
>>>
>>>
>>> requiring the diagonal to be real might be too tough, I'm not using
>>> complex toeplitz, but for other cases, I often have "almost real"
>>> values, up to numerical imprecision.
>>>
>>>
>>>
>>
>> This could be dealt with like Matlab does: don't worry about it, and
>> just use c[1:] to fill in r[1:]. ?If c[0] is has nonzero imaginary part,
>> then the matrix is not Hermitian--but that's OK, since that is what the
>> user gave to the function.
>>
>> Your example illustrates one of the bugs: note that, except for the
>> first element, the first column is the *conjugate* of the first
>> argument. ?The docstring says that `c` is the first column (and the
>> optional second argument is the first row). ?So it is the elements in
>> the first row starting in the second column that should be conjugated.
>> It also prints that annoying warning.

That's how I interpreted the bug


>>
>>
>>>>>> scipy.linalg.toeplitz(np.arange(4)*1.j,-np.arange(4)*1.j)
>>>>>>
>>>>>>
>>> array([[ 0.+0.j, ?0.-1.j, ?0.-2.j, ?0.-3.j],
>>> ? ? ? ?[ 0.+1.j, ?0.+0.j, ?0.-1.j, ?0.-2.j],
>>> ? ? ? ?[ 0.+2.j, ?0.+1.j, ?0.+0.j, ?0.-1.j],
>>> ? ? ? ?[ 0.+3.j, ?0.+2.j, ?0.+1.j, ?0.+0.j]])
>>>
>>> also for real values ?r[0] != c[0] might not be satisfied if there is
>>> numerical imprecision and they are only almost equal.
>>>
>>>
>>>
>>
>>
>> True. ?So if the requirement that r[0] == c[0] is strict, a user who
>> knows the first values are "close enough", but maybe not exactly equal,
>> would have to do something like:
>>
>> r[0] = c[0]
>> t = toeplitz(c, r)
>>
>> I could live with that, but not everyone will agree.
>>
>> Instead, the function could require that the values be "close", using
>> something like numpy.allclose(), but how close is close enough? ?Should
>> the function then have `atol` and `rtol` arguments to use for the
>> comparison? ?This feels like overkill, and is not my preference.
>>
>> So that leaves the behavior used by Matlab: use c[0], and ignore r[0].
>> But I don't like the printed warning (or any logged warning) when c[0]
>> != r[0]. ?If the program is behaving correctly, and as documented, no
>> warning should be necessary.

raising a proper Warning might be useful and avoid the almost equal issue

I think, all the uses I have seen use only a single argument to build
the symmetric toeplitz matrix.

Josef


>>
>> (If I could start from scratch, I would simply define the `r` argument
>> to give the values from the second column onward, and so completely
>> avoid the issue.)
>>
>> Warren
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From e.antero.tammi at gmail.com  Tue Mar  9 09:59:32 2010
From: e.antero.tammi at gmail.com (eat)
Date: Tue, 9 Mar 2010 14:59:32 +0000 (UTC)
Subject: [SciPy-Dev] Seeking help/ advice for applying functions
References: <loom.20100306T004849-522@post.gmane.org>
	<3d375d731003081224g25901ddcrcbe63ddddeef6db3@mail.gmail.com>
Message-ID: <loom.20100309T155757-217@post.gmane.org>

Robert Kern <robert.kern <at> gmail.com> writes:

> 
> Your example is not very clear. Can you write a less cryptic one with
> informative variable names and perhaps some comments about what each
> part is doing?
> 

"""
Hi,

I have tried to clarify my code. First part is the relevant one, the rest is
there just to provide some context to run some tests.

Also originally I should have posted this to Scipy-User list. Would it be
more appropriate to continue the discussion there?


Regards,
eat
"""

import numpy as np

## relevant part
# expect indicies to be sparse ~1% but hundred of thousands of elements
# also functions not necessary builtins and data may be large
def how1(functions, data):
    """ firsth approach to apply data to functions"""
    def how(indicies):
        return np.asarray([f(data) for f in functions[indicies]]).T
    return how


def how2(functions, data):
    """ second approach to apply data to functions"""
    def rr(data):
        """ reverse the 'roles' of data and function"""
        def f(g):
            return g(data)
        return f
    daf= rr(data)
    def how(indicies):
        return np.asarray(map(daf, functions[indicies])).T
    return how

# as I understand it, how1 and how2 boils down under the hood pretty
# much to the same code, so only syntatical differencies, right?

# and this is the key question: does there exist a more suitable
# scipy/ numpy solution for this situation?

# perhaps some kind of special vectorization as below (as pseudo code)?
def how3(functions, data):
    """ third approach to apply data to functions"""
    def vecme(functions, data, indicies):
        return functions[indicies](data)
    v= np.vectorize(vecme)
    def how(indicies):
        return np.asarray(v(functions, data, indicies)).T
    return how

## end relevant part
# rest is just some context where hows could be applied
def stream(m, n):
    """ mimic some external stream of 0\ 1 indicators"""
    np.random.seed(123)
    ind= np.asarray(np.random.randint(0, 2, (m, n)), dtype= bool)
    for k in xrange(m):
        yield ind[k, :]

def process(stream, how):
    """ consume stream"""
    for ind in stream:
        yield how(ind)

def run(hows, n):
    """run the hows"""
    for app in hows.keys():
        print 'approach:', app
        for r in process(stream(3, n), hows[app]):
            print np.round(r.squeeze(), 2)

if __name__ == '__main__':
    # some data and functions only as demonstration
    data= np.random.random((3, 1))
    fncs= np.asarray([np.sin, np.cos, np.tan, np.sinh, np.cosh, np.tanh])

    # produce equivalent results
    hows= {'firsth': how1(fncs, data),
           'second': how2(fncs, data)}
#           'third': how3(fncs, data)}
    run(hows, len(fncs))




From peridot.faceted at gmail.com  Tue Mar  9 13:12:53 2010
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 9 Mar 2010 13:12:53 -0500
Subject: [SciPy-Dev] Seeking help/ advice for applying functions
In-Reply-To: <loom.20100309T155757-217@post.gmane.org>
References: <loom.20100306T004849-522@post.gmane.org>
	<3d375d731003081224g25901ddcrcbe63ddddeef6db3@mail.gmail.com>
	<loom.20100309T155757-217@post.gmane.org>
Message-ID: <ce557a361003091012n35c7db65o27c1a72c70dfd639@mail.gmail.com>

On 9 March 2010 09:59, eat <e.antero.tammi at gmail.com> wrote:
> Robert Kern <robert.kern <at> gmail.com> writes:
>
>>
>> Your example is not very clear. Can you write a less cryptic one with
>> informative variable names and perhaps some comments about what each
>> part is doing?
>>
>
> """
> Hi,
>
> I have tried to clarify my code. First part is the relevant one, the rest is
> there just to provide some context to run some tests.

The short answer is that no, there's no way to optimize what you're doing.

The long answer is: when numpy and scipy are fast, they are fast
because they avoid running python code: if you add two arrays, there's
only one line of python code, and all the work is done by loops
written in C. If your code is calling many different python functions,
well, since they're python functions, to apply them at all you must
necessarily execute python code. There goes any potential speed
advantage. (There may be a convenience advantage; if so, you can look
into using np.vectorize, which is just a wrapper around a python loop,
but is convenient.)

That said, I assume you are considering numpy/scipy because you have
arrays of thousands or more. It also seems unlikely that you actually
have thousands of different functions (that's an awful lot of source
code!). So if your "different" functions are actually just a handful
(or fewer) pieces of actual code, and you are getting your thousands
of functions by wrapping them up with parameters and local variables,
well, now there are possibilities. Exactly what possibilities depend
on what your functions look like - which is one reason Robert Kern
asked you to clarify your code - but they all boil down to rearranging
the problem so that it goes back to "few functions, much data", then
writing the functions in such a way that you can use numpy to apply
them to thousands or millions of data points at once.

> Also originally I should have posted this to Scipy-User list. Would it be
> more appropriate to continue the discussion there?

Probably.


Anne

> Regards,
> eat
> """
>
> import numpy as np
>
> ## relevant part
> # expect indicies to be sparse ~1% but hundred of thousands of elements
> # also functions not necessary builtins and data may be large
> def how1(functions, data):
> ? ?""" firsth approach to apply data to functions"""
> ? ?def how(indicies):
> ? ? ? ?return np.asarray([f(data) for f in functions[indicies]]).T
> ? ?return how
>
>
> def how2(functions, data):
> ? ?""" second approach to apply data to functions"""
> ? ?def rr(data):
> ? ? ? ?""" reverse the 'roles' of data and function"""
> ? ? ? ?def f(g):
> ? ? ? ? ? ?return g(data)
> ? ? ? ?return f
> ? ?daf= rr(data)
> ? ?def how(indicies):
> ? ? ? ?return np.asarray(map(daf, functions[indicies])).T
> ? ?return how
>
> # as I understand it, how1 and how2 boils down under the hood pretty
> # much to the same code, so only syntatical differencies, right?
>
> # and this is the key question: does there exist a more suitable
> # scipy/ numpy solution for this situation?
>
> # perhaps some kind of special vectorization as below (as pseudo code)?
> def how3(functions, data):
> ? ?""" third approach to apply data to functions"""
> ? ?def vecme(functions, data, indicies):
> ? ? ? ?return functions[indicies](data)
> ? ?v= np.vectorize(vecme)
> ? ?def how(indicies):
> ? ? ? ?return np.asarray(v(functions, data, indicies)).T
> ? ?return how
>
> ## end relevant part
> # rest is just some context where hows could be applied
> def stream(m, n):
> ? ?""" mimic some external stream of 0\ 1 indicators"""
> ? ?np.random.seed(123)
> ? ?ind= np.asarray(np.random.randint(0, 2, (m, n)), dtype= bool)
> ? ?for k in xrange(m):
> ? ? ? ?yield ind[k, :]
>
> def process(stream, how):
> ? ?""" consume stream"""
> ? ?for ind in stream:
> ? ? ? ?yield how(ind)
>
> def run(hows, n):
> ? ?"""run the hows"""
> ? ?for app in hows.keys():
> ? ? ? ?print 'approach:', app
> ? ? ? ?for r in process(stream(3, n), hows[app]):
> ? ? ? ? ? ?print np.round(r.squeeze(), 2)
>
> if __name__ == '__main__':
> ? ?# some data and functions only as demonstration
> ? ?data= np.random.random((3, 1))
> ? ?fncs= np.asarray([np.sin, np.cos, np.tan, np.sinh, np.cosh, np.tanh])
>
> ? ?# produce equivalent results
> ? ?hows= {'firsth': how1(fncs, data),
> ? ? ? ? ? 'second': how2(fncs, data)}
> # ? ? ? ? ? 'third': how3(fncs, data)}
> ? ?run(hows, len(fncs))
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From jsseabold at gmail.com  Wed Mar 10 16:09:12 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Wed, 10 Mar 2010 16:09:12 -0500
Subject: [SciPy-Dev] Why does optimize.nonlin take a tuple for func to
	optimize?
Message-ID: <c048da1c1003101309i14819365ie591972ebeccbc2e@mail.gmail.com>

I am curious why optimize.nonlin expects a tuple for the function to
optimize?  This seems inconsistent with the other optimize methods I
have used in optimize.

http://docs.scipy.org/scipy/docs/scipy.optimize.nonlin/

Are there any objections to changing this to be more consistent with
the other solvers which take something like (F, x0, args=()) and use
optimize.wrap_function for the function to be optimized?  Perhaps
there is something I am missing.

-Skipper


From pav at iki.fi  Wed Mar 10 16:47:52 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 10 Mar 2010 23:47:52 +0200
Subject: [SciPy-Dev] Why does optimize.nonlin take a tuple for func to
	optimize?
In-Reply-To: <c048da1c1003101309i14819365ie591972ebeccbc2e@mail.gmail.com>
References: <c048da1c1003101309i14819365ie591972ebeccbc2e@mail.gmail.com>
Message-ID: <1268257672.4782.2.camel@idol>

ke, 2010-03-10 kello 16:09 -0500, Skipper Seabold kirjoitti:
> I am curious why optimize.nonlin expects a tuple for the function to
> optimize?  This seems inconsistent with the other optimize methods I
> have used in optimize.
> 
> http://docs.scipy.org/scipy/docs/scipy.optimize.nonlin/
> 
> Are there any objections to changing this to be more consistent with
> the other solvers which take something like (F, x0, args=()) and use
> optimize.wrap_function for the function to be optimized?  Perhaps
> there is something I am missing.

The nonlin module requires significant cleanup. I did some work last
spring on this, but didn't have time to finish it up fully.
http://codereview.appspot.com/62059/show
http://codereview.appspot.com/52096/show

The main holdup is the refactoring of line searches, and ensuring this
does not break anything, plus the overall design of the new nonlin
interfaces.

-- 
Pauli Virtanen




From jsseabold at gmail.com  Wed Mar 10 17:08:36 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Wed, 10 Mar 2010 17:08:36 -0500
Subject: [SciPy-Dev] Why does optimize.nonlin take a tuple for func to
	optimize?
In-Reply-To: <1268257672.4782.2.camel@idol>
References: <c048da1c1003101309i14819365ie591972ebeccbc2e@mail.gmail.com> 
	<1268257672.4782.2.camel@idol>
Message-ID: <c048da1c1003101408j290186aet34511860804db1ed@mail.gmail.com>

On Wed, Mar 10, 2010 at 4:47 PM, Pauli Virtanen <pav at iki.fi> wrote:
> ke, 2010-03-10 kello 16:09 -0500, Skipper Seabold kirjoitti:
>> I am curious why optimize.nonlin expects a tuple for the function to
>> optimize? ?This seems inconsistent with the other optimize methods I
>> have used in optimize.
>>
>> http://docs.scipy.org/scipy/docs/scipy.optimize.nonlin/
>>
>> Are there any objections to changing this to be more consistent with
>> the other solvers which take something like (F, x0, args=()) and use
>> optimize.wrap_function for the function to be optimized? ?Perhaps
>> there is something I am missing.
>
> The nonlin module requires significant cleanup. I did some work last
> spring on this, but didn't have time to finish it up fully.
> http://codereview.appspot.com/62059/show
> http://codereview.appspot.com/52096/show
>
> The main holdup is the refactoring of line searches, and ensuring this
> does not break anything, plus the overall design of the new nonlin
> interfaces.
>

Yes, nonlin seems to be a bit baffling to me.  Ok, I see your ticket
now.  http://projects.scipy.org/scipy/ticket/791

I'm afraid I don't know enough about these things to be of much help
in the short term.  I was just trying to use broyden for a penalized
maximum likelihood.  Would it help to write some regression tests
using your branch to ensure that linesearch refactoring doesn't break
anything else?

Skipper


From denis-bz-py at t-online.de  Wed Mar 10 13:16:21 2010
From: denis-bz-py at t-online.de (denis)
Date: Wed, 10 Mar 2010 19:16:21 +0100
Subject: [SciPy-Dev] linalg.solveh_banded => Mac OS BLAS parameter error in
	DPBSV
Message-ID: <hn8nlm$9l8$1@dough.gmane.org>

Folks,
   has anyone run solveh_banded on a mac ppc ?
My versions: scipy 0.7.1 numpy 1.3.0 py 2.6.4 macosx 10.4.11

If this is the wrong place or wrong form, please correct me.


# scipy.linalg.solveh_banded =>
# Parameter 8 to routine DPBSV  was incorrect
# Mac OS BLAS parameter error in DPBSV , parameter #0, (unavailable), is 0
# 144208 26 Jun  2009 _flinalg.so
# (solve_banded is in scipy/linalg/tests, solveh_banded not ...)

import sys
import numpy as np
from scipy.linalg import solve_banded, solveh_banded

N = 10
exec "\n".join( sys.argv[1:] )  # N= ...
np.random.seed(1)
np.set_printoptions( 2, threshold=100, suppress=True )  # .2f

ones = np.ones(N)
ab = np.array(( ones, 2*ones )) / 4
# ab = np.array(( ones, 2*ones, ones )) / 4
b = np.random.normal( 0, 1, N )
print "ab:", ab
print "b:", b

c, x = solveh_banded( ab, b )  # , lower=1 )
     # x = solve_banded( (1,1), ab, b )  # ok
print "x:", x

Thanks, cheers
   -- denis



From lists at onerussian.com  Fri Mar 12 09:42:02 2010
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Fri, 12 Mar 2010 09:42:02 -0500
Subject: [SciPy-Dev] few patches for your consideration
Message-ID: <20100312144202.GN8332@onerussian.com>

Hi Everyone,

Being lazy and git spoiled I am exposing tentative BUG: and  ENH:
commits upon your consideration:

http://github.com/yarikoptic/scipy3/commit/0cef22c0342faf8e70d84dd4008dc5ee44f365d4
BUG: use correct string formatting in raising depending on info from lapack

http://github.com/yarikoptic/scipy3/commit/4feb14edcb9d6efdb307fc14c351aab41bad69f4
ENH: a bit more of information upon failure in LinAlgError's from lapack

P.S. If I get a RW commit to SVN I would be happy to dcommit, or if you
instruct so I could file 'Pull request' into David's github clone, but since it
is just git-svned, not sure if it wouldn't create more problems than would
provide benefits.

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]




From jpscipy at gmail.com  Fri Mar 12 17:18:05 2010
From: jpscipy at gmail.com (J P)
Date: Fri, 12 Mar 2010 15:18:05 -0700
Subject: [SciPy-Dev] Seeking help/ advice for applying functions
In-Reply-To: <ce557a361003091012n35c7db65o27c1a72c70dfd639@mail.gmail.com>
References: <loom.20100306T004849-522@post.gmane.org>
	<3d375d731003081224g25901ddcrcbe63ddddeef6db3@mail.gmail.com>
	<loom.20100309T155757-217@post.gmane.org>
	<ce557a361003091012n35c7db65o27c1a72c70dfd639@mail.gmail.com>
Message-ID: <1741e14d1003121418s543060bck95d92317a4d7848d@mail.gmail.com>

If your data is that sparse (1 per 100 nonzero elements) then your biggest
computational savings would probably be to use sparse matrices.

On Tue, Mar 9, 2010 at 11:12 AM, Anne Archibald
<peridot.faceted at gmail.com>wrote:

> On 9 March 2010 09:59, eat <e.antero.tammi at gmail.com> wrote:
> > Robert Kern <robert.kern <at> gmail.com> writes:
> >
> >>
> >> Your example is not very clear. Can you write a less cryptic one with
> >> informative variable names and perhaps some comments about what each
> >> part is doing?
> >>
> >
> > """
> > Hi,
> >
> > I have tried to clarify my code. First part is the relevant one, the rest
> is
> > there just to provide some context to run some tests.
>
> The short answer is that no, there's no way to optimize what you're doing.
>
> The long answer is: when numpy and scipy are fast, they are fast
> because they avoid running python code: if you add two arrays, there's
> only one line of python code, and all the work is done by loops
> written in C. If your code is calling many different python functions,
> well, since they're python functions, to apply them at all you must
> necessarily execute python code. There goes any potential speed
> advantage. (There may be a convenience advantage; if so, you can look
> into using np.vectorize, which is just a wrapper around a python loop,
> but is convenient.)
>
> That said, I assume you are considering numpy/scipy because you have
> arrays of thousands or more. It also seems unlikely that you actually
> have thousands of different functions (that's an awful lot of source
> code!). So if your "different" functions are actually just a handful
> (or fewer) pieces of actual code, and you are getting your thousands
> of functions by wrapping them up with parameters and local variables,
> well, now there are possibilities. Exactly what possibilities depend
> on what your functions look like - which is one reason Robert Kern
> asked you to clarify your code - but they all boil down to rearranging
> the problem so that it goes back to "few functions, much data", then
> writing the functions in such a way that you can use numpy to apply
> them to thousands or millions of data points at once.
>
> > Also originally I should have posted this to Scipy-User list. Would it be
> > more appropriate to continue the discussion there?
>
> Probably.
>
>
> Anne
>
> > Regards,
> > eat
> > """
> >
> > import numpy as np
> >
> > ## relevant part
> > # expect indicies to be sparse ~1% but hundred of thousands of elements
> > # also functions not necessary builtins and data may be large
> > def how1(functions, data):
> >    """ firsth approach to apply data to functions"""
> >    def how(indicies):
> >        return np.asarray([f(data) for f in functions[indicies]]).T
> >    return how
> >
> >
> > def how2(functions, data):
> >    """ second approach to apply data to functions"""
> >    def rr(data):
> >        """ reverse the 'roles' of data and function"""
> >        def f(g):
> >            return g(data)
> >        return f
> >    daf= rr(data)
> >    def how(indicies):
> >        return np.asarray(map(daf, functions[indicies])).T
> >    return how
> >
> > # as I understand it, how1 and how2 boils down under the hood pretty
> > # much to the same code, so only syntatical differencies, right?
> >
> > # and this is the key question: does there exist a more suitable
> > # scipy/ numpy solution for this situation?
> >
> > # perhaps some kind of special vectorization as below (as pseudo code)?
> > def how3(functions, data):
> >    """ third approach to apply data to functions"""
> >    def vecme(functions, data, indicies):
> >        return functions[indicies](data)
> >    v= np.vectorize(vecme)
> >    def how(indicies):
> >        return np.asarray(v(functions, data, indicies)).T
> >    return how
> >
> > ## end relevant part
> > # rest is just some context where hows could be applied
> > def stream(m, n):
> >    """ mimic some external stream of 0\ 1 indicators"""
> >    np.random.seed(123)
> >    ind= np.asarray(np.random.randint(0, 2, (m, n)), dtype= bool)
> >    for k in xrange(m):
> >        yield ind[k, :]
> >
> > def process(stream, how):
> >    """ consume stream"""
> >    for ind in stream:
> >        yield how(ind)
> >
> > def run(hows, n):
> >    """run the hows"""
> >    for app in hows.keys():
> >        print 'approach:', app
> >        for r in process(stream(3, n), hows[app]):
> >            print np.round(r.squeeze(), 2)
> >
> > if __name__ == '__main__':
> >    # some data and functions only as demonstration
> >    data= np.random.random((3, 1))
> >    fncs= np.asarray([np.sin, np.cos, np.tan, np.sinh, np.cosh, np.tanh])
> >
> >    # produce equivalent results
> >    hows= {'firsth': how1(fncs, data),
> >           'second': how2(fncs, data)}
> > #           'third': how3(fncs, data)}
> >    run(hows, len(fncs))
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100312/d1c9d56e/attachment.html>

From cohen at lpta.in2p3.fr  Sat Mar 13 15:55:52 2010
From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi)
Date: Sat, 13 Mar 2010 21:55:52 +0100
Subject: [SciPy-Dev] ImportError: No module named ipapp
Message-ID: <4B9BFBD8.8020905@lpta.in2p3.fr>

Hi Brian, thanks for your help, see below my still being confused :

<quote author="Brian Granger-3">
Hi,

 > I have an identical problem : I have a trunk build of ipython, that I
 > installed with --user, and then today I wanted to have a look at the 
bundle
 > EPD distribution. I thought that the whole point was that I could get a
 > completely "waterproof" distribution with EPD, irrespective of any other
 > development version of say ipython on my system.
 >
 > EPD, is like any other Python installation in terms of how it 
resolves and finds
 > Python packages.  When you install EPD, it sets your PATH variables 
to point
 > to its python, ipython, etc scripts.  BUT, Python 2.6 still uses the
 > --user location
 > to find packages.  Thus, you have the following problem:
 >
 > * /home/cohen/sources/python/epd-6.1-1-rh5-x86/bin/ipython is first 
on your
 > path, so when you type ipython at the command line,  that script starts.
 >
 > * But when that script tries to "from IPython.ipapi import 
launch_new_instance"
 > Python goes and finds the IPython package in the --user location, 
which is the
 > wrong version of IPython (trunk doesn't have launch_new_instance).

-> Ok that is where I am being confused. The trunk ipython with the 
--user has been built/installed with the native python, while the EPD 
ipython is supposed to call the EPD python shipped in. I was expecting 
that things would be messed up *if* I had a PYTHONPATH env var 
installed, because this would be read by either instance. Thus I made 
sure to unset PYTHONPATH..... but it seems that something else keeps 
been share....
Isn't there any way to keep these two python instances completely 
separate within one system?

thanks for the clarification, this is a bit disappointing to me :(
Johann

 > So you must:
 >
 > * Install trunk IPython into EPD so that its "ipython" script points
 > to the trunk version.
 > * Set your PATH differently so that the trunk "ipython" script is
 > found before the EPD
 > version.
 > * Uninstall the trunk version of IPython.
 >
 > Hope this helps,
 >
 > Cheers,
 >
 > Brian

 > But I get:
 > [cohen at jarrett ~]$ 
/home/cohen/sources/python/epd-6.1-1-rh5-x86/bin/ipython
 > Traceback (most recent call last):
 >   File "/home/cohen/sources/python/epd-6.1-1-rh5-x86/bin/ipython", 
line 7,
 > in <module>
 >     from IPython.ipapi import launch_new_instance
 > ImportError: No module named ipapi
 >
 > if I rename .local as local, then the EPD version loads ok.... Isn't 
there a
 > way to keep both functioning?
 >
 > thanks,
 > Johann
 >
 > On 02/10/2010 05:34 AM, Brian Granger wrote:
 >
 > Can you try removing all traces of ipython (both from bin dirs and
 > site-packages) and reinstall.  It looks like you have multiple 
versions on
 > your PATH/PYTHONPATH that are conflicting.
 >
 > Cheers,
 >
 > Brian
 >
 >
 >
 > On Tue, Feb 9, 2010 at 11:22 AM, Nils Wagner 
<nwagner at iam.uni-stuttgart.de>
 > wrote:
 >>
 >> Hi all,
 >>
 >> I have installed ipython from scratch
 >>
 >> bzr branch lp:ipython
 >> cd ipython
 >> python setup.py install --prefix=$HOME/local
 >>
 >> If I start ipython
 >>
 >> ipython
 >> Traceback (most recent call last):
 >>   File "/home/nwagner/local/bin/ipython", line 4, in
 >> <module>
 >>     from IPython.core.ipapp import launch_new_instance
 >> ImportError: No module named ipapp
 >>
 >> Any idea ?
 >>
 >>            Nils
 >> _______________________________________________
 >> IPython-dev mailing list
 >> IPython-dev at scipy.org
 >> http://mail.scipy.org/mailman/listinfo/ipython-dev
 >
 >
 > --
 > This message has been scanned for viruses and
 > dangerous content by MailScanner, and is
 > believed to be clean.
 >
 > _______________________________________________
 > IPython-dev mailing list
 > IPython-dev at scipy.org
 > http://mail.scipy.org/mailman/listinfo/ipython-dev
 >
 >
 > _______________________________________________
 > IPython-dev mailing list
 > IPython-dev at scipy.org
 > http://mail.scipy.org/mailman/listinfo/ipython-dev
 >
 >



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev

</quote>



From rob.clewley at gmail.com  Mon Mar 15 19:05:44 2010
From: rob.clewley at gmail.com (Rob Clewley)
Date: Mon, 15 Mar 2010 19:05:44 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info in
	ref guide
Message-ID: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>

Hi,

In both my old version and the one in the svn trunk there is an
inconsistency in the docstring of scipy.optimize.fmin.

    Other Parameters
    ----------------
    xtol : float
        Relative error in xopt acceptable for convergence.
    ftol : number
        Relative error in func(xopt) acceptable for convergence.

As you see from the following code snippet from the body of the
function, the convergence test is in terms of absolute error for both
x and f, as the sim array contains x values and fsim the function
values.

    if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
                and max(abs(fsim[0]-fsim[1:])) <= ftol):
        break

Also, optional parameters for any optimize functions are not described
in the draft of the Scipy reference manual I came across while
googling this issue. For instance, at

http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin

fmin does not have the optional arguments detailed. If this is
automatically generated is there a reason why the optional parameters
aren't being shown in this document? I think they should be, IMO.

-Rob


From josef.pktd at gmail.com  Mon Mar 15 19:13:50 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 15 Mar 2010 19:13:50 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
Message-ID: <1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>

On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
> Hi,
>
> In both my old version and the one in the svn trunk there is an
> inconsistency in the docstring of scipy.optimize.fmin.
>
> ? ?Other Parameters
> ? ?----------------
> ? ?xtol : float
> ? ? ? ?Relative error in xopt acceptable for convergence.
> ? ?ftol : number
> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>
> As you see from the following code snippet from the body of the
> function, the convergence test is in terms of absolute error for both
> x and f, as the sim array contains x values and fsim the function
> values.
>
> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
> ? ? ? ?break
>
> Also, optional parameters for any optimize functions are not described
> in the draft of the Scipy reference manual I came across while
> googling this issue. For instance, at
>
> http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin
>
> fmin does not have the optional arguments detailed. If this is
> automatically generated is there a reason why the optional parameters
> aren't being shown in this document? I think they should be, IMO.

just a guess:

http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/

shows that Other Parameters is in the wrong order. It could be that
the section is ignored for rendering the html for this reason

Josef


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


From d.l.goldsmith at gmail.com  Mon Mar 15 19:41:10 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 15 Mar 2010 16:41:10 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
Message-ID: <45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>

I'll look into both problems.

DG

On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd at gmail.com> wrote:

> On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley at gmail.com>
> wrote:
> > Hi,
> >
> > In both my old version and the one in the svn trunk there is an
> > inconsistency in the docstring of scipy.optimize.fmin.
> >
> >    Other Parameters
> >    ----------------
> >    xtol : float
> >        Relative error in xopt acceptable for convergence.
> >    ftol : number
> >        Relative error in func(xopt) acceptable for convergence.
> >
> > As you see from the following code snippet from the body of the
> > function, the convergence test is in terms of absolute error for both
> > x and f, as the sim array contains x values and fsim the function
> > values.
> >
> >    if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
> >                and max(abs(fsim[0]-fsim[1:])) <= ftol):
> >        break
> >
> > Also, optional parameters for any optimize functions are not described
> > in the draft of the Scipy reference manual I came across while
> > googling this issue. For instance, at
> >
> >
> http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin
> >
> > fmin does not have the optional arguments detailed. If this is
> > automatically generated is there a reason why the optional parameters
> > aren't being shown in this document? I think they should be, IMO.
>
> just a guess:
>
> http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
>
> shows that Other Parameters is in the wrong order. It could be that
> the section is ignored for rendering the html for this reason
>
> Josef
>
>
> >
> > -Rob
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100315/adfcf91b/attachment.html>

From d.l.goldsmith at gmail.com  Mon Mar 15 19:50:34 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 15 Mar 2010 16:50:34 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
	<45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>
Message-ID: <45d1ab481003151650w2d689b8at7c7020c2b7726ef0@mail.gmail.com>

This is *very* bizarre: in View mode, Other parameters is displayed before
Returns, but in the edit frame in Edit mode, Returns is displayed above
Other parameters, but then if I preview, the preview displays it
incorrectly, even though in the edit frame, it's still correct!!!  Can
someone verify this on another platform/in another browser, please?  (Mine:
Windows Vista, Firefox 3.6).  Thanks!

DG

On Mon, Mar 15, 2010 at 4:41 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> I'll look into both problems.
>
> DG
>
>
> On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd at gmail.com> wrote:
>
>> On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > In both my old version and the one in the svn trunk there is an
>> > inconsistency in the docstring of scipy.optimize.fmin.
>> >
>> >    Other Parameters
>> >    ----------------
>> >    xtol : float
>> >        Relative error in xopt acceptable for convergence.
>> >    ftol : number
>> >        Relative error in func(xopt) acceptable for convergence.
>> >
>> > As you see from the following code snippet from the body of the
>> > function, the convergence test is in terms of absolute error for both
>> > x and f, as the sim array contains x values and fsim the function
>> > values.
>> >
>> >    if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>> >                and max(abs(fsim[0]-fsim[1:])) <= ftol):
>> >        break
>> >
>> > Also, optional parameters for any optimize functions are not described
>> > in the draft of the Scipy reference manual I came across while
>> > googling this issue. For instance, at
>> >
>> >
>> http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin
>> >
>> > fmin does not have the optional arguments detailed. If this is
>> > automatically generated is there a reason why the optional parameters
>> > aren't being shown in this document? I think they should be, IMO.
>>
>> just a guess:
>>
>> http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
>>
>> shows that Other Parameters is in the wrong order. It could be that
>> the section is ignored for rendering the html for this reason
>>
>> Josef
>>
>>
>> >
>> > -Rob
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100315/8a54ca36/attachment.html>

From ralf.gommers at googlemail.com  Mon Mar 15 20:13:30 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 16 Mar 2010 08:13:30 +0800
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003151650w2d689b8at7c7020c2b7726ef0@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
	<45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>
	<45d1ab481003151650w2d689b8at7c7020c2b7726ef0@mail.gmail.com>
Message-ID: <dde7764a1003151713u2d9c5c9bn711a629fbb8074c7@mail.gmail.com>

On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> This is *very* bizarre: in View mode, Other parameters is displayed before
> Returns, but in the edit frame in Edit mode, Returns is displayed above
> Other parameters, but then if I preview, the preview displays it
> incorrectly, even though in the edit frame, it's still correct!!!  Can
> someone verify this on another platform/in another browser, please?  (Mine:
> Windows Vista, Firefox 3.6).  Thanks!
>
> Not that bizarre. The rendered version simply always looks the same, and
assumes that Other Params belongs before instead of after Returns. The doc
standard simply disagrees with pydocweb here. I don't have a strong opinion
on which one is preferable, but it should be fixed.

Cheers,
Ralf


>> On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd at gmail.com> wrote:
>>
>>> On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > In both my old version and the one in the svn trunk there is an
>>> > inconsistency in the docstring of scipy.optimize.fmin.
>>> >
>>> >    Other Parameters
>>> >    ----------------
>>> >    xtol : float
>>> >        Relative error in xopt acceptable for convergence.
>>> >    ftol : number
>>> >        Relative error in func(xopt) acceptable for convergence.
>>> >
>>> > As you see from the following code snippet from the body of the
>>> > function, the convergence test is in terms of absolute error for both
>>> > x and f, as the sim array contains x values and fsim the function
>>> > values.
>>> >
>>> >    if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>> >                and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>> >        break
>>> >
>>> > Also, optional parameters for any optimize functions are not described
>>> > in the draft of the Scipy reference manual I came across while
>>> > googling this issue. For instance, at
>>> >
>>> >
>>> http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin
>>> >
>>> > fmin does not have the optional arguments detailed. If this is
>>> > automatically generated is there a reason why the optional parameters
>>> > aren't being shown in this document? I think they should be, IMO.
>>>
>>> just a guess:
>>>
>>> http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
>>>
>>> shows that Other Parameters is in the wrong order. It could be that
>>> the section is ignored for rendering the html for this reason
>>>
>>> Josef
>>>
>>>
>>> >
>>> > -Rob
>>> > _______________________________________________
>>> > SciPy-Dev mailing list
>>> > SciPy-Dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100316/02357dad/attachment.html>

From josef.pktd at gmail.com  Mon Mar 15 20:22:32 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 15 Mar 2010 20:22:32 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <dde7764a1003151713u2d9c5c9bn711a629fbb8074c7@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
	<45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>
	<45d1ab481003151650w2d689b8at7c7020c2b7726ef0@mail.gmail.com>
	<dde7764a1003151713u2d9c5c9bn711a629fbb8074c7@mail.gmail.com>
Message-ID: <1cd32cbb1003151722n1c5353d0ya0a0643b40b81e10@mail.gmail.com>

On Mon, Mar 15, 2010 at 8:13 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <d.l.goldsmith at gmail.com>
> wrote:
>>
>> This is *very* bizarre: in View mode, Other parameters is displayed before
>> Returns, but in the edit frame in Edit mode, Returns is displayed above
>> Other parameters, but then if I preview, the preview displays it
>> incorrectly, even though in the edit frame, it's still correct!!!? Can
>> someone verify this on another platform/in another browser, please?? (Mine:
>> Windows Vista, Firefox 3.6).? Thanks!
>>
> Not that bizarre. The rendered version simply always looks the same, and
> assumes that Other Params belongs before instead of after Returns. The doc
> standard simply disagrees with pydocweb here. I don't have a strong opinion
> on which one is preferable, but it should be fixed.

Independent of the display, the other parameters section doesn't show
up in the html docs.

The only example that I found in numpy is recarrays, there the
sequence is reversed but it also doesn't show up in the html

http://docs.scipy.org/numpy/docs/numpy.core.records.recarray/

http://docs.scipy.org/doc/numpy/reference/generated/numpy.recarray.html?highlight=recarray#numpy.recarray

Josef


>
> Cheers,
> Ralf
>
>>>
>>> On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd at gmail.com> wrote:
>>>>
>>>> On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley at gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > In both my old version and the one in the svn trunk there is an
>>>> > inconsistency in the docstring of scipy.optimize.fmin.
>>>> >
>>>> > ? ?Other Parameters
>>>> > ? ?----------------
>>>> > ? ?xtol : float
>>>> > ? ? ? ?Relative error in xopt acceptable for convergence.
>>>> > ? ?ftol : number
>>>> > ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>>>> >
>>>> > As you see from the following code snippet from the body of the
>>>> > function, the convergence test is in terms of absolute error for both
>>>> > x and f, as the sim array contains x values and fsim the function
>>>> > values.
>>>> >
>>>> > ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>>> > ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>>> > ? ? ? ?break
>>>> >
>>>> > Also, optional parameters for any optimize functions are not described
>>>> > in the draft of the Scipy reference manual I came across while
>>>> > googling this issue. For instance, at
>>>> >
>>>> >
>>>> > http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin
>>>> >
>>>> > fmin does not have the optional arguments detailed. If this is
>>>> > automatically generated is there a reason why the optional parameters
>>>> > aren't being shown in this document? I think they should be, IMO.
>>>>
>>>> just a guess:
>>>>
>>>> http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
>>>>
>>>> shows that Other Parameters is in the wrong order. It could be that
>>>> the section is ignored for rendering the html for this reason
>>>>
>>>> Josef
>>>>
>>>>
>>>> >
>>>> > -Rob
>>>> > _______________________________________________
>>>> > SciPy-Dev mailing list
>>>> > SciPy-Dev at scipy.org
>>>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>> >
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From d.l.goldsmith at gmail.com  Mon Mar 15 23:43:41 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 15 Mar 2010 20:43:41 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <dde7764a1003151713u2d9c5c9bn711a629fbb8074c7@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
	<45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>
	<45d1ab481003151650w2d689b8at7c7020c2b7726ef0@mail.gmail.com>
	<dde7764a1003151713u2d9c5c9bn711a629fbb8074c7@mail.gmail.com>
Message-ID: <45d1ab481003152043s69987e91wc25234ef9d3876d3@mail.gmail.com>

On Mon, Mar 15, 2010 at 5:13 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:
>
>> This is *very* bizarre: in View mode, Other parameters is displayed before
>> Returns, but in the edit frame in Edit mode, Returns is displayed above
>> Other parameters, but then if I preview, the preview displays it
>> incorrectly, even though in the edit frame, it's still correct!!!  Can
>> someone verify this on another platform/in another browser, please?  (Mine:
>> Windows Vista, Firefox 3.6).  Thanks!
>>
>> Not that bizarre. The rendered version simply always looks the same, and
> assumes that Other Params belongs before instead of after Returns. The doc
> standard simply disagrees with pydocweb here. I don't have a strong opinion
> on which one is preferable, but it should be fixed.
>

Right, I forgot that I myself reported this as a ticketed known problem in
the Q&A section.  So that half the problem is (un)solved. :-(

DG

>
> Cheers,
> Ralf
>
>
>>> On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd at gmail.com> wrote:
>>>
>>>> On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley at gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > In both my old version and the one in the svn trunk there is an
>>>> > inconsistency in the docstring of scipy.optimize.fmin.
>>>> >
>>>> >    Other Parameters
>>>> >    ----------------
>>>> >    xtol : float
>>>> >        Relative error in xopt acceptable for convergence.
>>>> >    ftol : number
>>>> >        Relative error in func(xopt) acceptable for convergence.
>>>> >
>>>> > As you see from the following code snippet from the body of the
>>>> > function, the convergence test is in terms of absolute error for both
>>>> > x and f, as the sim array contains x values and fsim the function
>>>> > values.
>>>> >
>>>> >    if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>>> >                and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>>> >        break
>>>> >
>>>> > Also, optional parameters for any optimize functions are not described
>>>> > in the draft of the Scipy reference manual I came across while
>>>> > googling this issue. For instance, at
>>>> >
>>>> >
>>>> http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html#scipy.optimize.fmin
>>>> >
>>>> > fmin does not have the optional arguments detailed. If this is
>>>> > automatically generated is there a reason why the optional parameters
>>>> > aren't being shown in this document? I think they should be, IMO.
>>>>
>>>> just a guess:
>>>>
>>>> http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
>>>>
>>>> shows that Other Parameters is in the wrong order. It could be that
>>>> the section is ignored for rendering the html for this reason
>>>>
>>>> Josef
>>>>
>>>>
>>>> >
>>>> > -Rob
>>>> > _______________________________________________
>>>> > SciPy-Dev mailing list
>>>> > SciPy-Dev at scipy.org
>>>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>> >
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100315/0a3cc3b0/attachment.html>

From ralf.gommers at googlemail.com  Tue Mar 16 11:16:53 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 16 Mar 2010 23:16:53 +0800
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <1cd32cbb1003151722n1c5353d0ya0a0643b40b81e10@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<1cd32cbb1003151613i62848fd0vcf02bd4b66a141a2@mail.gmail.com>
	<45d1ab481003151641g280fd51cjc85b1e9f24038221@mail.gmail.com>
	<45d1ab481003151650w2d689b8at7c7020c2b7726ef0@mail.gmail.com>
	<dde7764a1003151713u2d9c5c9bn711a629fbb8074c7@mail.gmail.com>
	<1cd32cbb1003151722n1c5353d0ya0a0643b40b81e10@mail.gmail.com>
Message-ID: <dde7764a1003160816h7bb83c8an6cd4cedd23ff1291@mail.gmail.com>

On Tue, Mar 16, 2010 at 8:22 AM, <josef.pktd at gmail.com> wrote:

> On Mon, Mar 15, 2010 at 8:13 PM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> >
> >
> > On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <
> d.l.goldsmith at gmail.com>
> > wrote:
> >>
> >> This is *very* bizarre: in View mode, Other parameters is displayed
> before
> >> Returns, but in the edit frame in Edit mode, Returns is displayed above
> >> Other parameters, but then if I preview, the preview displays it
> >> incorrectly, even though in the edit frame, it's still correct!!!  Can
> >> someone verify this on another platform/in another browser, please?
> (Mine:
> >> Windows Vista, Firefox 3.6).  Thanks!
> >>
> > Not that bizarre. The rendered version simply always looks the same, and
> > assumes that Other Params belongs before instead of after Returns. The
> doc
> > standard simply disagrees with pydocweb here. I don't have a strong
> opinion
> > on which one is preferable, but it should be fixed.
>
> Independent of the display, the other parameters section doesn't show
> up in the html docs.
>

Yes that seems to be a bug. I added this to the related pydocweb problem
with section ordering here:
http://code.google.com/p/pydocweb/issues/detail?id=45


>
> The only example that I found in numpy is recarrays, there the
> sequence is reversed but it also doesn't show up in the html
>
> http://docs.scipy.org/numpy/docs/numpy.core.records.recarray/
>
>
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.recarray.html?highlight=recarray#numpy.recarray
>
> There's an issue with section headers there as well because recarray is a
class and is not supposed to have a Returns section. So don't think that
tells you anything.

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

From dwf at cs.toronto.edu  Thu Mar 18 14:55:08 2010
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Thu, 18 Mar 2010 14:55:08 -0400
Subject: [SciPy-Dev] restarting the discussion about sparse SVD
Message-ID: <B2C245E1-7CF8-442E-9AC7-F337FBE420B7@cs.toronto.edu>

A friend of mine yesterday was a bit shocked/annoyed when he realized  
there was no way currently in SciPy to compute the SVD of a sparse  
matrix.

This has come up a number of times, so maybe we should organize our  
thoughts and figure out what exactly needs to get done.

- I remember hearing that ARPACK contained a sparse SVD routine but I  
can't seem to find mention of it in the docs.

- It also looks like the code in Divisi ( http:// 
divisi.media.mit.edu ) would be helpful, and looking in the archives   
it looks like the authors may be receptive to relicensing bits of it  
for use in SciPy.

Other thoughts?

David


From cournape at gmail.com  Fri Mar 19 00:41:15 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 18 Mar 2010 23:41:15 -0500
Subject: [SciPy-Dev] restarting the discussion about sparse SVD
In-Reply-To: <B2C245E1-7CF8-442E-9AC7-F337FBE420B7@cs.toronto.edu>
References: <B2C245E1-7CF8-442E-9AC7-F337FBE420B7@cs.toronto.edu>
Message-ID: <5b8d13221003182141yb3c616fg9c0b2489ec849e90@mail.gmail.com>

On Thu, Mar 18, 2010 at 1:55 PM, David Warde-Farley <dwf at cs.toronto.edu> wrote:
> A friend of mine yesterday was a bit shocked/annoyed when he realized
> there was no way currently in SciPy to compute the SVD of a sparse
> matrix.

It is actually not true anymore, I have added a simple sparse svd
based on arpack in scipy.sparse.linalg.eigen.arpack, but there is no
support for complex, etc...

> - I remember hearing that ARPACK contained a sparse SVD routine but I
> can't seem to find mention of it in the docs.

As far as I could see, ARPACK itself does not have SVD: the simple
example of computing SVD in arpack sources uses the eigensolver on
A'A. There are better techniques to do SVD on sparse matrix (PROPACK,
based on tri-diagonalization without intermediate A'A).

> - It also looks like the code in Divisi ( http://
> divisi.media.mit.edu ) would be helpful, and looking in the archives
> it looks like the authors may be receptive to relicensing bits of it
> for use in SciPy.

I think ARPACK is better (uses more recent techniques than SVDPACK, as
used in Divisi). The other technique (gradient-based) is not a "real"
SVD, but could still be useful,

David


From matthew.brett at gmail.com  Fri Mar 19 13:50:22 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 19 Mar 2010 10:50:22 -0700
Subject: [SciPy-Dev] Spherical harmonics, convention
Message-ID: <1e2af89e1003191050k1affc407if867f91eebf50e29@mail.gmail.com>

Hi,

I noticed that scipy.special.sph_harm uses conventions that (on
superficial reading) seem to be rather unusual; can I ask for advice
whether that is correct?

For example; http://en.wikipedia.org/wiki/Spherical_harmonics assumes:

theta = polar angle
phi = azimuthal angle
l (little L) = degree of harmonic

but we have:

theta = azimuthal angle
phi = polar angle
n = degree of harmonic

I realize that the theta / phi switch is the difference between
physics and math conventions of spherical coordinates, but my
superficial impression was that there was a rather strong tradition in
spherical harmonics to prefer theta = polar, phi = azimuthal; is that
correct?

Thanks a lot,

Matthew


From d.l.goldsmith at gmail.com  Fri Mar 19 15:16:29 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 19 Mar 2010 12:16:29 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
Message-ID: <45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>

On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
> Hi,
>
> In both my old version and the one in the svn trunk there is an
> inconsistency in the docstring of scipy.optimize.fmin.
>
> ? ?Other Parameters
> ? ?----------------
> ? ?xtol : float
> ? ? ? ?Relative error in xopt acceptable for convergence.
> ? ?ftol : number
> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>
> As you see from the following code snippet from the body of the
> function, the convergence test is in terms of absolute error for both
> x and f, as the sim array contains x values and fsim the function
> values.
>
> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
> ? ? ? ?break

OK, folks, so what's the _desired_ behavior: absolute or relative
error (i.e., where's the bug: in the code or in the doc)?

DG


From josef.pktd at gmail.com  Fri Mar 19 15:37:05 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 19 Mar 2010 15:37:05 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
Message-ID: <1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>

On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
>> Hi,
>>
>> In both my old version and the one in the svn trunk there is an
>> inconsistency in the docstring of scipy.optimize.fmin.
>>
>> ? ?Other Parameters
>> ? ?----------------
>> ? ?xtol : float
>> ? ? ? ?Relative error in xopt acceptable for convergence.
>> ? ?ftol : number
>> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>>
>> As you see from the following code snippet from the body of the
>> function, the convergence test is in terms of absolute error for both
>> x and f, as the sim array contains x values and fsim the function
>> values.
>>
>> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
>> ? ? ? ?break
>
> OK, folks, so what's the _desired_ behavior: absolute or relative
> error (i.e., where's the bug: in the code or in the doc)?

I think the docs should reflect the actual behavior of the function.
Whether the criteria will be changed and made consistent across
functions is a different question. But it's not a bug, so the docs
should adjust.

my opinion

Josef

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


From d.l.goldsmith at gmail.com  Fri Mar 19 16:05:02 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 19 Mar 2010 13:05:02 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
Message-ID: <45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>

On Fri, Mar 19, 2010 at 12:37 PM,  <josef.pktd at gmail.com> wrote:
> On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
>> On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
>>> Hi,
>>>
>>> In both my old version and the one in the svn trunk there is an
>>> inconsistency in the docstring of scipy.optimize.fmin.
>>>
>>> ? ?Other Parameters
>>> ? ?----------------
>>> ? ?xtol : float
>>> ? ? ? ?Relative error in xopt acceptable for convergence.
>>> ? ?ftol : number
>>> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>>>
>>> As you see from the following code snippet from the body of the
>>> function, the convergence test is in terms of absolute error for both
>>> x and f, as the sim array contains x values and fsim the function
>>> values.
>>>
>>> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>> ? ? ? ?break
>>
>> OK, folks, so what's the _desired_ behavior: absolute or relative
>> error (i.e., where's the bug: in the code or in the doc)?
>
> I think the docs should reflect the actual behavior of the function.
> Whether the criteria will be changed and made consistent across
> functions is a different question. But it's not a bug, so the docs
> should adjust.
>
> my opinion
>
> Josef

Well, I'm pretty sure we formally adopted the opposite policy: the
docs should reflect _desired_ behavior - if the code doesn't implement
desired behavior then a bug report is to be filed.  (I thought this
was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only"
in an email thread somewhere).  Can anyone else confirm and,
hopefully, supply a link to the email thread in which this was
discussed?

DG


From josef.pktd at gmail.com  Fri Mar 19 16:09:57 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 19 Mar 2010 16:09:57 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
Message-ID: <1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>

On Fri, Mar 19, 2010 at 4:05 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Fri, Mar 19, 2010 at 12:37 PM, ?<josef.pktd at gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith
>> <d.l.goldsmith at gmail.com> wrote:
>>> On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> In both my old version and the one in the svn trunk there is an
>>>> inconsistency in the docstring of scipy.optimize.fmin.
>>>>
>>>> ? ?Other Parameters
>>>> ? ?----------------
>>>> ? ?xtol : float
>>>> ? ? ? ?Relative error in xopt acceptable for convergence.
>>>> ? ?ftol : number
>>>> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>>>>
>>>> As you see from the following code snippet from the body of the
>>>> function, the convergence test is in terms of absolute error for both
>>>> x and f, as the sim array contains x values and fsim the function
>>>> values.
>>>>
>>>> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>>> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>>> ? ? ? ?break
>>>
>>> OK, folks, so what's the _desired_ behavior: absolute or relative
>>> error (i.e., where's the bug: in the code or in the doc)?
>>
>> I think the docs should reflect the actual behavior of the function.
>> Whether the criteria will be changed and made consistent across
>> functions is a different question. But it's not a bug, so the docs
>> should adjust.
>>
>> my opinion
>>
>> Josef
>
> Well, I'm pretty sure we formally adopted the opposite policy: the
> docs should reflect _desired_ behavior - if the code doesn't implement
> desired behavior then a bug report is to be filed. ?(I thought this
> was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only"
> in an email thread somewhere). ?Can anyone else confirm and,
> hopefully, supply a link to the email thread in which this was
> discussed?

I know of that policy, but there are a lot of mistakes in the docs,
and I don't think we change the code to match the mistakes in the
docs.

But you can also file a ticket for changing and reviewing convergence criteria

I don't think relative (to what?) error makes much sense if x or f goes to zero.

Josef


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


From d.l.goldsmith at gmail.com  Fri Mar 19 16:51:36 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 19 Mar 2010 13:51:36 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
	<1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
Message-ID: <45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>

On Fri, Mar 19, 2010 at 1:09 PM,  <josef.pktd at gmail.com> wrote:
> On Fri, Mar 19, 2010 at 4:05 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 12:37 PM, ?<josef.pktd at gmail.com> wrote:
>>> On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith
>>> <d.l.goldsmith at gmail.com> wrote:
>>>> On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> In both my old version and the one in the svn trunk there is an
>>>>> inconsistency in the docstring of scipy.optimize.fmin.
>>>>>
>>>>> ? ?Other Parameters
>>>>> ? ?----------------
>>>>> ? ?xtol : float
>>>>> ? ? ? ?Relative error in xopt acceptable for convergence.
>>>>> ? ?ftol : number
>>>>> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>>>>>
>>>>> As you see from the following code snippet from the body of the
>>>>> function, the convergence test is in terms of absolute error for both
>>>>> x and f, as the sim array contains x values and fsim the function
>>>>> values.
>>>>>
>>>>> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>>>> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>>>> ? ? ? ?break
>>>>
>>>> OK, folks, so what's the _desired_ behavior: absolute or relative
>>>> error (i.e., where's the bug: in the code or in the doc)?
>>>
>>> I think the docs should reflect the actual behavior of the function.
>>> Whether the criteria will be changed and made consistent across
>>> functions is a different question. But it's not a bug, so the docs
>>> should adjust.
>>>
>>> my opinion
>>>
>>> Josef
>>
>> Well, I'm pretty sure we formally adopted the opposite policy: the
>> docs should reflect _desired_ behavior - if the code doesn't implement
>> desired behavior then a bug report is to be filed. ?(I thought this
>> was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only"
>> in an email thread somewhere). ?Can anyone else confirm and,
>> hopefully, supply a link to the email thread in which this was
>> discussed?
>
> I know of that policy, but there are a lot of mistakes in the docs,
> and I don't think we change the code to match the mistakes in the
> docs.

No, of course not, but the idea is that a "mistake" in the doc is not
a mistake if in fact it documents the desired behavior (and thus the
real mistake is in the code, in which case we've basically agreed that
we _will_ change the code to match the doc; for better or worse, this
means that when "mistakes" are found in the docs - mistakes which in
fact may not be mistakes but only appear to be so because they don't
match code behavior - we will need to address them on a case-by-case
basis, such as is being done in this instance).
>
> But you can also file a ticket for changing and reviewing convergence criteria

OK, yours is a "vote" for "bug in the doc."

> I don't think relative (to what?) error makes much sense if x or f goes to zero.
>
> Josef

Agreed: the most robust behavior it to allow specification of both
types of tolerance.

DG


From josef.pktd at gmail.com  Fri Mar 19 16:58:17 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 19 Mar 2010 16:58:17 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
	<1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
	<45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
Message-ID: <1cd32cbb1003191358q79322158j6b9055cd6099f9c2@mail.gmail.com>

On Fri, Mar 19, 2010 at 4:51 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Fri, Mar 19, 2010 at 1:09 PM, ?<josef.pktd at gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 4:05 PM, David Goldsmith
>> <d.l.goldsmith at gmail.com> wrote:
>>> On Fri, Mar 19, 2010 at 12:37 PM, ?<josef.pktd at gmail.com> wrote:
>>>> On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith
>>>> <d.l.goldsmith at gmail.com> wrote:
>>>>> On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> In both my old version and the one in the svn trunk there is an
>>>>>> inconsistency in the docstring of scipy.optimize.fmin.
>>>>>>
>>>>>> ? ?Other Parameters
>>>>>> ? ?----------------
>>>>>> ? ?xtol : float
>>>>>> ? ? ? ?Relative error in xopt acceptable for convergence.
>>>>>> ? ?ftol : number
>>>>>> ? ? ? ?Relative error in func(xopt) acceptable for convergence.
>>>>>>
>>>>>> As you see from the following code snippet from the body of the
>>>>>> function, the convergence test is in terms of absolute error for both
>>>>>> x and f, as the sim array contains x values and fsim the function
>>>>>> values.
>>>>>>
>>>>>> ? ?if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \
>>>>>> ? ? ? ? ? ? ? ?and max(abs(fsim[0]-fsim[1:])) <= ftol):
>>>>>> ? ? ? ?break
>>>>>
>>>>> OK, folks, so what's the _desired_ behavior: absolute or relative
>>>>> error (i.e., where's the bug: in the code or in the doc)?
>>>>
>>>> I think the docs should reflect the actual behavior of the function.
>>>> Whether the criteria will be changed and made consistent across
>>>> functions is a different question. But it's not a bug, so the docs
>>>> should adjust.
>>>>
>>>> my opinion
>>>>
>>>> Josef
>>>
>>> Well, I'm pretty sure we formally adopted the opposite policy: the
>>> docs should reflect _desired_ behavior - if the code doesn't implement
>>> desired behavior then a bug report is to be filed. ?(I thought this
>>> was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only"
>>> in an email thread somewhere). ?Can anyone else confirm and,
>>> hopefully, supply a link to the email thread in which this was
>>> discussed?
>>
>> I know of that policy, but there are a lot of mistakes in the docs,
>> and I don't think we change the code to match the mistakes in the
>> docs.
>
> No, of course not, but the idea is that a "mistake" in the doc is not
> a mistake if in fact it documents the desired behavior (and thus the
> real mistake is in the code, in which case we've basically agreed that
> we _will_ change the code to match the doc; for better or worse, this
> means that when "mistakes" are found in the docs - mistakes which in
> fact may not be mistakes but only appear to be so because they don't
> match code behavior - we will need to address them on a case-by-case
> basis, such as is being done in this instance).

Sorry if I was ambiguous, my initial statement was about the specific
case of the fmin, not reflecting an opinion about a general policy.

I agree we have to check case by case. my "bug in docs" is for this case only

Josef

>>
>> But you can also file a ticket for changing and reviewing convergence criteria
>
> OK, yours is a "vote" for "bug in the doc."
>
>> I don't think relative (to what?) error makes much sense if x or f goes to zero.
>>
>> Josef
>
> Agreed: the most robust behavior it to allow specification of both
> types of tolerance.
>
> DG
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From ralf.gommers at googlemail.com  Sat Mar 20 04:52:00 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 20 Mar 2010 16:52:00 +0800
Subject: [SciPy-Dev] Spherical harmonics, convention
In-Reply-To: <1e2af89e1003191050k1affc407if867f91eebf50e29@mail.gmail.com>
References: <1e2af89e1003191050k1affc407if867f91eebf50e29@mail.gmail.com>
Message-ID: <dde7764a1003200152p69280b7uc0aea8bc4da5a846@mail.gmail.com>

On Sat, Mar 20, 2010 at 1:50 AM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> I noticed that scipy.special.sph_harm uses conventions that (on
> superficial reading) seem to be rather unusual; can I ask for advice
> whether that is correct?


> For example; http://en.wikipedia.org/wiki/Spherical_harmonics assumes:
>
> theta = polar angle
> phi = azimuthal angle
> l (little L) = degree of harmonic
>
> but we have:
>
> theta = azimuthal angle
> phi = polar angle
> n = degree of harmonic
>
> I realize that the theta / phi switch is the difference between
> physics and math conventions of spherical coordinates, but my
> superficial impression was that there was a rather strong tradition in
> spherical harmonics to prefer theta = polar, phi = azimuthal; is that
> correct?
>

It indeed looks weird to me as a physicist, I've never seen it the 'wrong'
way around. But I have to admit that I don't know how widely spherical
harmonics are used in mathematics, and for what. I associate them with the
hydrogen atom, multipole expansions in electrodynamics, etc.

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

From bkomaki at yahoo.com  Sat Mar 20 06:30:56 2010
From: bkomaki at yahoo.com (Bairam Komaki)
Date: Sat, 20 Mar 2010 03:30:56 -0700 (PDT)
Subject: [SciPy-Dev] Stefan Hannweber
Message-ID: <237343.17902.qm@web30403.mail.mud.yahoo.com>

http://wiaderko.110mb.com/mustapha.html


      


From ralf.gommers at googlemail.com  Sat Mar 20 07:19:36 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 20 Mar 2010 19:19:36 +0800
Subject: [SciPy-Dev] patches to prepare for 0.7.2rc1
Message-ID: <dde7764a1003200419x4d292c31odf3805fe32917a@mail.gmail.com>

At http://github.com/rgommers/scipy/tree/release0p7 I have some patches to
bump version number, add release notes for 0.7.2, and some updates to the
pavement file. Can I ask for a review and if it's all fine, can these be
committed to the 0.7.x branch?

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100320/7b0bf896/attachment.html>

From ralf.gommers at googlemail.com  Sat Mar 20 10:35:27 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 20 Mar 2010 22:35:27 +0800
Subject: [SciPy-Dev] patches to prepare for 0.7.2rc1
In-Reply-To: <dde7764a1003200419x4d292c31odf3805fe32917a@mail.gmail.com>
References: <dde7764a1003200419x4d292c31odf3805fe32917a@mail.gmail.com>
Message-ID: <dde7764a1003200735v5dc6850bpf9b4fd0a85275434@mail.gmail.com>

On Sat, Mar 20, 2010 at 7:19 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

> At http://github.com/rgommers/scipy/tree/release0p7 I have some patches to
> bump version number, add release notes for 0.7.2, and some updates to the
> pavement file. Can I ask for a review and if it's all fine, can these be
> committed to the 0.7.x branch?
>
>
> Thanks for reviewing David.

One follow-up question: in trac there are still 16 tickets for 0.7.1,
including 6 with patches. Should any of these be included after review, or
can they be moved to the 0.8.0 milestone?

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

From ralf.gommers at googlemail.com  Sat Mar 20 10:59:15 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 20 Mar 2010 22:59:15 +0800
Subject: [SciPy-Dev] requesting commit rights
Message-ID: <dde7764a1003200759q7691b6afs34240091e600efcd@mail.gmail.com>

Hi,

I would like to get commit rights for both scipy and numpy. The things I
want to work on and think I need them for:
1. making releases (including related build issues and tests)
2. docs (merging wiki edits, doc machinery for some scipy modules)

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100320/47cabbe1/attachment.html>

From josef.pktd at gmail.com  Sat Mar 20 11:36:11 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 20 Mar 2010 11:36:11 -0400
Subject: [SciPy-Dev] patches to prepare for 0.7.2rc1
In-Reply-To: <dde7764a1003200735v5dc6850bpf9b4fd0a85275434@mail.gmail.com>
References: <dde7764a1003200419x4d292c31odf3805fe32917a@mail.gmail.com>
	<dde7764a1003200735v5dc6850bpf9b4fd0a85275434@mail.gmail.com>
Message-ID: <1cd32cbb1003200836i3a3e9d9djc0c02b638f73fd30@mail.gmail.com>

On Sat, Mar 20, 2010 at 10:35 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Sat, Mar 20, 2010 at 7:19 PM, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:
>>
>> At http://github.com/rgommers/scipy/tree/release0p7 I have some patches to
>> bump version number, add release notes for 0.7.2, and some updates to the
>> pavement file. Can I ask for a review and if it's all fine, can these be
>> committed to the 0.7.x branch?
>>
>>
> Thanks for reviewing David.
>
> One follow-up question: in trac there are still 16 tickets for 0.7.1,
> including 6 with patches. Should any of these be included after review, or
> can they be moved to the 0.8.0 milestone?

Isn't 0.7.2 not just a rebuild of scipy?
Are any bug fixes supposed to be backported?

I would just bump all milestones.

Josef


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


From ralf.gommers at googlemail.com  Sat Mar 20 11:46:38 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 20 Mar 2010 23:46:38 +0800
Subject: [SciPy-Dev] patches to prepare for 0.7.2rc1
In-Reply-To: <1cd32cbb1003200836i3a3e9d9djc0c02b638f73fd30@mail.gmail.com>
References: <dde7764a1003200419x4d292c31odf3805fe32917a@mail.gmail.com>
	<dde7764a1003200735v5dc6850bpf9b4fd0a85275434@mail.gmail.com>
	<1cd32cbb1003200836i3a3e9d9djc0c02b638f73fd30@mail.gmail.com>
Message-ID: <dde7764a1003200846v7a0944ard23f1b0d305ee8d8@mail.gmail.com>

On Sat, Mar 20, 2010 at 11:36 PM, <josef.pktd at gmail.com> wrote:

> On Sat, Mar 20, 2010 at 10:35 AM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> >
> >
> > On Sat, Mar 20, 2010 at 7:19 PM, Ralf Gommers <
> ralf.gommers at googlemail.com>
> > wrote:
> >>
> >> At http://github.com/rgommers/scipy/tree/release0p7 I have some patches
> to
> >> bump version number, add release notes for 0.7.2, and some updates to
> the
> >> pavement file. Can I ask for a review and if it's all fine, can these be
> >> committed to the 0.7.x branch?
> >>
> >>
> > Thanks for reviewing David.
> >
> > One follow-up question: in trac there are still 16 tickets for 0.7.1,
> > including 6 with patches. Should any of these be included after review,
> or
> > can they be moved to the 0.8.0 milestone?
>
> Isn't 0.7.2 not just a rebuild of scipy?
>

It is so far.


> Are any bug fixes supposed to be backported?
>

They're not backports, they're open tickets (some with patches) that are at
the 0.7.1 milestone. I just want to double-check that they are not there for
a specific reason and need to be included. Someone obviously moved all
tickets except these 16 to 0.8.0.

Ralf


> I would just bump all milestones.
>
> Josef
>
>
> >
> > Ralf
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100320/70770527/attachment.html>

From rob.clewley at gmail.com  Sat Mar 20 12:30:27 2010
From: rob.clewley at gmail.com (Rob Clewley)
Date: Sat, 20 Mar 2010 12:30:27 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
	<1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
	<45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
Message-ID: <a749952d1003200930h61f0634bw4a0554a7e584e088@mail.gmail.com>

Hi,

> Agreed: the most robust behavior it to allow specification of both
> types of tolerance.

Yes, definitely. Most numerical algorithms for optimization / root
finding can benefit from a range of stopping conditions for different
usage situations. But beyond just the abs and rel tolerances in x, it
can be useful to also provide an absolute tolerance for the size of f
to declare it small enough (ftol) regardless of how close the x values
are. These conditions are very easy to add to the code.

The whole point of absolute tolerances is to take care of the
possibilities of x, f going to zero and ruining the meaning of
relative error. But for large values of x or f their relative error
tolerances make a lot of sense.

-Rob


From d.l.goldsmith at gmail.com  Sat Mar 20 15:23:26 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Sat, 20 Mar 2010 12:23:26 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <a749952d1003200930h61f0634bw4a0554a7e584e088@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
	<1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
	<45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
	<a749952d1003200930h61f0634bw4a0554a7e584e088@mail.gmail.com>
Message-ID: <45d1ab481003201223j213f06f3q84608f431431d383@mail.gmail.com>

On Sat, Mar 20, 2010 at 9:30 AM, Rob Clewley <rob.clewley at gmail.com> wrote:
> Hi,
>
>> Agreed: the most robust behavior it to allow specification of both
>> types of tolerance.
>
> Yes, definitely. Most numerical algorithms for optimization / root
> finding can benefit from a range of stopping conditions for different
> usage situations. But beyond just the abs and rel tolerances in x, it
> can be useful to also provide an absolute tolerance for the size of f
> to declare it small enough (ftol) regardless of how close the x values
> are. These conditions are very easy to add to the code.
>
> The whole point of absolute tolerances is to take care of the
> possibilities of x, f going to zero and ruining the meaning of
> relative error. But for large values of x or f their relative error
> tolerances make a lot of sense.
>
> -Rob

Rob: since no one else (besides Josef of course) is chiming in (in
particular, to "block"), may I suggest/request that you:

0) file an "enhancement" ticket for this improvement;

1) if you have the time and wherewithal, "own" the ticket, implement
the improvement (taking care to do so in such a way that the
function's extant API is not broken), and submit your patch;

2) then either update the docstring accordingly or let me know when
you're done (or at least have the details of your implementation
mapped out) and I will update the docstring.

If you need guidance in any of this (e.g., locating the scipy
developer's Trac page whereon tickets are filed) - or are just to
swamped - let me know and I'll be happy to help.  Thanks for reporting
this.

DG

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


From warren.weckesser at enthought.com  Sat Mar 20 21:29:33 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sat, 20 Mar 2010 20:29:33 -0500
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <1cd32cbb1003090705p453e5234h73edd39c1b37f1c6@mail.gmail.com>
References: <4B94516A.3030701@enthought.com>
	<4B9453C6.4000105@enthought.com>	<1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>	<4B946893.8090202@enthought.com>
	<4B95BFA9.4020507@enthought.com>
	<1cd32cbb1003090705p453e5234h73edd39c1b37f1c6@mail.gmail.com>
Message-ID: <4BA5767D.6020106@enthought.com>

josef.pktd at gmail.com wrote:
> On Mon, Mar 8, 2010 at 10:25 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>   
>> Two more questions about the toeplitz API:
>>     
>
> I did a (partial) search in trac and on the mailing lists and didn't
> find any information
>
>   


I have submitted a patch, attached to ticket #667.   The patch changes
the behavior of toeplitz() and hankel(), and adds a new function, 
circulant().
The patch also adds several tests of these functions.  I can commit the
patch, but I'd like to know if y'all agree with the changes first.

Warren


>   
>> The signature is toeplitz(c, r=None).  In the current implementation,
>> if either c or r is a scalar, then c is returned.  This results in the
>> following:
>>
>> In [1]: from scipy.linalg import toeplitz
>>
>> In [2]: toeplitz(1, [1,2,3,4])
>> Out[2]: 1
>>
>> In [3]: toeplitz([1], [1,2,3,4])
>> Out[3]: array([[1, 2, 3, 4]])
>>
>> I would expect these to produce the same result--the second result,
>> in fact.
>>
>> Similarly, the following is surprising:
>>
>> In [4]: toeplitz([1,2,3,4], 1)
>> Out[4]: [1, 2, 3, 4]
>>
>> In [5]: toeplitz([1,2,3,4], [1])
>> Out[5]:
>> array([[1],
>>       [2],
>>       [3],
>>       [4]])
>>
>> I think it makes more sense for toeplitz to simply treat a scalar
>> as a 1D array of length 1.  Moreover, it seems to me that toeplitz
>> should *always* return a 2D array.
>>     
>
> numpy/scipy is not matlab, so the policy is still a bit vague
>
>   
>>>> np.kron(5,3)
>>>>         
> 15
>   
>>>> np.kron([5],[3])
>>>>         
> array([15])
>   
>>>> np.kron([5],[3]).shape
>>>>         
> (1,)
>   
>>>> scipy.linalg.hankel(1)
>>>>         
> 1
>   
>>>> scipy.linalg.hankel(1,2)
>>>>         
> 1
>   
>>>> np.triu(3)
>>>>         
> Traceback (most recent call last):
>   File "C:\Programs\Python25\Lib\site-packages\numpy\lib\twodim_base.py",
> line 442, in triu
>     out = multiply((1-tri(m.shape[0], m.shape[1], k-1, int)),m)
> IndexError: tuple index out of range
>   
>>>> np.triu([3])
>>>>         
> Traceback (most recent call last):
>   File "C:\Programs\Python25\Lib\site-packages\numpy\lib\twodim_base.py",
> line 442, in triu
>     out = multiply((1-tri(m.shape[0], m.shape[1], k-1, int)),m)
> IndexError: tuple index out of range
>   
>>>> np.triu([[3]])
>>>>         
> array([[3]])
>
>   
>>>> scipy.linalg.kron([-1j], [1.j])
>>>>         
> Traceback (most recent call last):
>   File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py",
> line 835, in kron
> AttributeError: 'list' object has no attribute 'flags'
>
> and I filed a ticket for scipy.linalg.block_diag because there I can
> see a use for scalar to 2d.
>
> I don't have a strong opinion about always 2d result, but a bit more
> consistency in numpy/scipy would be useful.
>
>
>   
>> My second question: does anyone know why toeplitz uses
>> asarray_chkfinite()?  If, in general, numpy arrays can hold the
>> values nan and inf, why should this function care if its values
>> are finite?  Any objections to not using asarray_chkfinite()?
>>     
>
> I agree, I don't think it's the job of toeplitz or hankle to throw an
> exception if I want to have a inf or nan in my matrix.
>
>   
>> Warren
>>
>>
>>
>> Warren Weckesser wrote:
>>     
>>> josef.pktd at gmail.com wrote:
>>>
>>>       
>>>> On Sun, Mar 7, 2010 at 8:32 PM, Warren Weckesser
>>>> <warren.weckesser at enthought.com> wrote:
>>>>
>>>>
>>>>         
>>>>> Warren Weckesser wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> I am going to update linalg.toeplitz to fix the problem reported in
>>>>>> ticket #667, but I have some questions about the desired behavior of
>>>>>> the function when either `c` (the first column) or `r` (the first row)
>>>>>> is complex.  The docstring does not say anything about complex values,
>>>>>> but the code does some undocumented and unexpected things in this
>>>>>> case, one example of which is the bug reported in the ticket #667.
>>>>>>
>>>>>> I would like to fix this, but I would first like opinions on exactly
>>>>>> how it *should* handle complex arguments.  I *think* the idea is that
>>>>>> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
>>>>>> matrix is created.  Is that correct?  Note that this requires that
>>>>>> c[0] be real, since c[0] is the value that will be in the diagonal of
>>>>>> the matrix.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>> It looks like the behavior was copied from Matlab:
>>>
>>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/toeplitz.html
>>>
>>>
>>>       
>>>>>> While I am fixing this, I would like to remove the printed warning
>>>>>> that occurs when r[0] != c[0].  I would like to change this to raise
>>>>>> a ValueError--that is, adopt the philosophy that either the arguments
>>>>>> are correct (and the code handles them as [not yet, but soon to be]
>>>>>> documented in the docstring, with no warnings needed), or the
>>>>>> arguments are wrong and an exception should be raised.
>>>>>>
>>>>>> This means that when `r` is not given, an exception would be raised
>>>>>> if c[0] is not real.
>>>>>>
>>>>>> A very different way to handle the case of `r` not being given is to
>>>>>> assume it means a square matrix should be created with r[1:] = 0
>>>>>> (i.e. zeros in all the upper off-diagonals).  This avoids the whole
>>>>>> issue of complex numbers and conjugates, but it is also a more
>>>>>> drastic change.
>>>>>>
>>>>>>
>>>>>>             
>>>> a lot of code relies on toeplitz of a single argument to build the
>>>> symmetric matrix.
>>>>
>>>>
>>>>
>>>>         
>>> OK, thanks--that's good to know.
>>>
>>>
>>>       
>>>>>>             
>>>>> By the way, that is how linalg.hankel handles the case where `r` is not
>>>>> given.
>>>>>
>>>>>
>>>>>           
>>>> ??
>>>>
>>>>
>>>>
>>>>         
>>> I'm not sure what your question marks mean.  What I meant by "that is
>>> how linalg.hankel handles [it]" was that when `r` is not given, hankel
>>> uses zeros to fill in the bottom row.  Your examples demonstrate this.
>>> My point is moot, since if there is "a lot of code" that relies on
>>> creating a symmetric/hermitian matrix, it would be a bad idea to make
>>> such a significant change to the API.
>>>
>>>
>>>       
>>>>>>> import scipy.linalg
>>>>>>> scipy.linalg.toeplitz(np.arange(4))
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> array([[0, 1, 2, 3],
>>>>        [1, 0, 1, 2],
>>>>        [2, 1, 0, 1],
>>>>        [3, 2, 1, 0]])
>>>>
>>>>
>>>>         
>>>>>>> scipy.linalg.hankel(np.arange(4))
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> array([[ 0.,  1.,  2.,  3.],
>>>>        [ 1.,  2.,  3.,  0.],
>>>>        [ 2.,  3.,  0.,  0.],
>>>>        [ 3.,  0.,  0.,  0.]])
>>>>
>>>>
>>>>         
>>>>>>> scipy.linalg.hankel(np.arange(4)+1.j)
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
>>>>        [ 1.+1.j,  2.+1.j,  3.+1.j,  0.+0.j],
>>>>        [ 2.+1.j,  3.+1.j,  0.+0.j,  0.+0.j],
>>>>        [ 3.+1.j,  0.+0.j,  0.+0.j,  0.+0.j]])
>>>>
>>>>
>>>>         
>>>>>>> scipy.linalg.toeplitz(np.arange(4)+1.j)
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> Warning: column and row values don't agree; column value used.
>>>> array([[ 0.+1.j,  1.+1.j,  2.+1.j,  3.+1.j],
>>>>        [ 1.-1.j,  0.+1.j,  1.+1.j,  2.+1.j],
>>>>        [ 2.-1.j,  1.-1.j,  0.+1.j,  1.+1.j],
>>>>        [ 3.-1.j,  2.-1.j,  1.-1.j,  0.+1.j]])
>>>>
>>>>
>>>> requiring the diagonal to be real might be too tough, I'm not using
>>>> complex toeplitz, but for other cases, I often have "almost real"
>>>> values, up to numerical imprecision.
>>>>
>>>>
>>>>
>>>>         
>>> This could be dealt with like Matlab does: don't worry about it, and
>>> just use c[1:] to fill in r[1:].  If c[0] is has nonzero imaginary part,
>>> then the matrix is not Hermitian--but that's OK, since that is what the
>>> user gave to the function.
>>>
>>> Your example illustrates one of the bugs: note that, except for the
>>> first element, the first column is the *conjugate* of the first
>>> argument.  The docstring says that `c` is the first column (and the
>>> optional second argument is the first row).  So it is the elements in
>>> the first row starting in the second column that should be conjugated.
>>> It also prints that annoying warning.
>>>       
>
> That's how I interpreted the bug
>
>
>   
>>>       
>>>>>>> scipy.linalg.toeplitz(np.arange(4)*1.j,-np.arange(4)*1.j)
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> array([[ 0.+0.j,  0.-1.j,  0.-2.j,  0.-3.j],
>>>>        [ 0.+1.j,  0.+0.j,  0.-1.j,  0.-2.j],
>>>>        [ 0.+2.j,  0.+1.j,  0.+0.j,  0.-1.j],
>>>>        [ 0.+3.j,  0.+2.j,  0.+1.j,  0.+0.j]])
>>>>
>>>> also for real values  r[0] != c[0] might not be satisfied if there is
>>>> numerical imprecision and they are only almost equal.
>>>>
>>>>
>>>>
>>>>         
>>> True.  So if the requirement that r[0] == c[0] is strict, a user who
>>> knows the first values are "close enough", but maybe not exactly equal,
>>> would have to do something like:
>>>
>>> r[0] = c[0]
>>> t = toeplitz(c, r)
>>>
>>> I could live with that, but not everyone will agree.
>>>
>>> Instead, the function could require that the values be "close", using
>>> something like numpy.allclose(), but how close is close enough?  Should
>>> the function then have `atol` and `rtol` arguments to use for the
>>> comparison?  This feels like overkill, and is not my preference.
>>>
>>> So that leaves the behavior used by Matlab: use c[0], and ignore r[0].
>>> But I don't like the printed warning (or any logged warning) when c[0]
>>> != r[0].  If the program is behaving correctly, and as documented, no
>>> warning should be necessary.
>>>       
>
> raising a proper Warning might be useful and avoid the almost equal issue
>
> I think, all the uses I have seen use only a single argument to build
> the symmetric toeplitz matrix.
>
> Josef
>
>
>   
>>> (If I could start from scratch, I would simply define the `r` argument
>>> to give the values from the second column onward, and so completely
>>> avoid the issue.)
>>>
>>> Warren
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>       
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>     
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From josef.pktd at gmail.com  Sun Mar 21 00:34:43 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 21 Mar 2010 00:34:43 -0400
Subject: [SciPy-Dev] linalg.toeplitz and ticker #667
In-Reply-To: <4BA5767D.6020106@enthought.com>
References: <4B94516A.3030701@enthought.com> <4B9453C6.4000105@enthought.com>
	<1cd32cbb1003071805x4f264182n736fb13847ed3f48@mail.gmail.com>
	<4B946893.8090202@enthought.com> <4B95BFA9.4020507@enthought.com>
	<1cd32cbb1003090705p453e5234h73edd39c1b37f1c6@mail.gmail.com>
	<4BA5767D.6020106@enthought.com>
Message-ID: <1cd32cbb1003202134x631d115by10d588a3a6b1b6b6@mail.gmail.com>

On Sat, Mar 20, 2010 at 9:29 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> josef.pktd at gmail.com wrote:
>> On Mon, Mar 8, 2010 at 10:25 PM, Warren Weckesser
>> <warren.weckesser at enthought.com> wrote:
>>
>>> Two more questions about the toeplitz API:
>>>
>>
>> I did a (partial) search in trac and on the mailing lists and didn't
>> find any information
>>
>>
>
>
> I have submitted a patch, attached to ticket #667. ? The patch changes
> the behavior of toeplitz() and hankel(), and adds a new function,
> circulant().
> The patch also adds several tests of these functions. ?I can commit the
> patch, but I'd like to know if y'all agree with the changes first.

fine with me

Josef

>
> Warren
>
>
>>
>>> The signature is toeplitz(c, r=None). ?In the current implementation,
>>> if either c or r is a scalar, then c is returned. ?This results in the
>>> following:
>>>
>>> In [1]: from scipy.linalg import toeplitz
>>>
>>> In [2]: toeplitz(1, [1,2,3,4])
>>> Out[2]: 1
>>>
>>> In [3]: toeplitz([1], [1,2,3,4])
>>> Out[3]: array([[1, 2, 3, 4]])
>>>
>>> I would expect these to produce the same result--the second result,
>>> in fact.
>>>
>>> Similarly, the following is surprising:
>>>
>>> In [4]: toeplitz([1,2,3,4], 1)
>>> Out[4]: [1, 2, 3, 4]
>>>
>>> In [5]: toeplitz([1,2,3,4], [1])
>>> Out[5]:
>>> array([[1],
>>> ? ? ? [2],
>>> ? ? ? [3],
>>> ? ? ? [4]])
>>>
>>> I think it makes more sense for toeplitz to simply treat a scalar
>>> as a 1D array of length 1. ?Moreover, it seems to me that toeplitz
>>> should *always* return a 2D array.
>>>
>>
>> numpy/scipy is not matlab, so the policy is still a bit vague
>>
>>
>>>>> np.kron(5,3)
>>>>>
>> 15
>>
>>>>> np.kron([5],[3])
>>>>>
>> array([15])
>>
>>>>> np.kron([5],[3]).shape
>>>>>
>> (1,)
>>
>>>>> scipy.linalg.hankel(1)
>>>>>
>> 1
>>
>>>>> scipy.linalg.hankel(1,2)
>>>>>
>> 1
>>
>>>>> np.triu(3)
>>>>>
>> Traceback (most recent call last):
>> ? File "C:\Programs\Python25\Lib\site-packages\numpy\lib\twodim_base.py",
>> line 442, in triu
>> ? ? out = multiply((1-tri(m.shape[0], m.shape[1], k-1, int)),m)
>> IndexError: tuple index out of range
>>
>>>>> np.triu([3])
>>>>>
>> Traceback (most recent call last):
>> ? File "C:\Programs\Python25\Lib\site-packages\numpy\lib\twodim_base.py",
>> line 442, in triu
>> ? ? out = multiply((1-tri(m.shape[0], m.shape[1], k-1, int)),m)
>> IndexError: tuple index out of range
>>
>>>>> np.triu([[3]])
>>>>>
>> array([[3]])
>>
>>
>>>>> scipy.linalg.kron([-1j], [1.j])
>>>>>
>> Traceback (most recent call last):
>> ? File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py",
>> line 835, in kron
>> AttributeError: 'list' object has no attribute 'flags'
>>
>> and I filed a ticket for scipy.linalg.block_diag because there I can
>> see a use for scalar to 2d.
>>
>> I don't have a strong opinion about always 2d result, but a bit more
>> consistency in numpy/scipy would be useful.
>>
>>
>>
>>> My second question: does anyone know why toeplitz uses
>>> asarray_chkfinite()? ?If, in general, numpy arrays can hold the
>>> values nan and inf, why should this function care if its values
>>> are finite? ?Any objections to not using asarray_chkfinite()?
>>>
>>
>> I agree, I don't think it's the job of toeplitz or hankle to throw an
>> exception if I want to have a inf or nan in my matrix.
>>
>>
>>> Warren
>>>
>>>
>>>
>>> Warren Weckesser wrote:
>>>
>>>> josef.pktd at gmail.com wrote:
>>>>
>>>>
>>>>> On Sun, Mar 7, 2010 at 8:32 PM, Warren Weckesser
>>>>> <warren.weckesser at enthought.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Warren Weckesser wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I am going to update linalg.toeplitz to fix the problem reported in
>>>>>>> ticket #667, but I have some questions about the desired behavior of
>>>>>>> the function when either `c` (the first column) or `r` (the first row)
>>>>>>> is complex. ?The docstring does not say anything about complex values,
>>>>>>> but the code does some undocumented and unexpected things in this
>>>>>>> case, one example of which is the bug reported in the ticket #667.
>>>>>>>
>>>>>>> I would like to fix this, but I would first like opinions on exactly
>>>>>>> how it *should* handle complex arguments. ?I *think* the idea is that
>>>>>>> if `c` is complex and `r` is not given, then a Hermitian Toeplitz
>>>>>>> matrix is created. ?Is that correct? ?Note that this requires that
>>>>>>> c[0] be real, since c[0] is the value that will be in the diagonal of
>>>>>>> the matrix.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> It looks like the behavior was copied from Matlab:
>>>>
>>>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/toeplitz.html
>>>>
>>>>
>>>>
>>>>>>> While I am fixing this, I would like to remove the printed warning
>>>>>>> that occurs when r[0] != c[0]. ?I would like to change this to raise
>>>>>>> a ValueError--that is, adopt the philosophy that either the arguments
>>>>>>> are correct (and the code handles them as [not yet, but soon to be]
>>>>>>> documented in the docstring, with no warnings needed), or the
>>>>>>> arguments are wrong and an exception should be raised.
>>>>>>>
>>>>>>> This means that when `r` is not given, an exception would be raised
>>>>>>> if c[0] is not real.
>>>>>>>
>>>>>>> A very different way to handle the case of `r` not being given is to
>>>>>>> assume it means a square matrix should be created with r[1:] = 0
>>>>>>> (i.e. zeros in all the upper off-diagonals). ?This avoids the whole
>>>>>>> issue of complex numbers and conjugates, but it is also a more
>>>>>>> drastic change.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> a lot of code relies on toeplitz of a single argument to build the
>>>>> symmetric matrix.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> OK, thanks--that's good to know.
>>>>
>>>>
>>>>
>>>>>>>
>>>>>> By the way, that is how linalg.hankel handles the case where `r` is not
>>>>>> given.
>>>>>>
>>>>>>
>>>>>>
>>>>> ??
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I'm not sure what your question marks mean. ?What I meant by "that is
>>>> how linalg.hankel handles [it]" was that when `r` is not given, hankel
>>>> uses zeros to fill in the bottom row. ?Your examples demonstrate this.
>>>> My point is moot, since if there is "a lot of code" that relies on
>>>> creating a symmetric/hermitian matrix, it would be a bad idea to make
>>>> such a significant change to the API.
>>>>
>>>>
>>>>
>>>>>>>> import scipy.linalg
>>>>>>>> scipy.linalg.toeplitz(np.arange(4))
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> array([[0, 1, 2, 3],
>>>>> ? ? ? ?[1, 0, 1, 2],
>>>>> ? ? ? ?[2, 1, 0, 1],
>>>>> ? ? ? ?[3, 2, 1, 0]])
>>>>>
>>>>>
>>>>>
>>>>>>>> scipy.linalg.hankel(np.arange(4))
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> array([[ 0., ?1., ?2., ?3.],
>>>>> ? ? ? ?[ 1., ?2., ?3., ?0.],
>>>>> ? ? ? ?[ 2., ?3., ?0., ?0.],
>>>>> ? ? ? ?[ 3., ?0., ?0., ?0.]])
>>>>>
>>>>>
>>>>>
>>>>>>>> scipy.linalg.hankel(np.arange(4)+1.j)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> array([[ 0.+1.j, ?1.+1.j, ?2.+1.j, ?3.+1.j],
>>>>> ? ? ? ?[ 1.+1.j, ?2.+1.j, ?3.+1.j, ?0.+0.j],
>>>>> ? ? ? ?[ 2.+1.j, ?3.+1.j, ?0.+0.j, ?0.+0.j],
>>>>> ? ? ? ?[ 3.+1.j, ?0.+0.j, ?0.+0.j, ?0.+0.j]])
>>>>>
>>>>>
>>>>>
>>>>>>>> scipy.linalg.toeplitz(np.arange(4)+1.j)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> Warning: column and row values don't agree; column value used.
>>>>> array([[ 0.+1.j, ?1.+1.j, ?2.+1.j, ?3.+1.j],
>>>>> ? ? ? ?[ 1.-1.j, ?0.+1.j, ?1.+1.j, ?2.+1.j],
>>>>> ? ? ? ?[ 2.-1.j, ?1.-1.j, ?0.+1.j, ?1.+1.j],
>>>>> ? ? ? ?[ 3.-1.j, ?2.-1.j, ?1.-1.j, ?0.+1.j]])
>>>>>
>>>>>
>>>>> requiring the diagonal to be real might be too tough, I'm not using
>>>>> complex toeplitz, but for other cases, I often have "almost real"
>>>>> values, up to numerical imprecision.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> This could be dealt with like Matlab does: don't worry about it, and
>>>> just use c[1:] to fill in r[1:]. ?If c[0] is has nonzero imaginary part,
>>>> then the matrix is not Hermitian--but that's OK, since that is what the
>>>> user gave to the function.
>>>>
>>>> Your example illustrates one of the bugs: note that, except for the
>>>> first element, the first column is the *conjugate* of the first
>>>> argument. ?The docstring says that `c` is the first column (and the
>>>> optional second argument is the first row). ?So it is the elements in
>>>> the first row starting in the second column that should be conjugated.
>>>> It also prints that annoying warning.
>>>>
>>
>> That's how I interpreted the bug
>>
>>
>>
>>>>
>>>>>>>> scipy.linalg.toeplitz(np.arange(4)*1.j,-np.arange(4)*1.j)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> array([[ 0.+0.j, ?0.-1.j, ?0.-2.j, ?0.-3.j],
>>>>> ? ? ? ?[ 0.+1.j, ?0.+0.j, ?0.-1.j, ?0.-2.j],
>>>>> ? ? ? ?[ 0.+2.j, ?0.+1.j, ?0.+0.j, ?0.-1.j],
>>>>> ? ? ? ?[ 0.+3.j, ?0.+2.j, ?0.+1.j, ?0.+0.j]])
>>>>>
>>>>> also for real values ?r[0] != c[0] might not be satisfied if there is
>>>>> numerical imprecision and they are only almost equal.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> True. ?So if the requirement that r[0] == c[0] is strict, a user who
>>>> knows the first values are "close enough", but maybe not exactly equal,
>>>> would have to do something like:
>>>>
>>>> r[0] = c[0]
>>>> t = toeplitz(c, r)
>>>>
>>>> I could live with that, but not everyone will agree.
>>>>
>>>> Instead, the function could require that the values be "close", using
>>>> something like numpy.allclose(), but how close is close enough? ?Should
>>>> the function then have `atol` and `rtol` arguments to use for the
>>>> comparison? ?This feels like overkill, and is not my preference.
>>>>
>>>> So that leaves the behavior used by Matlab: use c[0], and ignore r[0].
>>>> But I don't like the printed warning (or any logged warning) when c[0]
>>>> != r[0]. ?If the program is behaving correctly, and as documented, no
>>>> warning should be necessary.
>>>>
>>
>> raising a proper Warning might be useful and avoid the almost equal issue
>>
>> I think, all the uses I have seen use only a single argument to build
>> the symmetric toeplitz matrix.
>>
>> Josef
>>
>>
>>
>>>> (If I could start from scratch, I would simply define the `r` argument
>>>> to give the values from the second column onward, and so completely
>>>> avoid the issue.)
>>>>
>>>> Warren
>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From warren.weckesser at enthought.com  Sun Mar 21 11:54:58 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 21 Mar 2010 10:54:58 -0500
Subject: [SciPy-Dev] Reguest for easy patch review--ticket #1113
Message-ID: <4BA64152.8010503@enthought.com>

Hi,

I submitted a patch to ticket #1113 that is just two lines added to the 
eig() function of scipy.linalg (along with some tests).  I think it's a 
no-brainer, but I'd still like at least one other person to take a look 
and give it a thumbs up before I commit it.

Thanks,

Warren



From robert.kern at gmail.com  Sun Mar 21 16:06:11 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 21 Mar 2010 15:06:11 -0500
Subject: [SciPy-Dev] Reguest for easy patch review--ticket #1113
In-Reply-To: <4BA64152.8010503@enthought.com>
References: <4BA64152.8010503@enthought.com>
Message-ID: <3d375d731003211306r4da0072eg8dcb786b3b1439d2@mail.gmail.com>

On Sun, Mar 21, 2010 at 10:54, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> Hi,
>
> I submitted a patch to ticket #1113 that is just two lines added to the
> eig() function of scipy.linalg (along with some tests). ?I think it's a
> no-brainer, but I'd still like at least one other person to take a look
> and give it a thumbs up before I commit it.

Looks good to me. Style nit: I would start using the
ValueError("message") syntax instead of the deprecated ValueError,
"message" syntax. One less thing for 2to3 to deal with.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From warren.weckesser at enthought.com  Sun Mar 21 16:39:39 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 21 Mar 2010 15:39:39 -0500
Subject: [SciPy-Dev] Reguest for easy patch review--ticket #1113
In-Reply-To: <3d375d731003211306r4da0072eg8dcb786b3b1439d2@mail.gmail.com>
References: <4BA64152.8010503@enthought.com>
	<3d375d731003211306r4da0072eg8dcb786b3b1439d2@mail.gmail.com>
Message-ID: <4BA6840B.4050009@enthought.com>

Robert Kern wrote:
> On Sun, Mar 21, 2010 at 10:54, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>   
>> Hi,
>>
>> I submitted a patch to ticket #1113 that is just two lines added to the
>> eig() function of scipy.linalg (along with some tests).  I think it's a
>> no-brainer, but I'd still like at least one other person to take a look
>> and give it a thumbs up before I commit it.
>>     
>
> Looks good to me. Style nit: I would start using the
> ValueError("message") syntax instead of the deprecated ValueError,
> "message" syntax. One less thing for 2to3 to deal with.
>
>   

Good point--thanks.  I made that change and checked it in.

Warren



From warren.weckesser at enthought.com  Sun Mar 21 16:51:25 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 21 Mar 2010 15:51:25 -0500
Subject: [SciPy-Dev] Another easy patch review: ticket #996
Message-ID: <4BA686CD.4070707@enthought.com>

I added a patch to ticket #996 that implements the change discussed 
there.  The change to the code is trivial; the main issue is that 
everyone else agrees that the `find` function should return the list of 
keys instead of printing them.  Personally I think it's another no-brainer.

Warren



From robert.kern at gmail.com  Sun Mar 21 17:08:12 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 21 Mar 2010 16:08:12 -0500
Subject: [SciPy-Dev] Another easy patch review: ticket #996
In-Reply-To: <4BA686CD.4070707@enthought.com>
References: <4BA686CD.4070707@enthought.com>
Message-ID: <3d375d731003211408t46c0df8ctdd110970ea0e1bb2@mail.gmail.com>

On Sun, Mar 21, 2010 at 15:51, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> I added a patch to ticket #996 that implements the change discussed
> there. ?The change to the code is trivial; the main issue is that
> everyone else agrees that the `find` function should return the list of
> keys instead of printing them. ?Personally I think it's another no-brainer.

Requests for "no-brainer" reviews tend to go faster when they include
a link to the ticket. :-)

Anyways, +1 on the patch.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From warren.weckesser at enthought.com  Sun Mar 21 17:13:31 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 21 Mar 2010 16:13:31 -0500
Subject: [SciPy-Dev] Another easy patch review: ticket #996
In-Reply-To: <3d375d731003211408t46c0df8ctdd110970ea0e1bb2@mail.gmail.com>
References: <4BA686CD.4070707@enthought.com>
	<3d375d731003211408t46c0df8ctdd110970ea0e1bb2@mail.gmail.com>
Message-ID: <4BA68BFB.9090903@enthought.com>

Robert Kern wrote:
> On Sun, Mar 21, 2010 at 15:51, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>   
>> I added a patch to ticket #996 that implements the change discussed
>> there.  The change to the code is trivial; the main issue is that
>> everyone else agrees that the `find` function should return the list of
>> keys instead of printing them.  Personally I think it's another no-brainer.
>>     
>
> Requests for "no-brainer" reviews tend to go faster when they include
> a link to the ticket. :-)
>   

+1 on the suggestion--noted for future reference.

> Anyways, +1 on the patch.
>
>   

OK, in it goes.

Warren



From rob.clewley at gmail.com  Sun Mar 21 17:14:37 2010
From: rob.clewley at gmail.com (Rob Clewley)
Date: Sun, 21 Mar 2010 17:14:37 -0400
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <45d1ab481003201223j213f06f3q84608f431431d383@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
	<1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
	<45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
	<a749952d1003200930h61f0634bw4a0554a7e584e088@mail.gmail.com>
	<45d1ab481003201223j213f06f3q84608f431431d383@mail.gmail.com>
Message-ID: <a749952d1003211414p573e667ahe36351f38e8348df@mail.gmail.com>

David,

> Rob: since no one else (besides Josef of course) is chiming in (in
> particular, to "block"), may I suggest/request that you:
>
> 0) file an "enhancement" ticket for this improvement;

Done

> 1) if you have the time and wherewithal, "own" the ticket, implement
> the improvement (taking care to do so in such a way that the
> function's extant API is not broken), and submit your patch;

I don't see how to take ownership on the trac site. Please direct me!

> If you need guidance in any of this (e.g., locating the scipy
> developer's Trac page whereon tickets are filed) - or are just to
> swamped - let me know and I'll be happy to help. ?Thanks for reporting
> this.

I am pretty swamped but sooner or later I will feel the OCD take over
and do something about it. Of course others are welcome in the
meantime.

-Rob


From d.l.goldsmith at gmail.com  Sun Mar 21 18:58:05 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Sun, 21 Mar 2010 15:58:05 -0700
Subject: [SciPy-Dev] Doc error in scipy.optimize.fmin and missing info
	in ref guide
In-Reply-To: <a749952d1003211414p573e667ahe36351f38e8348df@mail.gmail.com>
References: <a749952d1003151605o5ade38cdta3848a5d0e66ef91@mail.gmail.com>
	<45d1ab481003191216j21755413t45fbd710a40fc07a@mail.gmail.com>
	<1cd32cbb1003191237i7f7ffacbw17be6533843fc84a@mail.gmail.com>
	<45d1ab481003191305s4f57603al6b4a48dac776b7d4@mail.gmail.com>
	<1cd32cbb1003191309q916c42bu43090d6afd1ee229@mail.gmail.com>
	<45d1ab481003191351r6b818182u87c4bd5042c1bd32@mail.gmail.com>
	<a749952d1003200930h61f0634bw4a0554a7e584e088@mail.gmail.com>
	<45d1ab481003201223j213f06f3q84608f431431d383@mail.gmail.com>
	<a749952d1003211414p573e667ahe36351f38e8348df@mail.gmail.com>
Message-ID: <45d1ab481003211558q2b208fb0o2d3786502604c64e@mail.gmail.com>

On Sun, Mar 21, 2010 at 2:14 PM, Rob Clewley <rob.clewley at gmail.com> wrote:
> David,
>
>> Rob: since no one else (besides Josef of course) is chiming in (in
>> particular, to "block"), may I suggest/request that you:
>>
>> 0) file an "enhancement" ticket for this improvement;
>
> Done

Great, thanks!

>> 1) if you have the time and wherewithal, "own" the ticket, implement
>> the improvement (taking care to do so in such a way that the
>> function's extant API is not broken), and submit your patch;
>
> I don't see how to take ownership on the trac site. Please direct me!

Yeah, I'm not getting an "Assign to" field either, nor could I readily
find instructions vis-a-vis gaining ownership privileges: my guess is
that you have to ask for "assume ownership" privileges (presumably
here) and, assuming they're granted, when you re-login and visit the
ticket's page, then you'll see the "Assign to" drop down w/ your
account name in it.  (This said, it appears that you can submit a
patch w/out having to claim ownership, so I imagine you could treat
this entire step as optional.)

>> If you need guidance in any of this (e.g., locating the scipy
>> developer's Trac page whereon tickets are filed) - or are just to
>> swamped - let me know and I'll be happy to help. ?Thanks for reporting
>> this.
>
> I am pretty swamped but sooner or later I will feel the OCD take over
> and do something about it. Of course others are welcome in the
> meantime.

Of course. ;-)

Thanks again!

DG

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


From fuoss at anl.gov  Tue Mar 23 10:57:04 2010
From: fuoss at anl.gov (Paul Fuoss)
Date: Tue, 23 Mar 2010 09:57:04 -0500
Subject: [SciPy-Dev] Installing scipy on OS 10.6.2
Message-ID: <C7CE40F0.26C26%fuoss@anl.gov>

I have been unsuccessful at installing scipy on OS 10.6.  When I try
to build from the distribution, I get a huge number of library
architecture errors. I've tried to build both against the python
that comes with the system (2.6.1) and against the MacPort python
(2.6.5)  (see test summary at end of message).

When I try to install via MacPort, it appears to install but much
functionality is missing (e.g. curve_fit) that I assume is because
the BLAS and LAPACK libraries aren't being linked to correctly.

I'm using OS 10.6.2 on an Intel iMac.

The latest Xcode is installed (3.2.1) with:
  i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)

gfortran from research.att.acom:
  GNU Fortran (GCC) 4.2.3

I would appreciate suggestions.

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/fftpack/_fftpack.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/fftpack/_fftpack.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/special/_cephes.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/special/_cephes.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: test_integer (test_array_import.TestReadArray)
----------------------------------------------------------------------
ImportError: 
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pytho
n2.6/site-packages/scipy/special/_cephes.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/special/_cephes.so: no matching architecture in universal
wrapper

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/lib/blas/fblas.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/lib/blas/fblas.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/lib/lapack/calc_lwork.so, 2): no suitable image
found.  Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/lib/lapack/calc_lwork.so: no matching architecture in
universal wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/linalg/flapack.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/linalg/flapack.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------
======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/sparse/linalg/isolve/_iterative.so, 2): no
suitable image found.  Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/sparse/linalg/isolve/_iterative.so: no matching
architecture in universal wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/optimize/minpack2.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/optimize/minpack2.so: no matching architecture in
universal wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/odr/__odrpack.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/odr/__odrpack.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/optimize/minpack2.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/optimize/minpack2.so: no matching architecture in
universal wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/special/_cephes.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/special/_cephes.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------
======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/sparse/linalg/isolve/_iterative.so, 2): no
suitable image found.  Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/sparse/linalg/isolve/_iterative.so: no matching
architecture in universal wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/sparse/linalg/isolve/_iterative.so, 2): no
suitable image found.  Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/sparse/linalg/isolve/_iterative.so: no matching
architecture in universal wrapper)
----------------------------------------------------------------------

======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/special/_cephes.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/special/_cephes.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------
======================================================================
ERROR: Failure: ImportError
(dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/site-packages/scipy/special/_cephes.so, 2): no suitable image found.
Did find:
    
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/si
te-packages/scipy/special/_cephes.so: no matching architecture in universal
wrapper)
----------------------------------------------------------------------

======================================================================
FAIL: test_mio.test_warnings(<type 'exceptions.FutureWarning'>, <function
loadmat at 0x1048f61b8>,
'/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/s
ite-packages/scipy/io/matlab/tests/data/testdouble_7.1_GLNX86.mat')
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/s
ite-packages/nose/case.py", line 183, in runTest
    self.test(*self.arg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/s
ite-packages/numpy/testing/utils.py", line 693, in assert_raises
    return nose.tools.assert_raises(*args,**kwargs)
AssertionError: FutureWarning not raised

----------------------------------------------------------------------
Ran 1382 tests in 428.657s

FAILED (KNOWNFAIL=6, SKIP=3, errors=16, failures=1)
Out[3]: <nose.result.TextTestResult run=1382 errors=16 failures=1>





From ralf.gommers at googlemail.com  Tue Mar 23 11:10:04 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 23 Mar 2010 23:10:04 +0800
Subject: [SciPy-Dev] Installing scipy on OS 10.6.2
In-Reply-To: <C7CE40F0.26C26%fuoss@anl.gov>
References: <C7CE40F0.26C26%fuoss@anl.gov>
Message-ID: <dde7764a1003230810j5e447b41p2f98bc6ce79c1b50@mail.gmail.com>

On Tue, Mar 23, 2010 at 10:57 PM, Paul Fuoss <fuoss at anl.gov> wrote:

> I have been unsuccessful at installing scipy on OS 10.6.  When I try
> to build from the distribution, I get a huge number of library
> architecture errors. I've tried to build both against the python
> that comes with the system (2.6.1) and against the MacPort python
> (2.6.5)  (see test summary at end of message).
>
> When I try to install via MacPort, it appears to install but much
> functionality is missing (e.g. curve_fit) that I assume is because
> the BLAS and LAPACK libraries aren't being linked to correctly.
>
> I'm using OS 10.6.2 on an Intel iMac.
>
> The latest Xcode is installed (3.2.1) with:
>  i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
>
> gfortran from research.att.acom:
>  GNU Fortran (GCC) 4.2.3
>
> I would appreciate suggestions.
>

How are you trying to build? The error suggests you are building for the
wrong achitecture (32 vs 64-bit).

I have been able to build against the Apple-provided python but not the
python.org version so far. The difference is that the former is 64-bit while
the latter is 32-bit. For Apple Python, install numscons (
http://projects.scipy.org/numpy/wiki/NumScons) and gfortran (from
http://r.research.att.com/tools/) and use:
$ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
setupscons.py scons

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

From fuoss at anl.gov  Tue Mar 23 13:03:06 2010
From: fuoss at anl.gov (Paul H. Fuoss)
Date: Tue, 23 Mar 2010 12:03:06 -0500 (CDT)
Subject: [SciPy-Dev] Installing scipy on OS 10.6.2
In-Reply-To: <dde7764a1003230810j5e447b41p2f98bc6ce79c1b50@mail.gmail.com>
Message-ID: <5223709.256011269363786766.JavaMail.root@zimbra>

Ralf,

I downloaded scipy from svn.  Then I did the command:

$ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" sudo python setupscons.py install

Trying this dies with:

scons: done building targets.
Executing scons command (pkg is scipy.fftpack): /usr/bin/python "/Library/Python/2.6/site-packages/numscons-0.10.1-py2.6.egg/numscons/scons-local/scons.py" -f scipy/fftpack/SConstruct -I. scons_tool_path="" src_dir="scipy/fftpack" pkg_name="scipy.fftpack" log_level=50 distutils_libdir="../../../../build/lib.macosx-10.6-universal-2.6" cc_opt=gcc-4.2 cc_opt_path="/usr/bin" f77_opt=gfortran f77_opt_path="/usr/local/bin" cxx_opt=g++-4.2 cxx_opt_path="/usr/bin" include_bootstrap=/Library/Python/2.6/site-packages/numpy-1.3.0-py2.6-macosx-10.6-universal.egg/numpy/core/include silent=0 bootstrapping=0 
scons: Reading SConscript files ...
Mkdir("build/scons/scipy/fftpack")
AttributeError: SConfBase instance has no attribute 'CheckF77Mangling':
  File "/Users/fuossadmin/Desktop/Downloads/scipy/scipy/fftpack/SConstruct", line 2:
    GetInitEnvironment(ARGUMENTS).DistutilsSConscript('SConscript')
  File "/Library/Python/2.6/site-packages/numscons-0.10.1-py2.6.egg/numscons/core/numpyenv.py", line 108:
    build_dir = '$build_dir', src_dir = '$src_dir')
  File "/Library/Python/2.6/site-packages/numscons-0.10.1-py2.6.egg/numscons/scons-local/scons-local-1.2.0/SCons/Script/SConscript.py", line 549:
    return apply(_SConscript, [self.fs,] + files, subst_kw)
  File "/Library/Python/2.6/site-packages/numscons-0.10.1-py2.6.egg/numscons/scons-local/scons-local-1.2.0/SCons/Script/SConscript.py", line 259:
    exec _file_ in call_stack[-1].globals
  File "/Users/fuossadmin/Desktop/Downloads/scipy/build/scons/scipy/fftpack/SConscript", line 11:
    config.CheckF77Mangling()
error: Error while executing scons command. See above for more information.
If you think it is a problem in numscons, you can also try executing the scons
command with --log-level option for more detailed output of what numscons is
doing, for example --log-level=0; the lowest the level is, the more detailed
the output it.

Any clues?

Thanks.

Paul

----- Original Message -----
From: "Ralf Gommers" <ralf.gommers at googlemail.com>
To: "SciPy Developers List" <scipy-dev at scipy.org>
Sent: Tuesday, March 23, 2010 10:10:04 AM GMT -06:00 US/Canada Central
Subject: Re: [SciPy-Dev] Installing scipy on OS 10.6.2





On Tue, Mar 23, 2010 at 10:57 PM, Paul Fuoss < fuoss at anl.gov > wrote: 


I have been unsuccessful at installing scipy on OS 10.6. When I try 
to build from the distribution, I get a huge number of library 
architecture errors. I've tried to build both against the python 
that comes with the system (2.6.1) and against the MacPort python 
(2.6.5) (see test summary at end of message). 

When I try to install via MacPort, it appears to install but much 
functionality is missing (e.g. curve_fit) that I assume is because 
the BLAS and LAPACK libraries aren't being linked to correctly. 

I'm using OS 10.6.2 on an Intel iMac. 

The latest Xcode is installed (3.2.1) with: 
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) 

gfortran from research.att.acom: 
GNU Fortran (GCC) 4.2.3 

I would appreciate suggestions. 


How are you trying to build? The error suggests you are building for the wrong achitecture (32 vs 64-bit). 

I have been able to build against the Apple-provided python but not the python.org version so far. The difference is that the former is 64-bit while the latter is 32-bit. For Apple Python, install numscons ( http://projects.scipy.org/numpy/wiki/NumScons ) and gfortran (from http://r.research.att.com/tools/ ) and use: 
$ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python setupscons.py scons 

Cheers, 
Ralf 

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


From cournape at gmail.com  Tue Mar 23 19:33:44 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 24 Mar 2010 08:33:44 +0900
Subject: [SciPy-Dev] Installing scipy on OS 10.6.2
In-Reply-To: <5223709.256011269363786766.JavaMail.root@zimbra>
References: <dde7764a1003230810j5e447b41p2f98bc6ce79c1b50@mail.gmail.com>
	<5223709.256011269363786766.JavaMail.root@zimbra>
Message-ID: <5b8d13221003231633k62b22c8cxfc186e616fd3ef33@mail.gmail.com>

On Wed, Mar 24, 2010 at 2:03 AM, Paul H. Fuoss <fuoss at anl.gov> wrote:
> Ralf,
>
> I downloaded scipy from svn. ?Then I did the command:
>
> $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" sudo python setupscons.py install

Don't use sudo (it modifies how environment variables are handled),
and remove the unnecessary -lgfortran. from LDFLAGS.

David


From thouis at broad.mit.edu  Tue Mar 23 20:10:30 2010
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Tue, 23 Mar 2010 20:10:30 -0400
Subject: [SciPy-Dev] Installing scipy on OS 10.6.2
In-Reply-To: <5b8d13221003231633k62b22c8cxfc186e616fd3ef33@mail.gmail.com>
References: <dde7764a1003230810j5e447b41p2f98bc6ce79c1b50@mail.gmail.com> 
	<5223709.256011269363786766.JavaMail.root@zimbra>
	<5b8d13221003231633k62b22c8cxfc186e616fd3ef33@mail.gmail.com>
Message-ID: <6c17e6f51003231710m51460feai196e1f1afef16570@mail.gmail.com>

While trying to build universal binaries on 10.5, I found that editing
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/Makefile
was easier than trying to fight my way through to a working set of
environment variables.

My particular changes were to modify these lines:
BASECFLAGS=     -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk  -fno-strict-aliasing -no-cpp-precomp
-mno-fused-madd -fno-common -dynamic
LDFLAGS=        -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g
UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk
CONFIG_ARGS=    '-C' '--enable-framework'
'--enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk' 'LDFLAGS=-g '
'OPT=-g -O3 '
MACOSX_DEPLOYMENT_TARGET=10.3

After those changes, "python setup.py build" for numpy & scipy worked
without problems, and without other variables being set.

This may apply to your situation as well (using x86_64 to replace the
other architectures).

Thouis Jones



On Tue, Mar 23, 2010 at 19:33, David Cournapeau <cournape at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 2:03 AM, Paul H. Fuoss <fuoss at anl.gov> wrote:
>> Ralf,
>>
>> I downloaded scipy from svn. ?Then I did the command:
>>
>> $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" sudo python setupscons.py install
>
> Don't use sudo (it modifies how environment variables are handled),
> and remove the unnecessary -lgfortran. from LDFLAGS.
>
> David
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From warren.weckesser at enthought.com  Tue Mar 23 23:56:23 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Tue, 23 Mar 2010 22:56:23 -0500
Subject: [SciPy-Dev] Patch review request: adding hadamard function to
	scipy.linalg
Message-ID: <4BA98D67.2030101@enthought.com>

I submitted a patch to ticket #675:  
http://projects.scipy.org/scipy/ticket/675

It adds a function that generates Hadamard matrices.  The code is a 
slightly modified version of the code submitted by Ivo in the ticket.  
If anyone has a moment, take a look and let me know what you think.  The 
function is only a few lines, so a review shouldn't take long.  I'd like 
to have at least one other set of eyes on the code before checking it in.

Cheers,

Warren



From warren.weckesser at enthought.com  Wed Mar 24 14:40:23 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 24 Mar 2010 13:40:23 -0500
Subject: [SciPy-Dev] scipy.misc.ppimport
Message-ID: <4BAA5C97.5070504@enthought.com>

Hi,

A new ticket on the scipy trac 
(http://projects.scipy.org/scipy/ticket/1136) reports a problem with 
scipy.misc.ppimport.  Not long ago I fixed a couple blatant typos in 
ppimport.py (because of another ticket, 
http://projects.scipy.org/scipy/ticket/1133), but I didn't actually try 
to use the ppimport() function.

I think this code has problems.  There was code in there that could 
never have worked, and there are no tests.

I'm not going to have time to work on ppimport, and after a little 
searching, I wonder if anyone should bother.  In scipy trunk, the only 
actual use of anything related to ppimport is in the info() function in 
misc.helpmod.py, and it just checks if the object for which info is 
being requested has attributes assigned by ppimport.  But if nothing 
else in scipy actually uses ppimport, the code in info() is moot.

All the info.py files of the various scipy packages contain 
'postpone_import = 1', but I don't see any code that actually uses this 
variable.

What's the history of ppimport?  Why does it exist in scipy?  Pearu 
Peterson worked on this several years ago, but it is not clear to me how 
it is currently used.  Can we simply get rid of it, or am I missing 
something?

Warren




From robert.kern at gmail.com  Wed Mar 24 14:43:27 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Mar 2010 13:43:27 -0500
Subject: [SciPy-Dev] scipy.misc.ppimport
In-Reply-To: <4BAA5C97.5070504@enthought.com>
References: <4BAA5C97.5070504@enthought.com>
Message-ID: <3d375d731003241143s4eb86945j19c661d47c36e19d@mail.gmail.com>

On Wed, Mar 24, 2010 at 13:40, Warren Weckesser
<warren.weckesser at enthought.com> wrote:

> I'm not going to have time to work on ppimport, and after a little
> searching, I wonder if anyone should bother.

No. We stopped using it. Consider it deprecated.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From david at silveregg.co.jp  Sun Mar 28 22:04:30 2010
From: david at silveregg.co.jp (David Cournapeau)
Date: Mon, 29 Mar 2010 11:04:30 +0900
Subject: [SciPy-Dev] Regenerating Swig-generated files with Swig 1.3.40 ?
Message-ID: <4BB00AAE.8060902@silveregg.co.jp>

Hi,

I would like to know if there is any objection to regenerate the swig 
source files with the last SWIG ? I have started working on py3 support 
for scipy, and the recent SWIG have added support for py3 compatibility 
(>= 1.3.37, we currently use 1.3.36). The main drawback I can see is 
that it would require people to build their own swig if they want to 
modify the code, as few distributions support such recent swig releases.

cheers,

David


From robert.kern at gmail.com  Mon Mar 29 10:31:04 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 29 Mar 2010 09:31:04 -0500
Subject: [SciPy-Dev] Regenerating Swig-generated files with Swig 1.3.40 ?
In-Reply-To: <4BB00AAE.8060902@silveregg.co.jp>
References: <4BB00AAE.8060902@silveregg.co.jp>
Message-ID: <3d375d731003290731l411d0781j3d5a67f5c60f687b@mail.gmail.com>

On Sun, Mar 28, 2010 at 21:04, David Cournapeau <david at silveregg.co.jp> wrote:
> Hi,
>
> I would like to know if there is any objection to regenerate the swig
> source files with the last SWIG ? I have started working on py3 support
> for scipy, and the recent SWIG have added support for py3 compatibility
> (>= 1.3.37, we currently use 1.3.36). The main drawback I can see is
> that it would require people to build their own swig if they want to
> modify the code, as few distributions support such recent swig releases.

I'm okay with that. Go for it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From jh at physics.ucf.edu  Mon Mar 29 20:52:32 2010
From: jh at physics.ucf.edu (Joe Harrington)
Date: Mon, 29 Mar 2010 20:52:32 -0400
Subject: [SciPy-Dev] [burtscher@mpia-hd.mpg.de: Dead links on scipy Download
	page]
Message-ID: <wl8pr2mvdf3.fsf@glup.physics.ucf.edu>

>From an Alert Reader...

> From: Leonard Burtscher <burtscher at mpia-hd.mpg.de>
> To: jharring at physics.ucf.edu
> Subject: Dead links on scipy Download page
> Date: Thu, 25 Mar 2010 21:04:37 +0100

> Joe,

> Just wanted to let you know that the two links to macinscience.org on http://www.scipy.org/Download 
>   are not working anymore.

> Best,
> Leonard Burtscher

Chris F., are you out there?  Else, does anyone know what's up with
that site?

--jh--


From gombiuda at gmail.com  Tue Mar 30 04:07:43 2010
From: gombiuda at gmail.com (gombiuda JHL)
Date: Tue, 30 Mar 2010 16:07:43 +0800
Subject: [SciPy-Dev] GSoC: scipy porting to py3k
Message-ID: <4c900f171003300107i3e7d8c7erc6432b4a3f14d879@mail.gmail.com>

Hi all, I would like to take part in porting the scipy to python3.0 in GSoC.

I have been a programmer for 9 years and the first 6 years I focus myself in
algorithm and data structure. I use python for almost 2 years, and have read
part of the python source code. I think I can manage to do this job.

And what I want to ask is, how many people it needs to do the porting? I
don't know how to arrange my time in the proposal. Is there anyone give me a
hand. Thanks a lot.

If possible, please give me some guidelines to follow. Thanks again.

-- 
Sincerely,
Gombiuda Jiang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100330/93442273/attachment.html>

From warren.weckesser at enthought.com  Wed Mar 31 01:02:51 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 31 Mar 2010 00:02:51 -0500
Subject: [SciPy-Dev] Candidates for closing
Message-ID: <4BB2D77B.2020903@enthought.com>

I think these tickets can now be closed:

http://projects.scipy.org/scipy/ticket/667
http://projects.scipy.org/scipy/ticket/675
http://projects.scipy.org/scipy/ticket/996
http://projects.scipy.org/scipy/ticket/1002
http://projects.scipy.org/scipy/ticket/1128


Warren



From warren.weckesser at enthought.com  Wed Mar 31 01:15:04 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 31 Mar 2010 00:15:04 -0500
Subject: [SciPy-Dev] Speaking of tickets...
Message-ID: <4BB2DA58.2050903@enthought.com>

Just curious: what are the plans for the "Statistic Review" tickets in 
scipy.stats, from April, 2006?  Can any of these be closed?

Warren



From david at silveregg.co.jp  Wed Mar 31 01:44:48 2010
From: david at silveregg.co.jp (David Cournapeau)
Date: Wed, 31 Mar 2010 14:44:48 +0900
Subject: [SciPy-Dev] Candidates for closing
In-Reply-To: <4BB2D77B.2020903@enthought.com>
References: <4BB2D77B.2020903@enthought.com>
Message-ID: <4BB2E150.8060604@silveregg.co.jp>

Warren Weckesser wrote:
> I think these tickets can now be closed:
> 
> http://projects.scipy.org/scipy/ticket/667
> http://projects.scipy.org/scipy/ticket/675
> http://projects.scipy.org/scipy/ticket/996
> http://projects.scipy.org/scipy/ticket/1002
> http://projects.scipy.org/scipy/ticket/1128

Thanks for those fixes/patches ! I closed the entries. Just two trivial 
comments:
  - in trac, it is better to use rNNNN instead of rev NNNN (so that the 
link appears in the ticket)
  - unix EOL is preferable to windows EOL in general. How do to so 
depends on your editor (you only need to care when creating a new file, 
as any decent editor will automatically detect and use the correct line 
ending for an existing file)

thanks,

David



From warren.weckesser at enthought.com  Wed Mar 31 01:50:36 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 31 Mar 2010 00:50:36 -0500
Subject: [SciPy-Dev] Candidates for closing
In-Reply-To: <4BB2E150.8060604@silveregg.co.jp>
References: <4BB2D77B.2020903@enthought.com> <4BB2E150.8060604@silveregg.co.jp>
Message-ID: <4BB2E2AC.4020201@enthought.com>

David Cournapeau wrote:
> Warren Weckesser wrote:
>   
>> I think these tickets can now be closed:
>>
>> http://projects.scipy.org/scipy/ticket/667
>> http://projects.scipy.org/scipy/ticket/675
>> http://projects.scipy.org/scipy/ticket/996
>> http://projects.scipy.org/scipy/ticket/1002
>> http://projects.scipy.org/scipy/ticket/1128
>>     
>
> Thanks for those fixes/patches ! I closed the entries.

Thanks!

>  Just two trivial 
> comments:
>   - in trac, it is better to use rNNNN instead of rev NNNN (so that the 
> link appears in the ticket)
>   

I noticed that feature a few days ago, and just recently started using 
rNNNN.

>   - unix EOL is preferable to windows EOL in general. How do to so 
> depends on your editor (you only need to care when creating a new file, 
> as any decent editor will automatically detect and use the correct line 
> ending for an existing file)
>   

I saw that check-in you made to change the EOL style.  I'm not sure how 
the file ended up with Windows EOL, since I'm usually working on a Mac, 
and I think the other files that I've created are correct.  I might have 
been dabbling with a new editor at the time.  Thanks for fixing it.

Cheers,

Warren



From martin.druon at wanadoo.fr  Wed Mar 31 08:37:56 2010
From: martin.druon at wanadoo.fr (Martin DRUON)
Date: Wed, 31 Mar 2010 14:37:56 +0200 (CEST)
Subject: [SciPy-Dev] Evolution of the generic_filter function
Message-ID: <21455464.99120.1270039076470.JavaMail.www@wwinf1k01>

Hi,

first, like it is my first post here, I would like to congratulate you for your great job... thank you very much...

Now, my question. It seems that the function "scipy.ndimage.generic_filter" can only operate onto scalar objets like float or int. Moreover, it returns 
only float objects. Do you think that, in the near future, this function will be able to treat generic objects like tuples or user classes ? In that case, we 
will be able to treat directly, for example, vector fields or color images. We will also be able to apply a function onto multiple arrays at the same time, 
with the same windowing. Then, to my mind, this method will become very powerful for image processing tools.

If this evolution is not scheduled, how I can substitute this method ? For example, I would like to call a function fct(win_a, win_b) with "win_a" a 
window extracted from an array "a" and "win_b" the same window extracted from "b".


Example : 

# The original fields : two 2D vector fields with 2 components for each vector
field_size = (5,5)
a = numpy.random.random(field_size + (2,))
b = numpy.random.random(field_size + (2,))


# A simple function : the result is the sum of the element-wise product
def fct(win1,win2):
return (win1 * win2).sum()


# And now, the new generic_filter() which operates simultaneously onto sub-windows of multiple arrays
# "c" is the result field : a 2D scalar field with the same size "field_size"
c = scipy.ndimage.generic_filter( {"win1":a, "win2":b}, fct, size=(3,3), ...)

Thank you.

Martin




From zachary.pincus at yale.edu  Wed Mar 31 10:09:16 2010
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Wed, 31 Mar 2010 10:09:16 -0400
Subject: [SciPy-Dev] Evolution of the generic_filter function
In-Reply-To: <21455464.99120.1270039076470.JavaMail.www@wwinf1k01>
References: <21455464.99120.1270039076470.JavaMail.www@wwinf1k01>
Message-ID: <FA51D61B-EFAC-47FB-8DD8-183EF3B91814@yale.edu>

> Now, my question. It seems that the function  
> "scipy.ndimage.generic_filter" can only operate onto scalar objets  
> like float or int. Moreover, it returns only float objects. Do you  
> think that, in the near future, this function will be able to treat  
> generic objects like tuples or user classes ? In that case, we will  
> be able to treat directly, for example, vector fields or color  
> images. We will also be able to apply a function onto multiple  
> arrays at the same time, with the same windowing. Then, to my mind,  
> this method will become very powerful for image processing tools.

This change doesn't appear to be on anyone's radar yet... though I'm  
sure patches might be accepted! (But beware: ndimage is a pretty  
tangled codebase on the C side of things, which is why lots of  
improvements like this haven't been made.)

However, note that the generic_filter function is a performance  
disaster: it applies a *python* function to every element in an  
array... very slow. (As would be a vectorized replacement which took a  
"vector_axis" keyword, or one which worked on structured arrays.)

You might want to think about implementing in cython a replacement  
"generic_filter" (with vector arguments, of course), that could apply  
cdef'd functions (all within cython), if performance matters. There's  
some new mechanisms in the numpy C api for neighborhood iterators that  
would be useful for filtering like this, too. (But with limited  
options for boundary conditions.)

Alternately, here's a sketch of a technique I have used for "in- 
parallel" filtering in pure python. Note that there are no boundary  
conditions handled here, but you could deal with that:

a = numpy.random((100, 100, 2))
center = a[1:-1, 1:-1]
left = a[:-2, 1:-1]
right = a[2:, 1:-1]
up = a[1:-1, :-2]
down = a[1:-1, 2:]
boxfiltered_a = (center + left + right + up + down) / 5.

(obviously you could do this more elegantly / generically, but this is  
the idea...)

Or, perhaps you could figure out how to decompose the vectorized  
filtering operations you need into filtering on the individual  
components, then combining the components in parallel?

Zach


From josef.pktd at gmail.com  Wed Mar 31 13:32:08 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 31 Mar 2010 13:32:08 -0400
Subject: [SciPy-Dev] Speaking of tickets...
In-Reply-To: <4BB2DA58.2050903@enthought.com>
References: <4BB2DA58.2050903@enthought.com>
Message-ID: <v2v1cd32cbb1003311032ze26953c7na4b4d33022405d83@mail.gmail.com>

On Wed, Mar 31, 2010 at 1:15 AM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> Just curious: what are the plans for the "Statistic Review" tickets in
> scipy.stats, from April, 2006? ?Can any of these be closed?

short answer:
I looked at them and there are several that can be closed, especially
the functions that have been removed or depreciated. For others, I
have to check my notes to see which ones I verified and added tested.


long answer (this were my initial notes when I browsed the tickets):

I found them very inconvenient to work with. Many or most of them are
empty and I didn't find an easy way to get an overview which ones of
the tickets contain useful information and require attention.

I went through them randomly and over those that contain an
attachment, but never systematically. I prefer to open new tickets for
specific issues because they are easier to find. For a status overview
I keep my own list.

I changed, closed or reassigned only a few of them. The owner is still Robert.

trying out some options, I found this view

http://projects.scipy.org/scipy/query?status=accepted&status=apply&status=needs_decision&status=needs_review&status=needs_work&status=new&status=reopened&order=changetime&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=changetime&milestone=StatisticsCleanup&desc=1

which sorts tickets by changetime. Tickets up to #74 in the list have
some additional comments.

Is there a way to "Show under each result:  Description", but instead
of Description, I would like to get also the comments?

For the regular use of the trac tickets they don't create much noise
because the statistical review tickets don't count as open tickets.

Josef



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


From robert.kern at gmail.com  Wed Mar 31 13:57:44 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 31 Mar 2010 11:57:44 -0600
Subject: [SciPy-Dev] Speaking of tickets...
In-Reply-To: <v2v1cd32cbb1003311032ze26953c7na4b4d33022405d83@mail.gmail.com>
References: <4BB2DA58.2050903@enthought.com>
	<v2v1cd32cbb1003311032ze26953c7na4b4d33022405d83@mail.gmail.com>
Message-ID: <p2i3d375d731003311057q6810142bz62629e9f2ab1293@mail.gmail.com>

On Wed, Mar 31, 2010 at 11:32,  <josef.pktd at gmail.com> wrote:
> On Wed, Mar 31, 2010 at 1:15 AM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>> Just curious: what are the plans for the "Statistic Review" tickets in
>> scipy.stats, from April, 2006? ?Can any of these be closed?
>
> short answer:
> I looked at them and there are several that can be closed, especially
> the functions that have been removed or depreciated. For others, I
> have to check my notes to see which ones I verified and added tested.
>
>
> long answer (this were my initial notes when I browsed the tickets):
>
> I found them very inconvenient to work with. Many or most of them are
> empty and I didn't find an easy way to get an overview which ones of
> the tickets contain useful information and require attention.

Well, the point of them was to systematically review every function.
Those "empty" tickets need just as much attention as those that have
comments.

However, it's obvious that I dropped the ball on organizing that
effort. They may be systematically closed now.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From gombiuda at gmail.com  Wed Mar 31 19:12:40 2010
From: gombiuda at gmail.com (gombiuda JHL)
Date: Thu, 1 Apr 2010 07:12:40 +0800
Subject: [SciPy-Dev] GSoC: Speed Up 2to3 in Pattern Matching
Message-ID: <q2j4c900f171003311612ne2a546a1qbb28ce20167eeeb1@mail.gmail.com>

Hi all, firstly sorry for my length of the proposal.
My name is Gombiuda Jiang. Here is my proposal. I am eager to listen to all
kind of comments and advices. Thank you for reading my proposal.

GSoC: Speed Up 2to3 in Pattern Matching

Firstly, thank your for your time to have a glance of my proposal.

Idea Background
============================
As PSF pay more and more attention on porting projects using python 2.x to
python 3.x, developers in the community start to pay their efforts to port
their projects. Luckily, there is a great tool `2to3` helping them in
porting job automatically to some extent. However, `2to3` has its
limitations. Within these limitations, speed of the conversion can be
improved with another implementation to replace the using one. To be more
detail, `2to3` is slow because of its using back-tracking of its pattern
matching job. Back-tracking is easy to understand and implement, so firstly
it's put into used. In addition its implementation is using recursion
instead of loop. So as the payload of `2to3` is rocketing up, it eventually
shows its weakness of creating more and more frames to allow function calls.
As a result, it's necessary to use another algorithm to speed up the pattern
matching process.

Improvement
============================
As a traditional problem, pattern matching has some efficient algorithms.
One of them is named `McNaughton-Yamada-Thompson` algorithm, which bases on
NFA(Nondeterministic Finite Automata) theory. This theory can efficiently
judge if a string(token stream is also acceptable) can be matched a given
regular expression. So it reaches its basic requirements of the pattern
matching in `2to3` project.
After finishing implementing the algorithm and passing test cases to
certificate it works well, we can, if necessary, continue to improve more
using DFA theory, which may cost more memory and pattern-compiling time but
work faster in matching the patterns.

The details is described as below:

In original implementation, a pattern string of a fixer is firstly tokenized
and then compiled to a pattern syntax tree. Then it starts matching it with
the syntax tree of the python 2.x source code with back-tracking.
Here we use the original tokenizing result, then put it into a
`NFAGenerator` to generate the NFA. At last, we put a node of the syntax
tree which is generated from the python 2.x source code into the NFA, and
output the result of `True` or `False`. The left process(replacement
process) hasn't change.

So the changed things are a new `NFAGenerator` class, a new `NFAPattern`
class to represent the result of the generation result of the `NFAGenerator`
class. Here is the model of the two classes:

class NFAPattern(object):
    """
    Attributes:
-`content`: The original pattern to be matched
        -`graph`: A 2D array to store the transition diagram

    Methods:
-`optimize(self)`: Maybe implement later using DFA or some graph reduction
algorithms
-`match(self, node, result)`: Travels the tree to find out all matched node
and put them into result to be passed out
    """
    def __init__(self, content):
        self.graph = None
self.content = content

    def optimize(self):
        # Maybe implement later using DFA or some graph reduction algorithms
        pass

    def match(self, node, result=None):
        # Find out all matched node(as root) and put them into result to be
passed out
        pass

class NFAGenerator(object):
    """
    Basically the same as the original one `PatternCompiler` except of the
implementation of the compile_node() method.
    """
    def __init__(self):
        # implement like the original one in `PatternCompiler`
        pass

    def compile_pattern(self, input, debug=False):
        tokens = tokenize_wrapper(input)
        root = self.driver.parse_tokens(tokens, debug=debug)
        return self.compile_node(root)

    def compile_node(self, node):
        # implement base on `McNaughton-Yamada-Thompson` algorithm to
compile a pattern string into a NFA
        pass

With this improvement, the process will be more faster than before. But
there still contains protential to improve. Right, that's pararrelization.

Simplely, we can imagine that we have a bunch of files to be converted.
Multithread can be easily used because there is no sequence-relationship
between each file. As a result, the changes would be:

# Inside refactor.py
import threading
class RefactoringTool(object):
    # ....
    THREADS = 10

    def refactor_dir(self, dir_name, write=False, doctests_only=False):
    """
    """
        cl = threading.Condition(threading.Lock())
        def generate_filenames(dir_name):
            for dirpath, dirnames, filenames in os.walk(dir_name):
                for name in filenames:
                    if not name.startswith(".") and name.endswith("py"):
                        fullname = os.path.join(dirpath, name)
        yield fullname

def refacotr_one_file(iter):
    while True:
        cl.wait()
cl.acquire()
fullname = iter.next()
cl.release()
if fullname:
    self.refactor_file(fullname, write, doctests_only)
else:
    break

iter = generate_filenames(dir_name)
threads = []
        for i in range(THREADS):
    threads.append(threading.Thread(target=refacotr_one_file, args=(iter,)))
for thread in threads:
    thread.start()
 # ....

Time Schedule of GSoC
============================
April 27~May 6: Communicate with the mentor to get more requirement
information
May 7~May 16: Read more documentations to make sure the implementation.
May 17~May 26: Write the structure of the new implementation
May 27~June 6: Write test cases for testing and write benchmark tool for
checking out the efficiency.
June 7~July 6: Write the new implementation.
July 7~July 11: Testing and bug fixing.
July 12~July 16: Mid-term evaluation
July 17~July 26: Improvement from NFA to DFA or just reduce the graph of the
NFA or add multithread support
July 27~August 6: Scrub code and test
August 7~August 16: Write documentations
August 17: Pencil down

About Me
============================
Name: Gombiuda Jiang
University: Sun-Yat sen university of China
Major: Software Engineering
Email/Gtalk: gombiuda at gmail.com

Knowledge Background:
    - 9 years programming experience with 6 years focusing on algorithm and
data structure learning and 3 years software development experience.
    - Some experience of researching face detection and recognition using
Hidden-Markov-Model algorithm.
    - Some experience of researching text clustering with artifical
intelligence.
    - Fundermental courses at software school, like `Software Engineering`,
`Operating System`, ...

Prizes:
    - The first prize NOIP of primary group district and thus roll in high
school with bonus point added
    - The first prize NOIP of high school group district and thus
recommended to the Sun-Yat sen university
    - The third prize `Software Inovation Competition` at Sun-Yat sen
university
    - The second prize `Commercial Software Inovation Competition` which is
hold by Citizen Bank

Development Experience:
    - A RSS news reader using C++ in 2007
    - A commercial website in Citizen Bank competition using Java SSH
    - A educational online-judge website using python and django which is
put into use in our software school.
    - Some small tools like file format convertor, auto voter via Internet,
cheater of the Travian game, and so on.

Why Me?
============================
I have been using Linux as my default system for years and I like open
source very much. I do want to contribute my energy to the community
continuously. I have been using python for nearly 2 years and I like it very
much for is efficiency. So I read part of the source code of python and got
to realize its internal structure. As a result, I'd like to take part in
developing the python projects, especially the core and the built-in
libraries. And with a strong algorithm ability, I think I can manage to do
it!

Future View
============================
I would like to join the group of developing python with the help of this
project's success. If you see my protential, please let me in, then I will
try my best to learn and work hard, not making you disappoint.

Finally, thanks again for reading my proposal.


-- 
Sincerely,
Gombiuda Jiang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100401/d9858489/attachment.html>

From warren.weckesser at enthought.com  Wed Mar 31 22:31:50 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 31 Mar 2010 21:31:50 -0500
Subject: [SciPy-Dev] Another patch for review: linalg.solveh_banded
Message-ID: <4BB40596.5060902@enthought.com>

I added a patch to ticket #676: http://projects.scipy.org/scipy/ticket/676

The change to the code is simple, but this looks like an old and musty 
bug, so maybe there is a reason it wasn't fixed a long time ago.  
Reviews would be appreciated.

Warren