From stefan at sun.ac.za  Wed Apr  1 19:19:53 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 2 Apr 2009 01:19:53 +0200
Subject: [SciPy-dev] GSoC Proposals Due on the 3rd
Message-ID: <9457e7c80904011619y68c31426x7a178c268acdb1a3@mail.gmail.com>

Hi all

Students interested in working on NumPy or SciPy for GSoC2009, please
note that the deadline for proposals is the 3rd of April.

http://socghop.appspot.com/document/show/program/google/gsoc2009/userguide#depth_studentapply

Let's keep those applications coming!

Cheers
St?fan


From cournape at gmail.com  Thu Apr  2 00:49:56 2009
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 2 Apr 2009 13:49:56 +0900
Subject: [SciPy-dev] Numpy/Scipy GSOC project(s)
In-Reply-To: <73531abb0903310942h414f42d0m2bc4efd5fed97a06@mail.gmail.com>
References: <73531abb0903300136k3cd1e9e2r23e749b0ec0695e0@mail.gmail.com>
	<49D0952E.2010202@ar.media.kyoto-u.ac.jp>
	<73531abb0903310936r7eaf2a8exaa587b4c129790c1@mail.gmail.com>
	<73531abb0903310942h414f42d0m2bc4efd5fed97a06@mail.gmail.com>
Message-ID: <5b8d13220904012149h9dbead3p7e65f8e26454049f@mail.gmail.com>

Hi Ross,

2009/4/1 ross smith <rjsm at umich.edu>:
> At first I'd be more interested in bug cleaning.? I think it's the best way
> to get comfortable with a new codebase.?? Toward the second half of the
> summer, I'd be more interested in new features.

I am sorry I did not answer earlier - I unfortunately don't have the
time to give you a complete reply ATM, but you should submit your
proposal right now, as the deadline is very soon (I believe you can
improve the proposal after the deadline, after it has been submitted),

cheers,

David


From josef.pktd at gmail.com  Thu Apr  2 10:11:07 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 2 Apr 2009 10:11:07 -0400
Subject: [SciPy-dev] python pow versus np.power
Message-ID: <1cd32cbb0904020711m4c4001c8ya58f09ad44db8873@mail.gmail.com>

In stats distribution, I don't want exceptions to be raised for corner
cases. In many places python builtin pow is used which cannot handle
several cases.
Until now I switched to the use of np.power for each individual case
when there where problems.

Is there any strong reason not to change all occurrences of pow to np.power?
It would provide a more robust implementation, even if there is a
small performance hit.

Josef

examples:
>>> np.power(0.0,-2)
inf
>>> pow(0.,-2)
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    pow(0.,-2)
ZeroDivisionError: 0.0 cannot be raised to a negative power

>>> pow(np.inf,2)
Traceback (most recent call last):
  File "<pyshell#14>", line 1, in <module>
    pow(np.inf,2)
OverflowError: (34, 'Result too large')
>>> np.power(np.inf,2)
inf

>>> np.power(np.nan,2)
nan
>>> pow(np.nan,2)
Traceback (most recent call last):
  File "<pyshell#17>", line 1, in <module>
    pow(np.nan,2)
ValueError: (33, 'Domain error')


From robert.kern at gmail.com  Thu Apr  2 13:29:16 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 2 Apr 2009 12:29:16 -0500
Subject: [SciPy-dev] python pow versus np.power
In-Reply-To: <1cd32cbb0904020711m4c4001c8ya58f09ad44db8873@mail.gmail.com>
References: <1cd32cbb0904020711m4c4001c8ya58f09ad44db8873@mail.gmail.com>
Message-ID: <3d375d730904021029p5e366c2fx67a42537a80775a6@mail.gmail.com>

On Thu, Apr 2, 2009 at 09:11,  <josef.pktd at gmail.com> wrote:
> In stats distribution, I don't want exceptions to be raised for corner
> cases. In many places python builtin pow is used which cannot handle
> several cases.
> Until now I switched to the use of np.power for each individual case
> when there where problems.
>
> Is there any strong reason not to change all occurrences of pow to np.power?
> It would provide a more robust implementation, even if there is a
> small performance hit.

In scipy? Probably not. 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 josef.pktd at gmail.com  Thu Apr  2 14:35:17 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 2 Apr 2009 14:35:17 -0400
Subject: [SciPy-dev] python pow versus np.power
In-Reply-To: <3d375d730904021029p5e366c2fx67a42537a80775a6@mail.gmail.com>
References: <1cd32cbb0904020711m4c4001c8ya58f09ad44db8873@mail.gmail.com>
	<3d375d730904021029p5e366c2fx67a42537a80775a6@mail.gmail.com>
Message-ID: <1cd32cbb0904021135l661a5287u984b677a25c71966@mail.gmail.com>

On Thu, Apr 2, 2009 at 1:29 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Thu, Apr 2, 2009 at 09:11, ?<josef.pktd at gmail.com> wrote:
>> In stats distribution, I don't want exceptions to be raised for corner
>> cases. In many places python builtin pow is used which cannot handle
>> several cases.
>> Until now I switched to the use of np.power for each individual case
>> when there where problems.
>>
>> Is there any strong reason not to change all occurrences of pow to np.power?
>> It would provide a more robust implementation, even if there is a
>> small performance hit.
>
> In scipy? Probably not. Go for it.
>

Thanks, it will be only for stats.distributions

Josef


From chanley at stsci.edu  Thu Apr  2 19:39:50 2009
From: chanley at stsci.edu (Christopher Hanley)
Date: Thu, 02 Apr 2009 19:39:50 -0400
Subject: [SciPy-dev] New Scipy build issue
Message-ID: <49D54CC6.5030909@stsci.edu>

Hi,

Recently when trying to build scipy from svn I get the following build 
error:

creating build/temp.macosx-10.3-i386-2.5
creating build/temp.macosx-10.3-i386-2.5/scipy
creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
compile options: 
'-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch 
i686 -fPIC -O3 -funroll-loops 
-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c 
scipy/fftpack/src/dfftpack/dcosqb.f -o 
build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o" 
failed with exit status 1


I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is 
the gfortran info:

[redcedar:~/dev/scipy] chanley% gfortran -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.2.2/configure --prefix=/sw 
--prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info 
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona 
--with-tune=generic --host=i686-apple-darwin9 --with-gmp=/sw 
--with-libiconv-prefix=/sw --with-system-zlib 
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.2.2

I'm using Python 2.5.1 and the head of the numpy svn trunk.  I haven't 
changed my site.cfg file or updated any libraries on my system.  Any 
ideas what I might need to change?


Thanks,
Chris

-- 
Christopher Hanley
Senior Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338


From robert.kern at gmail.com  Thu Apr  2 19:44:10 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 2 Apr 2009 18:44:10 -0500
Subject: [SciPy-dev] New Scipy build issue
In-Reply-To: <49D54CC6.5030909@stsci.edu>
References: <49D54CC6.5030909@stsci.edu>
Message-ID: <3d375d730904021644x7f3e2b80l35caec1576af7993@mail.gmail.com>

On Thu, Apr 2, 2009 at 18:39, Christopher Hanley <chanley at stsci.edu> wrote:
> Hi,
>
> Recently when trying to build scipy from svn I get the following build
> error:
>
> creating build/temp.macosx-10.3-i386-2.5
> creating build/temp.macosx-10.3-i386-2.5/scipy
> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
> compile options:
> '-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
> gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
> f951: error: unrecognized command line option "-arch"
> f951: error: unrecognized command line option "-arch"
> error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch
> i686 -fPIC -O3 -funroll-loops
> -I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c
> scipy/fftpack/src/dfftpack/dcosqb.f -o
> build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
> failed with exit status 1
>
>
> I'm using gfortran for the build on my Mac OS X 10.5.6 system. ?Here is
> the gfortran info:
>
> [redcedar:~/dev/scipy] chanley% gfortran -v
> Using built-in specs.
> Target: i686-apple-darwin9
> Configured with: ../gcc-4.2.2/configure --prefix=/sw
> --prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info
> --enable-languages=c,c++,fortran,objc,java --with-arch=nocona
> --with-tune=generic --host=i686-apple-darwin9 --with-gmp=/sw
> --with-libiconv-prefix=/sw --with-system-zlib
> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
> Thread model: posix
> gcc version 4.2.2
>
> I'm using Python 2.5.1 and the head of the numpy svn trunk. ?I haven't
> changed my site.cfg file or updated any libraries on my system. ?Any
> ideas what I might need to change?

Is that Fink's gfortran? I recommend *only* using the gfortran binaries here:

  http://r.research.att.com/tools/

-- 
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 chanley at stsci.edu  Thu Apr  2 19:47:05 2009
From: chanley at stsci.edu (Christopher Hanley)
Date: Thu, 02 Apr 2009 19:47:05 -0400
Subject: [SciPy-dev] New Scipy build issue
In-Reply-To: <3d375d730904021644x7f3e2b80l35caec1576af7993@mail.gmail.com>
References: <49D54CC6.5030909@stsci.edu>
	<3d375d730904021644x7f3e2b80l35caec1576af7993@mail.gmail.com>
Message-ID: <49D54E79.4070903@stsci.edu>

Robert Kern wrote:
> On Thu, Apr 2, 2009 at 18:39, Christopher Hanley <chanley at stsci.edu> wrote:
>> Hi,
>>
>> Recently when trying to build scipy from svn I get the following build
>> error:
>>
>> creating build/temp.macosx-10.3-i386-2.5
>> creating build/temp.macosx-10.3-i386-2.5/scipy
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
>> compile options:
>> '-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
>> gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
>> f951: error: unrecognized command line option "-arch"
>> f951: error: unrecognized command line option "-arch"
>> error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch
>> i686 -fPIC -O3 -funroll-loops
>> -I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c
>> scipy/fftpack/src/dfftpack/dcosqb.f -o
>> build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
>> failed with exit status 1
>>
>>
>> I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is
>> the gfortran info:
>>
>> [redcedar:~/dev/scipy] chanley% gfortran -v
>> Using built-in specs.
>> Target: i686-apple-darwin9
>> Configured with: ../gcc-4.2.2/configure --prefix=/sw
>> --prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info
>> --enable-languages=c,c++,fortran,objc,java --with-arch=nocona
>> --with-tune=generic --host=i686-apple-darwin9 --with-gmp=/sw
>> --with-libiconv-prefix=/sw --with-system-zlib
>> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>> Thread model: posix
>> gcc version 4.2.2
>>
>> I'm using Python 2.5.1 and the head of the numpy svn trunk.  I haven't
>> changed my site.cfg file or updated any libraries on my system.  Any
>> ideas what I might need to change?
> 
> Is that Fink's gfortran? I recommend *only* using the gfortran binaries here:
> 
>   http://r.research.att.com/tools/
> 
OK thanks.  That may be the difference.  I haven't had this issue on my 
home machine and I installed gfortran myself there.

I'll give it a shot.  Thank you for your time and help.

Cheers,
Chris


-- 
Christopher Hanley
Senior Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338


From chanley at stsci.edu  Thu Apr  2 20:08:12 2009
From: chanley at stsci.edu (Christopher Hanley)
Date: Thu, 02 Apr 2009 20:08:12 -0400
Subject: [SciPy-dev] New Scipy build issue
In-Reply-To: <3d375d730904021644x7f3e2b80l35caec1576af7993@mail.gmail.com>
References: <49D54CC6.5030909@stsci.edu>
	<3d375d730904021644x7f3e2b80l35caec1576af7993@mail.gmail.com>
Message-ID: <49D5536C.9040700@stsci.edu>

Robert Kern wrote:
> On Thu, Apr 2, 2009 at 18:39, Christopher Hanley <chanley at stsci.edu> wrote:
>> Hi,
>>
>> Recently when trying to build scipy from svn I get the following build
>> error:
>>
>> creating build/temp.macosx-10.3-i386-2.5
>> creating build/temp.macosx-10.3-i386-2.5/scipy
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
>> compile options:
>> '-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
>> gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
>> f951: error: unrecognized command line option "-arch"
>> f951: error: unrecognized command line option "-arch"
>> error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch
>> i686 -fPIC -O3 -funroll-loops
>> -I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c
>> scipy/fftpack/src/dfftpack/dcosqb.f -o
>> build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
>> failed with exit status 1
>>
>>
>> I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is
>> the gfortran info:
>>
>> [redcedar:~/dev/scipy] chanley% gfortran -v
>> Using built-in specs.
>> Target: i686-apple-darwin9
>> Configured with: ../gcc-4.2.2/configure --prefix=/sw
>> --prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info
>> --enable-languages=c,c++,fortran,objc,java --with-arch=nocona
>> --with-tune=generic --host=i686-apple-darwin9 --with-gmp=/sw
>> --with-libiconv-prefix=/sw --with-system-zlib
>> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>> Thread model: posix
>> gcc version 4.2.2
>>
>> I'm using Python 2.5.1 and the head of the numpy svn trunk.  I haven't
>> changed my site.cfg file or updated any libraries on my system.  Any
>> ideas what I might need to change?
> 
> Is that Fink's gfortran? I recommend *only* using the gfortran binaries here:
> 
>   http://r.research.att.com/tools/
> 

That worked.  You rock as usual.

Thanks,
Chris


-- 
Christopher Hanley
Senior Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338


From mirteney at gmail.com  Fri Apr  3 06:28:09 2009
From: mirteney at gmail.com (Anton Litvinov)
Date: Fri, 3 Apr 2009 16:28:09 +0600
Subject: [SciPy-dev] possible GSoC proposal
Message-ID: <ad5d092c0904030328u7b28df8dvf0d1e8e808beb4c6@mail.gmail.com>

Hello

While using SciPy I thought that it would be good to have the family of
Runge-Kutta methods out of the box.
This problem is of my interest and I have a desire to make this idea come
true.


--
Best regards,
 Anton Litvinov
 Yugra State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090403/472e1607/attachment.html>

From stefan at sun.ac.za  Fri Apr  3 10:16:56 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 3 Apr 2009 16:16:56 +0200
Subject: [SciPy-dev] possible GSoC proposal
In-Reply-To: <ad5d092c0904030328u7b28df8dvf0d1e8e808beb4c6@mail.gmail.com>
References: <ad5d092c0904030328u7b28df8dvf0d1e8e808beb4c6@mail.gmail.com>
Message-ID: <9457e7c80904030716x5c546822mfda97523807b208c@mail.gmail.com>

Hi Anton

2009/4/3 Anton Litvinov <mirteney at gmail.com>:
> While using SciPy I thought that it would be good to have the family of
> Runge-Kutta methods out of the box.
> This problem is of my interest and I have a desire to make this idea come
> true.

By all means, submit a proposal.  I suggest getting in contact with
Rob Clewley to finalise the details.

Please note that the deadline is in a couple of hours!

Regards
St?fan


From ondrej at certik.cz  Sun Apr  5 17:45:42 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Sun, 5 Apr 2009 14:45:42 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
Message-ID: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>

Hi,

the mission of scipy from scipy.org:

"
SciPy is open-source software for mathematics, science, and
engineering. [...] The SciPy library [...] provides many user-friendly
and efficient numerical routines such as routines for numerical
integration and optimization.
"

it has solvers for ODEs using several methods. Is having a finite
element (FEM) solvers for PDEs (and some ODEs too) among the scipy's
goals?

My group[0] would be very interested in that.

Of course, this is not something, that can happen overnight. But scipy
has interface to lot's of sparse solvers, so it might have some nice
pythonic interface to finite element solvers for PDEs too.

If you look at the topical software, PDE section:

http://scipy.org/Topical_Software#head-3df99e31c89f2e8ff60a2622805f6a304c50101f

there are currently 3 solvers listed, FiPy (finite volumes), SfePy
(regular finite elements, Robert Cimrman, some patches from me and
other people), Hermes (higher order adaptive finite elements,
developed at the University of Nevada/Reno[0], where I am now). There
are more good opensource FEM libraries out there, some list is here:

http://hpfem.org/femcodes.html

the most widely used is probably libmesh, though it's GPL and as far
as I know it doesn't yet have python wrappers (I wrote some swig
wrappers couple years back, but it was bad --- it's on my todo list to
write good wrappers in Cython for libmesh).

All FEM codes need a common functionality --- you need to load a mesh
(e.g. readers and writers for all the different mesh formats out
there, commercial or not), you need to define your PDE, then you need
to assemble the global matrices (this is the, where all the FEM codes
differ, e.g. you can have lots of different bases, etc. etc.), then
depending on your problem, in most cases you end up either with linear
system of equations:

A * x = b

or (eigenproblem):

A * x = lambda * B * x

where A, B are (sparse) matrices, "x" is the solution, "b" is the
right hand side (vector), lambda is the eigenvalue. So the goal of the
FE solver is to calculate A, B and "b". It should be general enough to
allow you to discretize any integral in the weak formulation of the
PDE, but in most cases, A, B or "b" is all you want.

Then I solve it using solvers that are in scipy, or pysparse, or
petsc4py, or slepc4py.

Next one has to take "x" and feed it to the finite element solver
again and then tell it to automatically adapt the mesh (there are
several approaches for this, you can use some not so good error
estimators, like some gradients of the solution, or you can use
sophisticated errror estimators, like a reference solution, calculated
on a uniformly refined mesh etc.). So you iteratively adapt, until you
are satisfied.

Most problems are nonlinear, so one also has to use some nonlinear
solvers, e.g. I wrote some Jacobian free nonlinear solvers in
scipy.optimize.nonlin, but this has to be polished and improved (and
also if your problem is simple enough to allow it, you can also
construct the Jacobian using FEM directly, that's the best thing).

Once you have the solution, you also need to save it to many different
file formats for visualization, and/or provide hooks to mayavi or
matplotlib (for 2D stuff).

And besides all of this, one also needs to have a common functionality
like doing arithmetics with the solution (e.g. sum/substract two
solutions, integrate it, etc.) , project it to different meshes, etc.
etc.



So do you think scipy could have some default, adaptive FEM solver,
that would do the job for any PDE, and then all the common
functionality above, so that one can easily hook in there any other
solver, just to construct the A, B, "b" matrices/vectors and then use
scipy for the rest (and optionally the solver again for the
adaptivity)?


This is a question where you want scipy to go in the longer term. But
I think a good mission statement is to provide a viable alternative to
Matlab. And for that, a good PDE solver and related tools are
necessary. And if scipy had all the common functionality above, so
that one can easily hook up any FEM solver in there, plus there would
be some default solver in scipy itself, imho that would rock.

In my group[0] (we also collaborate with Robert Cimrman) we are doing
all of the above and our goal is to have such a system anyway. But it
occurred to us that if this could be part of scipy, it could be a win
to everybody, since I could spend more time working on scipy and all
scipy users would have a good FEM solver. Plus I would then have
imminent interest to release soon, release often, which imho is not
bad for scipy either.

As to techinical side, the 2D solver is written in C++ and builds in
about 3s on 8 processors, and the python wrappers use Cython. The 3D
solver takes a bit longer to build I think 17s. So it would make the
scipy build a bit longer, but imho scipy should be able to solve PDEs.

Together with a project like SPD:

http://code.google.com/p/spdproject/

which easily builds scipy, numpy, atlas, blas, ..... on all platforms
from source easily, then imho we could have a viable alternative to
matlab.

Ondrej

P.S. Currently our FE solvers is GPL, but I think that could change to
BSD if there is enough interest in that (there is in me). SPD also has
to be GPL, because it's based on Sage, but if there is enough
interest, I guess it's not difficult to rewrite all the buildscripts
from scratch and use BSD (I myself don't mind using GPL for SPD and
save myself lots of time by taking advantage of Sage).

[0] http://hpfem.math.unr.edu/


From benny.malengier at gmail.com  Mon Apr  6 05:16:36 2009
From: benny.malengier at gmail.com (Benny Malengier)
Date: Mon, 6 Apr 2009 11:16:36 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
Message-ID: <bcafe8290904060216x2a4e8ddcyf539d844ab76340e@mail.gmail.com>

As a user, I would very much like to see scipy include some FEM base.
As you say, a generic framework would allow others to just write a different
core, support other mesh formats, ..., eg they could be done as scikits.
The fragmentation now is large.

I am using freefem++ (http://www.freefem.org/ ) recently for quick reference
solutions in 2D. Would you plan such a high level parsing of weak forms?

Anyway, the question is always to use C/C++ directly or python to do the
job. Personally I am leaning to using DUNE http://www.dune-project.org for
my next project as it is very versatile. I know they where playing with a
python interface too, but I find nothing on their site now about this.

Benny

2009/4/5 Ondrej Certik <ondrej at certik.cz>

> Hi,
>
> the mission of scipy from scipy.org:
>
> "
> SciPy is open-source software for mathematics, science, and
> engineering. [...] The SciPy library [...] provides many user-friendly
> and efficient numerical routines such as routines for numerical
> integration and optimization.
> "
>
> it has solvers for ODEs using several methods. Is having a finite
> element (FEM) solvers for PDEs (and some ODEs too) among the scipy's
> goals?
>
> My group[0] would be very interested in that.
>
> Of course, this is not something, that can happen overnight. But scipy
> has interface to lot's of sparse solvers, so it might have some nice
> pythonic interface to finite element solvers for PDEs too.
>
> If you look at the topical software, PDE section:
>
>
> http://scipy.org/Topical_Software#head-3df99e31c89f2e8ff60a2622805f6a304c50101f
>
> there are currently 3 solvers listed, FiPy (finite volumes), SfePy
> (regular finite elements, Robert Cimrman, some patches from me and
> other people), Hermes (higher order adaptive finite elements,
> developed at the University of Nevada/Reno[0], where I am now). There
> are more good opensource FEM libraries out there, some list is here:
>
> http://hpfem.org/femcodes.html
>
> the most widely used is probably libmesh, though it's GPL and as far
> as I know it doesn't yet have python wrappers (I wrote some swig
> wrappers couple years back, but it was bad --- it's on my todo list to
> write good wrappers in Cython for libmesh).
>
> All FEM codes need a common functionality --- you need to load a mesh
> (e.g. readers and writers for all the different mesh formats out
> there, commercial or not), you need to define your PDE, then you need
> to assemble the global matrices (this is the, where all the FEM codes
> differ, e.g. you can have lots of different bases, etc. etc.), then
> depending on your problem, in most cases you end up either with linear
> system of equations:
>
> A * x = b
>
> or (eigenproblem):
>
> A * x = lambda * B * x
>
> where A, B are (sparse) matrices, "x" is the solution, "b" is the
> right hand side (vector), lambda is the eigenvalue. So the goal of the
> FE solver is to calculate A, B and "b". It should be general enough to
> allow you to discretize any integral in the weak formulation of the
> PDE, but in most cases, A, B or "b" is all you want.
>
> Then I solve it using solvers that are in scipy, or pysparse, or
> petsc4py, or slepc4py.
>
> Next one has to take "x" and feed it to the finite element solver
> again and then tell it to automatically adapt the mesh (there are
> several approaches for this, you can use some not so good error
> estimators, like some gradients of the solution, or you can use
> sophisticated errror estimators, like a reference solution, calculated
> on a uniformly refined mesh etc.). So you iteratively adapt, until you
> are satisfied.
>
> Most problems are nonlinear, so one also has to use some nonlinear
> solvers, e.g. I wrote some Jacobian free nonlinear solvers in
> scipy.optimize.nonlin, but this has to be polished and improved (and
> also if your problem is simple enough to allow it, you can also
> construct the Jacobian using FEM directly, that's the best thing).
>
> Once you have the solution, you also need to save it to many different
> file formats for visualization, and/or provide hooks to mayavi or
> matplotlib (for 2D stuff).
>
> And besides all of this, one also needs to have a common functionality
> like doing arithmetics with the solution (e.g. sum/substract two
> solutions, integrate it, etc.) , project it to different meshes, etc.
> etc.
>
>
>
> So do you think scipy could have some default, adaptive FEM solver,
> that would do the job for any PDE, and then all the common
> functionality above, so that one can easily hook in there any other
> solver, just to construct the A, B, "b" matrices/vectors and then use
> scipy for the rest (and optionally the solver again for the
> adaptivity)?
>
>
> This is a question where you want scipy to go in the longer term. But
> I think a good mission statement is to provide a viable alternative to
> Matlab. And for that, a good PDE solver and related tools are
> necessary. And if scipy had all the common functionality above, so
> that one can easily hook up any FEM solver in there, plus there would
> be some default solver in scipy itself, imho that would rock.
>
> In my group[0] (we also collaborate with Robert Cimrman) we are doing
> all of the above and our goal is to have such a system anyway. But it
> occurred to us that if this could be part of scipy, it could be a win
> to everybody, since I could spend more time working on scipy and all
> scipy users would have a good FEM solver. Plus I would then have
> imminent interest to release soon, release often, which imho is not
> bad for scipy either.
>
> As to techinical side, the 2D solver is written in C++ and builds in
> about 3s on 8 processors, and the python wrappers use Cython. The 3D
> solver takes a bit longer to build I think 17s. So it would make the
> scipy build a bit longer, but imho scipy should be able to solve PDEs.
>
> Together with a project like SPD:
>
> http://code.google.com/p/spdproject/
>
> which easily builds scipy, numpy, atlas, blas, ..... on all platforms
> from source easily, then imho we could have a viable alternative to
> matlab.
>
> Ondrej
>
> P.S. Currently our FE solvers is GPL, but I think that could change to
> BSD if there is enough interest in that (there is in me). SPD also has
> to be GPL, because it's based on Sage, but if there is enough
> interest, I guess it's not difficult to rewrite all the buildscripts
> from scratch and use BSD (I myself don't mind using GPL for SPD and
> save myself lots of time by taking advantage of Sage).
>
> [0] http://hpfem.math.unr.edu/
> _______________________________________________
> 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/20090406/2208a781/attachment.html>

From prabhu at aero.iitb.ac.in  Mon Apr  6 05:23:05 2009
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Mon, 06 Apr 2009 14:53:05 +0530
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
Message-ID: <49D9C9F9.6010109@aero.iitb.ac.in>

On 04/06/09 03:15, Ondrej Certik wrote:
> the mission of scipy from scipy.org:
> 
> "
> SciPy is open-source software for mathematics, science, and
> engineering. [...] The SciPy library [...] provides many user-friendly
> and efficient numerical routines such as routines for numerical
> integration and optimization.
> "
> 
> it has solvers for ODEs using several methods. Is having a finite
> element (FEM) solvers for PDEs (and some ODEs too) among the scipy's
> goals?

I do not think this would fit in with the purposes of scipy the library, 
  for the next obvious question would be what about grid generators? 
What about finite difference and finite volume solvers and so on.  I 
think these are a little too specialized to go into scipy proper.  There 
are a plethora of approaches, techniques, algorithms and a host of 
problems with each.

A scikit would be good as would a separate family of tools under the 
scipy umbrella.  It would be great to have a scipy-pde package but what 
does this have to do with scipy itself?  Do we have a larger 
super-package that hopes to provide different bundles, kind of like sage 
but more targeted to numerical computing?

> Together with a project like SPD:
> 
> http://code.google.com/p/spdproject/

Perhaps this is really the answer.  A specialized set of sub-packages or 
bundles with SPD for different tasks.

cheers,
prabhu


From daniel.wheeler2 at gmail.com  Mon Apr  6 11:58:45 2009
From: daniel.wheeler2 at gmail.com (Daniel Wheeler)
Date: Mon, 6 Apr 2009 11:58:45 -0400
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49D9C9F9.6010109@aero.iitb.ac.in>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
Message-ID: <80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>

On Mon, Apr 6, 2009 at 5:23 AM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:

> I do not think this would fit in with the purposes of scipy the library,
>  for the next obvious question would be what about grid generators?
> What about finite difference and finite volume solvers and so on.  I
> think these are a little too specialized to go into scipy proper.  There
> are a plethora of approaches, techniques, algorithms and a host of
> problems with each.

Totally agree. Scipy should be low level, FE tools etc should be using
scipy/numpy not integrated into scipy.

One weakness right now is that there doesn't seem to be a good open
source python based meshing tool. Again, this is not something that
should necessarily be in scipy, but something that should probably
leverage from scipy. We (FiPY) currently use gmsh, but it is not
tightly integrated and and we've written our own standard mesh
classes, but haven't done anything more with this.

-- 
Daniel Wheeler


From cohen at lpta.in2p3.fr  Mon Apr  6 14:56:33 2009
From: cohen at lpta.in2p3.fr (Cohen-Tanugi Johann)
Date: Mon, 06 Apr 2009 20:56:33 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
Message-ID: <49DA5061.9060002@lpta.in2p3.fr>

Sorry to jump on this (interesting) discussion with a relevant question 
but aside from Ondrej initial question : is there somewhere a scipy 
mission statement clearly spelled out?

best,
Johann

Daniel Wheeler wrote:
> On Mon, Apr 6, 2009 at 5:23 AM, Prabhu Ramachandran
> <prabhu at aero.iitb.ac.in> wrote:
>
>   
>> I do not think this would fit in with the purposes of scipy the library,
>>  for the next obvious question would be what about grid generators?
>> What about finite difference and finite volume solvers and so on.  I
>> think these are a little too specialized to go into scipy proper.  There
>> are a plethora of approaches, techniques, algorithms and a host of
>> problems with each.
>>     
>
> Totally agree. Scipy should be low level, FE tools etc should be using
> scipy/numpy not integrated into scipy.
>
> One weakness right now is that there doesn't seem to be a good open
> source python based meshing tool. Again, this is not something that
> should necessarily be in scipy, but something that should probably
> leverage from scipy. We (FiPY) currently use gmsh, but it is not
> tightly integrated and and we've written our own standard mesh
> classes, but haven't done anything more with this.
>
>   


From nwagner at iam.uni-stuttgart.de  Mon Apr  6 15:10:55 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 06 Apr 2009 21:10:55 +0200
Subject: [SciPy-dev] make all-pdf in scipy/doc
Message-ID: <web-118784889@uni-stuttgart.de>

Hi all,

I tried to build the pdf version of scipy-ref.
I am using sphinx0.6.1.
However I cannot find scipy-ref.pdf in build/latex

Any idea ?

  Nils

make all-pdf
pdflatex -interaction batchmode  'scipy-ref.tex'
This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
entering extended mode
make: [scipy-ref.pdf] Fehler 1 (ignoriert)
pdflatex -interaction batchmode  'scipy-ref.tex'
This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
entering extended mode
make: [scipy-ref.pdf] Fehler 1 (ignoriert)
pdflatex -interaction batchmode  'scipy-ref.tex'
This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
entering extended mode
make: [scipy-ref.pdf] Fehler 1 (ignoriert)
makeindex -s python.ist 'scipy-ref.idx'
This is makeindex, version 2.14 [02-Oct-2002] (kpathsea + 
Thai support).
Scanning style file ./python.ist......done (6 attributes 
redefined, 0 ignored).
Scanning input file scipy-ref.idx....done (273 entries 
accepted, 0 rejected).
Sorting entries.....done (2401 comparisons).
Generating output file scipy-ref.ind....done (346 lines 
written, 0 warnings).
Output written in scipy-ref.ind.
Transcript written in scipy-ref.ilg.
makeindex -s python.ist 'modscipy-ref.idx'
Input index file modscipy-ref.idx not found.
Usage: makeindex [-ilqrcgLT] [-s sty] [-o ind] [-t log] 
[-p num] [idx0 idx1 ...]
make: [scipy-ref.pdf] Fehler 1 (ignoriert)
pdflatex -interaction batchmode  'scipy-ref.tex'
This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
entering extended mode
make: [scipy-ref.pdf] Fehler 1 (ignoriert)
pdflatex -interaction batchmode  'scipy-ref.tex'
This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
entering extended mode
make: [scipy-ref.pdf] Fehler 1 (ignoriert)
  


From pgmdevlist at gmail.com  Wed Apr  8 02:52:59 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 8 Apr 2009 02:52:59 -0400
Subject: [SciPy-dev] integrate.dop w/ setupscons and r5642
Message-ID: <546FBCF3-0B45-48A3-AC09-AE87D55D04D6@gmail.com>

All,
I just tried to compile scipy using setupscons.py on a virtual  
environment in MacOSX (10.5.6, gcc 4.2). Works quite OK, except for  a  
surprise:
the content of the scipy/integrate directory in the site-package is  
such:
__init__.py             info.py                  
libodepack.a            odepack.py               
quadrature.py           setupscons.py
__init__.pyc            info.pyc                 
libquadpack.a           odepack.pyc              
quadrature.pyc          setupscons.pyc
_odepack.so             liblinpack_lite.a        
ode.py                  quadpack.py              
setup.py                tests
_quadpack.so            libmach.a                
ode.pyc                 quadpack.pyc             
setup.pyc               vode.so

When compiled w/ the standard setup.py in an another virtual  
environment, it is such:
__init__.py     _odepack.so     dop.so          info.pyc         
ode.pyc         odepack.pyc     quadpack.pyc    quadrature.pyc   
setup.pyc       setupscons.pyc  vode.so
__init__.pyc    _quadpack.so    info.py         ode.py           
odepack.py      quadpack.py     quadrature.py   setup.py         
setupscons.py   tests

Looks like some static libraries are not grouped into dop.so when  
compiling w/ setupscons, which causes problems down the road  
(integrate.dop can't be imported).

Does anybody observe that, or is it just me being tired and having  
missed something ?

Thx a lot in advance for any comment,
P.


From david at ar.media.kyoto-u.ac.jp  Wed Apr  8 04:56:58 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 08 Apr 2009 17:56:58 +0900
Subject: [SciPy-dev] integrate.dop w/ setupscons and r5642
In-Reply-To: <546FBCF3-0B45-48A3-AC09-AE87D55D04D6@gmail.com>
References: <546FBCF3-0B45-48A3-AC09-AE87D55D04D6@gmail.com>
Message-ID: <49DC66DA.7060405@ar.media.kyoto-u.ac.jp>

Pierre GM wrote:
> All,
> I just tried to compile scipy using setupscons.py on a virtual  
> environment in MacOSX (10.5.6, gcc 4.2). Works quite OK, except for  a  
> surprise:
> the content of the scipy/integrate directory in the site-package is  
> such:
>   

Should be fixed in trunk,

David


From pgmdevlist at gmail.com  Wed Apr  8 10:40:00 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 8 Apr 2009 10:40:00 -0400
Subject: [SciPy-dev] integrate.dop w/ setupscons and r5642
In-Reply-To: <49DC66DA.7060405@ar.media.kyoto-u.ac.jp>
References: <546FBCF3-0B45-48A3-AC09-AE87D55D04D6@gmail.com>
	<49DC66DA.7060405@ar.media.kyoto-u.ac.jp>
Message-ID: <6258ABD7-874A-49DD-AD56-0B9D3B47D13B@gmail.com>


On Apr 8, 2009, at 4:56 AM, David Cournapeau wrote:

> Pierre GM wrote:
>> All,
>> I just tried to compile scipy using setupscons.py on a virtual
>> environment in MacOSX (10.5.6, gcc 4.2). Works quite OK, except  
>> for  a
>> surprise:
>> the content of the scipy/integrate directory in the site-package is
>> such:
>>
>
> Should be fixed in trunk,

now I get an unresolved
Symbol not found: _dop853_
Any pointer welcome.
Thx in advance
P.


From david at ar.media.kyoto-u.ac.jp  Wed Apr  8 10:58:05 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 08 Apr 2009 23:58:05 +0900
Subject: [SciPy-dev] integrate.dop w/ setupscons and r5642
In-Reply-To: <6258ABD7-874A-49DD-AD56-0B9D3B47D13B@gmail.com>
References: <546FBCF3-0B45-48A3-AC09-AE87D55D04D6@gmail.com>	<49DC66DA.7060405@ar.media.kyoto-u.ac.jp>
	<6258ABD7-874A-49DD-AD56-0B9D3B47D13B@gmail.com>
Message-ID: <49DCBB7D.3070207@ar.media.kyoto-u.ac.jp>

Pierre GM wrote:
>
> now I get an unresolved
> Symbol not found: _dop853_
>   

This will teach me to commit things without testing. This time, the
scipy testsuite passes after later changes,

David


From pav at iki.fi  Wed Apr  8 14:30:34 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 8 Apr 2009 18:30:34 +0000 (UTC)
Subject: [SciPy-dev] make all-pdf in scipy/doc
References: <web-118784889@uni-stuttgart.de>
Message-ID: <griqga$est$1@ger.gmane.org>

Mon, 06 Apr 2009 21:10:55 +0200, Nils Wagner wrote:
> I tried to build the pdf version of scipy-ref. I am using sphinx0.6.1.
> However I cannot find scipy-ref.pdf in build/latex
> 
> Any idea ?

Fixed in trunk, I believe.

-- 
Pauli Virtanen



From nwagner at iam.uni-stuttgart.de  Wed Apr  8 15:26:20 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 08 Apr 2009 21:26:20 +0200
Subject: [SciPy-dev] make all-pdf in scipy/doc
In-Reply-To: <griqga$est$1@ger.gmane.org>
References: <web-118784889@uni-stuttgart.de>
 <griqga$est$1@ger.gmane.org>
Message-ID: <web-118879855@uni-stuttgart.de>

On Wed, 8 Apr 2009 18:30:34 +0000 (UTC)
  Pauli Virtanen <pav at iki.fi> wrote:
> Mon, 06 Apr 2009 21:10:55 +0200, Nils Wagner wrote:
>> I tried to build the pdf version of scipy-ref. I am 
>>using sphinx0.6.1.
>> However I cannot find scipy-ref.pdf in build/latex
>> 
>> Any idea ?
> 
>Fixed in trunk, I believe.


Thank you. Works for me.

Cheers
            Nils
   


From pgmdevlist at gmail.com  Wed Apr  8 15:42:06 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 8 Apr 2009 15:42:06 -0400
Subject: [SciPy-dev] integrate.dop w/ setupscons and r5642
In-Reply-To: <49DCBB7D.3070207@ar.media.kyoto-u.ac.jp>
References: <546FBCF3-0B45-48A3-AC09-AE87D55D04D6@gmail.com>	<49DC66DA.7060405@ar.media.kyoto-u.ac.jp>
	<6258ABD7-874A-49DD-AD56-0B9D3B47D13B@gmail.com>
	<49DCBB7D.3070207@ar.media.kyoto-u.ac.jp>
Message-ID: <B4C5CC0B-56DB-4883-AC0C-CE3C8BA51329@gmail.com>

David,
Thanks a million, works like a charm.
A+
P.


On Apr 8, 2009, at 10:58 AM, David Cournapeau wrote:

> Pierre GM wrote:
>>
>> now I get an unresolved
>> Symbol not found: _dop853_
>>
>
> This will teach me to commit things without testing. This time, the
> scipy testsuite passes after later changes,
>


From rjsm at umich.edu  Wed Apr  8 17:33:21 2009
From: rjsm at umich.edu (ross smith)
Date: Wed, 8 Apr 2009 17:33:21 -0400
Subject: [SciPy-dev] Numpy/Scipy GSOC project(s)
In-Reply-To: <5b8d13220904012149h9dbead3p7e65f8e26454049f@mail.gmail.com>
References: <73531abb0903300136k3cd1e9e2r23e749b0ec0695e0@mail.gmail.com>
	<49D0952E.2010202@ar.media.kyoto-u.ac.jp>
	<73531abb0903310936r7eaf2a8exaa587b4c129790c1@mail.gmail.com>
	<73531abb0903310942h414f42d0m2bc4efd5fed97a06@mail.gmail.com>
	<5b8d13220904012149h9dbead3p7e65f8e26454049f@mail.gmail.com>
Message-ID: <73531abb0904081433l7295e181g9de0a350e64e7e5d@mail.gmail.com>

I've had a run of bad luck (burglary) and haven't been able to reply for any
updates.

I did submit a draft proposal for this project on time but it needs some
work.  One coment from Josef was that sgnal.lti, would need some help with
documentation and testing along with extending it for MIMO, with the caveat
that this might be too much for a gsoc project. [1]  any other opinions on
if this would be too tough?

are there any other areas of SciPy.signal that are in need of work?

-Ross

On Thu, Apr 2, 2009 at 00:49, David Cournapeau <cournape at gmail.com> wrote:

> Hi Ross,
>
> 2009/4/1 ross smith <rjsm at umich.edu>:
> > At first I'd be more interested in bug cleaning.  I think it's the best
> way
> > to get comfortable with a new codebase.   Toward the second half of the
> > summer, I'd be more interested in new features.
>
> I am sorry I did not answer earlier - I unfortunately don't have the
> time to give you a complete reply ATM, but you should submit your
> proposal right now, as the deadline is very soon (I believe you can
> improve the proposal after the deadline, after it has been submitted),
>
> cheers,
>
> David
> _______________________________________________
> 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/20090408/db3195ac/attachment.html>

From ondrej at certik.cz  Wed Apr  8 18:43:30 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 8 Apr 2009 15:43:30 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49DA5061.9060002@lpta.in2p3.fr>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
Message-ID: <85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>

On Mon, Apr 6, 2009 at 11:56 AM, Cohen-Tanugi Johann
<cohen at lpta.in2p3.fr> wrote:
> Sorry to jump on this (interesting) discussion with a relevant question
> but aside from Ondrej initial question : is there somewhere a scipy
> mission statement clearly spelled out?

I would like to know this too. Seems like people differ in the
interpretation of the mission.

Let me reply to the points above:

On Mon, Apr 6, 2009 at 2:16 AM, Benny Malengier
<benny.malengier at gmail.com> wrote:
> As a user, I would very much like to see scipy include some FEM base.
> As you say, a generic framework would allow others to just write a different
> core, support other mesh formats, ..., eg they could be done as scikits.
> The fragmentation now is large.

Exactly.

>
> I am using freefem++ (http://www.freefem.org/ ) recently for quick reference
> solutions in 2D. Would you plan such a high level parsing of weak forms?

Yes, we do --- we just want to use Python+Cython to enter the forms.



On Mon, Apr 6, 2009 at 2:23 AM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> On 04/06/09 03:15, Ondrej Certik wrote:
>> the mission of scipy from scipy.org:
>>
>> "
>> SciPy is open-source software for mathematics, science, and
>> engineering. [...] The SciPy library [...] provides many user-friendly
>> and efficient numerical routines such as routines for numerical
>> integration and optimization.
>> "
>>
>> it has solvers for ODEs using several methods. Is having a finite
>> element (FEM) solvers for PDEs (and some ODEs too) among the scipy's
>> goals?
>
> I do not think this would fit in with the purposes of scipy the library,
>  for the next obvious question would be what about grid generators?
> What about finite difference and finite volume solvers and so on.  I
> think these are a little too specialized to go into scipy proper.  There
> are a plethora of approaches, techniques, algorithms and a host of
> problems with each.

There could be one good enough default mesh generator in scipy. As to
FDM -- imho FEM is much more versatile and general. As to FVM, imho
many aspects of FVM could be handled by such an interface as well.

Besides, I propose to add adaptive FEM, so the mesh generator is only
really needed to define the geometry, which in lots of cases can be
done even by hand, as the solver takes care of the rest.

>
> A scikit would be good as would a separate family of tools under the
> scipy umbrella.  It would be great to have a scipy-pde package but what
> does this have to do with scipy itself?  Do we have a larger

So what exactly is "scipy itself"? I thought it could be all numerical
things, that are in matlab.

They have it as a toolbox:

http://www.mathworks.com/products/pde/

so I guess scipy should be like a bare matlab and all toolboxes should
go to scikits?

> super-package that hopes to provide different bundles, kind of like sage
> but more targeted to numerical computing?

What do you mean by "we have a larger superpackage"? Are you asking if
we want to have such a package, or if we want scipy to become such a
package?

>
>> Together with a project like SPD:
>>
>> http://code.google.com/p/spdproject/
>
> Perhaps this is really the answer.  A specialized set of sub-packages or
> bundles with SPD for different tasks.

Yes, that's what we'll do most probably.



On Mon, Apr 6, 2009 at 8:58 AM, Daniel Wheeler
<daniel.wheeler2 at gmail.com> wrote:
> On Mon, Apr 6, 2009 at 5:23 AM, Prabhu Ramachandran
> <prabhu at aero.iitb.ac.in> wrote:
>
>> I do not think this would fit in with the purposes of scipy the library,
>>  for the next obvious question would be what about grid generators?
>> What about finite difference and finite volume solvers and so on.  I
>> think these are a little too specialized to go into scipy proper.  There
>> are a plethora of approaches, techniques, algorithms and a host of
>> problems with each.
>
> Totally agree. Scipy should be low level, FE tools etc should be using
> scipy/numpy not integrated into scipy.
>
> One weakness right now is that there doesn't seem to be a good open
> source python based meshing tool. Again, this is not something that
> should necessarily be in scipy, but something that should probably
> leverage from scipy. We (FiPY) currently use gmsh, but it is not
> tightly integrated and and we've written our own standard mesh
> classes, but haven't done anything more with this.

I like the FiPy project, when I get more time, I'd like to create some
unified interface, so that one can take one equation and solve it with
both FiPy and our FEM code (or libmesh), so that one can compare all
those solvers and see which one performs the best.

Can FiPy do adaptive mesh refinement? I was trying to find it in the
manual, but it seems you always need to create the mesh beforehand?
Then you calculate on it, you get something. How do you know if it's
precise enough and if you should refine the mesh? How do you determine
where you should refine it and how much?

If our FEM solver creates a nice hp mesh automatically, imho you
cannot beat it by any hand made mesh, so then any comparison with a
hand made mesh would be unfair to fipy.

Ondrej


From stefan at sun.ac.za  Wed Apr  8 19:00:15 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 9 Apr 2009 01:00:15 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
Message-ID: <9457e7c80904081600x286954f3t1fff260a65b3c6d0@mail.gmail.com>

2009/4/9 Ondrej Certik <ondrej at certik.cz>:
> I would like to know this too. Seems like people differ in the
> interpretation of the mission.

I wouldn't presume to know the full answer to this question, but I
think the intention is clear: SciPy should be a library that is useful
across different scientific disciplines.  Unfortunately, drawing that
line isn't a highly scientific process.

For example, personally I can see how a mesh generator could fit
nicely into scipy.spatial, whereas FEM in itself seems too specialised
(unless it is implemented in a very generic framework).  My opinion
differs from others given so far, emphasising the blurriness of the
line.

Prabhu's suggestion to write a SciKit strikes me as a good one.  In
any case, it is the best way to get new code into SciPy.

Regards
St?fan


From robert.kern at gmail.com  Wed Apr  8 19:04:52 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 8 Apr 2009 18:04:52 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
Message-ID: <3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>

On Wed, Apr 8, 2009 at 17:43, Ondrej Certik <ondrej at certik.cz> wrote:

> On Mon, Apr 6, 2009 at 2:23 AM, Prabhu Ramachandran
> <prabhu at aero.iitb.ac.in> wrote:

>> A scikit would be good as would a separate family of tools under the
>> scipy umbrella. ?It would be great to have a scipy-pde package but what
>> does this have to do with scipy itself? ?Do we have a larger
>
> So what exactly is "scipy itself"?

People usually mean the scipy Python package when they use this term.

> I thought it could be all numerical
> things, that are in matlab.
>
> They have it as a toolbox:
>
> http://www.mathworks.com/products/pde/
>
> so I guess scipy should be like a bare matlab and all toolboxes should
> go to scikits?

Not necessarily *bare* Matlab, but that's roughly my take. Personally,
I don't feel a need to put everything numerical possible into scipy
itself. That way lies madness, IMO. A single Python package just isn't
the right technology to contain that much code.

I see scipy as primarily providing the fundamentals. In addition, it
also serves as a home for numerical code that would otherwise have no
home. I see no benefit in pulling in existing projects that are
thriving on their own. As for PDEs, specifically, I think the domain
is rich enough that it can usefully live in its own package better
than being put into scipy. While there may be some fundamentals that
you can pull out that might make sense to live in scipy (some simple
good-enough mesh generation as you suggest), you will inevitably need
more options, more sophisticated mesh generation, more dependencies,
etc., that fits the development life cycle of a PDE-dedicated package
more than scipy.

In other words, the important question isn't, "Can scipy do this?" but
rather, "Can Python do this?".

>> super-package that hopes to provide different bundles, kind of like sage
>> but more targeted to numerical computing?
>
> What do you mean by "we have a larger superpackage"? Are you asking if
> we want to have such a package, or if we want scipy to become such a
> package?

I don't think he's talking about a Python package, but rather a
project that bundles Python packages together, like the SAGE
distribution (which is much more than the sage Python package),
Python(X,Y) and EPD. scipy is a Python package and can't really morph
into a superpackage. It simply belongs to a different category of
things. In fact, I suggest not using the term "superpackage" but
"distribution".

-- 
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 prabhu at aero.iitb.ac.in  Thu Apr  9 07:18:04 2009
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Thu, 09 Apr 2009 16:48:04 +0530
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
Message-ID: <49DDD96C.50106@aero.iitb.ac.in>

On 04/09/09 04:34, Robert Kern wrote:
> I see scipy as primarily providing the fundamentals. In addition, it
> also serves as a home for numerical code that would otherwise have no
> home. I see no benefit in pulling in existing projects that are
> thriving on their own. As for PDEs, specifically, I think the domain
> is rich enough that it can usefully live in its own package better
> than being put into scipy. While there may be some fundamentals that
> you can pull out that might make sense to live in scipy (some simple
> good-enough mesh generation as you suggest), you will inevitably need
> more options, more sophisticated mesh generation, more dependencies,
> etc., that fits the development life cycle of a PDE-dedicated package
> more than scipy.
> 
> In other words, the important question isn't, "Can scipy do this?" but
> rather, "Can Python do this?".

Thanks Robert for expressing this so nicely!

>>> super-package that hopes to provide different bundles, kind of like sage
>>> but more targeted to numerical computing?
>> What do you mean by "we have a larger superpackage"? Are you asking if
>> we want to have such a package, or if we want scipy to become such a
>> package?
> 
> I don't think he's talking about a Python package, but rather a
> project that bundles Python packages together, like the SAGE
> distribution (which is much more than the sage Python package),
> Python(X,Y) and EPD. scipy is a Python package and can't really morph
> into a superpackage. It simply belongs to a different category of
> things. In fact, I suggest not using the term "superpackage" but
> "distribution".

Indeed, that is precisely what I meant --- a distribution tailored for 
PDEs would be nice.  If we had a fool proof distribution generation 
system that works on all platforms this would be trivial but easier said 
than done.

cheers,
prabhu


From dagss at student.matnat.uio.no  Thu Apr  9 08:34:05 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Thu, 9 Apr 2009 14:34:05 +0200 (CEST)
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49DDD96C.50106@aero.iitb.ac.in>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<49DDD96C.50106@aero.iitb.ac.in>
Message-ID: <f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>

Prabhu Ramachandran wrote:
> On 04/09/09 04:34, Robert Kern wrote:
>> I don't think he's talking about a Python package, but rather a
>> project that bundles Python packages together, like the SAGE
>> distribution (which is much more than the sage Python package),
>> Python(X,Y) and EPD. scipy is a Python package and can't really morph
>> into a superpackage. It simply belongs to a different category of
>> things. In fact, I suggest not using the term "superpackage" but
>> "distribution".
>
> Indeed, that is precisely what I meant --- a distribution tailored for
> PDEs would be nice.  If we had a fool proof distribution generation
> system that works on all platforms this would be trivial but easier said
> than done.

Someone said that Sage has a different focus -- but that is just because
most of the current active userbase are matematicians. From what I've
heard they certainly want to be "a viable open source alternative to ...
MATLAB ..." (as well as Maxima and Mathematica) and would welcome work on
that area.

I'm just saying that I hope we do NOT get a "tailored distribution for
PDEs". A very large part of what Sage or EPD brings to the table (notebook
interface, plotting GUIs, build and package system, builds on many
platforms, interactive Cython development etc.) are field neutral and I
think it would be better if the same system could in time be used by
"everybody". At least, this is a role Sage very much wants to take on.

(But SciPy is definitely a component of such a system, not the system
itself.)

The "workflow" of the average sciuentific programmer has a big potential
for improvement, and one cannot bring that about by further fragmentation.

Dag Sverre



From prabhu at aero.iitb.ac.in  Thu Apr  9 08:43:45 2009
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Thu, 09 Apr 2009 18:13:45 +0530
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>	<49DDD96C.50106@aero.iitb.ac.in>
	<f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>
Message-ID: <49DDED81.3090405@aero.iitb.ac.in>

On 04/09/09 18:04, Dag Sverre Seljebotn wrote:
> The "workflow" of the average sciuentific programmer has a big potential
> for improvement, and one cannot bring that about by further fragmentation.

I was not advocating fragmentation, any viable solution would be fine. 
IIRC, SPD itself is based on Sage and surely there will be some exchange 
of code/ideas between Sage and SPD at some time.  However, given a 
choice I would prefer a modular set of packages rather than one 
monolithic monster. I haven't delved into all the existing solutions 
enough to know if they are sufficiently modular or not.  The very fact 
that SPD exists suggests that there is scope for improvement.

cheers,
prabhu


From daniel.wheeler2 at gmail.com  Thu Apr  9 11:25:27 2009
From: daniel.wheeler2 at gmail.com (Daniel Wheeler)
Date: Thu, 9 Apr 2009 11:25:27 -0400
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
Message-ID: <80b160a0904090825m4421f567n9cdb5689d4a90786@mail.gmail.com>

On Wed, Apr 8, 2009 at 6:43 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> On Mon, Apr 6, 2009 at 8:58 AM, Daniel Wheeler
>> One weakness right now is that there doesn't seem to be a good open
>> source python based meshing tool. Again, this is not something that
>> should necessarily be in scipy, but something that should probably
>> leverage from scipy. We (FiPY) currently use gmsh, but it is not
>> tightly integrated and and we've written our own standard mesh
>> classes, but haven't done anything more with this.
>
> I like the FiPy project, when I get more time, I'd like to create some
> unified interface, so that one can take one equation and solve it with
> both FiPy and our FEM code (or libmesh), so that one can compare all
> those solvers and see which one performs the best.

Essentially, this is what we are trying to do with fipy. We would like
to access solvers from various packages via a common interface
(pysparse, scipy, trilinos, pykrylov, petsc, pyamg) and also call a
number of tools that construct matrices with different techniques. The
second part is harder to abstract and we only have our simple FV
method at the moment.

> Can FiPy do adaptive mesh refinement?

No. We'll wait until there is a meshing tool that can deal with it or
create a python interface to an existing tool at a push.

> I was trying to find it in the
> manual, but it seems you always need to create the mesh beforehand?

True.

> Then you calculate on it, you get something. How do you know if it's
> precise enough and if you should refine the mesh? How do you determine
> where you should refine it and how much?

Not something that fipy deals with at the moment. Basically it's a
task left to the user.

> If our FEM solver creates a nice hp mesh automatically, imho you
> cannot beat it by any hand made mesh, so then any comparison with a
> hand made mesh would be unfair to fipy.

Very true. h refinement is what we would like, but we require a third
party tool for this. The scope is too wide for us right now to deal
with.

-- 
Daniel Wheeler


From ondrej at certik.cz  Thu Apr  9 16:25:04 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 9 Apr 2009 13:25:04 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49DDED81.3090405@aero.iitb.ac.in>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<49DDD96C.50106@aero.iitb.ac.in>
	<f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>
	<49DDED81.3090405@aero.iitb.ac.in>
Message-ID: <85b5c3130904091325m72a5b342oe0de8cb4665b690c@mail.gmail.com>

On Thu, Apr 9, 2009 at 5:43 AM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> On 04/09/09 18:04, Dag Sverre Seljebotn wrote:
>> The "workflow" of the average sciuentific programmer has a big potential
>> for improvement, and one cannot bring that about by further fragmentation.
>
> I was not advocating fragmentation, any viable solution would be fine.
> IIRC, SPD itself is based on Sage and surely there will be some exchange
> of code/ideas between Sage and SPD at some time. ?However, given a
> choice I would prefer a modular set of packages rather than one
> monolithic monster. I haven't delved into all the existing solutions
> enough to know if they are sufficiently modular or not. ?The very fact
> that SPD exists suggests that there is scope for improvement.

The problem with Sage is that it doesn't include any PDE solver,
mayavi, not many sparse solvers (I think only superlu in scipy) etc. I
want all in one package, so the only way is to do it yourself, but SPD
is compatible with Sage, so any spkg package that works in Sage works
in SPD and vice versa.

I imagine, that after some time, Sage could include the good spkg
packages. So I don't see any problem or fragmentation here.

Ondrej


From dagss at student.matnat.uio.no  Fri Apr 10 04:46:41 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Fri, 10 Apr 2009 10:46:41 +0200 (CEST)
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49DDED81.3090405@aero.iitb.ac.in>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<49DDD96C.50106@aero.iitb.ac.in>
	<f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>
	<49DDED81.3090405@aero.iitb.ac.in>
Message-ID: <bcf31bbb3e781ff8cb869a058d913898.squirrel@webmail.uio.no>

Prabhu Ramachandran wrote:
> On 04/09/09 18:04, Dag Sverre Seljebotn wrote:
>> The "workflow" of the average sciuentific programmer has a big potential
>> for improvement, and one cannot bring that about by further
>> fragmentation.
>
> I was not advocating fragmentation, any viable solution would be fine.
> IIRC, SPD itself is based on Sage and surely there will be some exchange
> of code/ideas between Sage and SPD at some time.  However, given a
> choice I would prefer a modular set of packages rather than one
> monolithic monster. I haven't delved into all the existing solutions

I just wanted to comment on the monolithic monster thing: It does have its
advantages too. For instance R is included and can be depended upon by any
Sage script.

I'd much rather spend some hundred MBs disk space to have all the open
source software science packages (like R) installed, and work on improving
e.g. the R-to-Python bridge, than, say, reimplement the vast amount of
algorithms available for R in Python just because "I like Python better
than R".

That's the upside to having a monolithic monster: It allows you to "build
the car instead of reinventing the wheel", using things regardless of the
implementation language. Without distributing all the software together
it's incredibly hard to have the different pieces fit together everywhere
(R would be a slightly incompatible version with RPy, etc. etc.)

Dag Sverre



From jtravs at gmail.com  Fri Apr 10 05:23:23 2009
From: jtravs at gmail.com (John Travers)
Date: Fri, 10 Apr 2009 10:23:23 +0100
Subject: [SciPy-dev] [SciPy-user] Question including a boundary value
	problem solver in SciPy
In-Reply-To: <113e17f20904091043m5762fbd0m696bf032812934ba@mail.gmail.com>
References: <113e17f20904091043m5762fbd0m696bf032812934ba@mail.gmail.com>
Message-ID: <3a1077e70904100223n580472dev4ca683f30feef718@mail.gmail.com>

On Thu, Apr 9, 2009 at 6:43 PM, John Salvatier
<jsalvati at u.washington.edu> wrote:
> Hello,
>
> I am not sure this is the right place to ask this question, but I have
> wrapped a boundary value problem solver based on the Fortran code
> BVP_SOLVER. The PyPi page is here, and I have a tutorial for it here.

scipy-dev. I have cross-posted this reply. Please respond to the
scipy-dev thread.

>
> I am interested in integrating this into SciPy, so I have two questions: 1)
> Does this type of thing belong in SciPy? 2) if it is, what are the steps to
> getting this included in into SciPy?
>

Hi John,

This would be a very welcome addition!

I also made a wrapper for this code a few years back. Apart from the
license issues, which it sounds like you are solving, the main problem
with direct inclusion is that it is written in fortran 90, which scipy
currently does not depend on.

At the time I was told that making it a scikit would be the best
option for inclusion, and I think that is still true. This allows
scipy to still be independent of fortran 90 code. On the other hand,
as gfortran is now getting more stable and reasonably fast maybe it is
time to re-visit this issue.

Given that over the past two years I haven't made any moves to
actually make a scikit, then I guess you have more momentum to go
ahead with this. Note that there is a different boundary bvalue
problem solver available
(http://www.elisanet.fi/ptvirtan/software/bvp/index.html), it would be
nice if both were combined into a single scikit.

Cheers,
John


From prabhu at aero.iitb.ac.in  Fri Apr 10 06:48:20 2009
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Fri, 10 Apr 2009 16:18:20 +0530
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <bcf31bbb3e781ff8cb869a058d913898.squirrel@webmail.uio.no>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>	<49DDD96C.50106@aero.iitb.ac.in>	<f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>	<49DDED81.3090405@aero.iitb.ac.in>
	<bcf31bbb3e781ff8cb869a058d913898.squirrel@webmail.uio.no>
Message-ID: <49DF23F4.8050003@aero.iitb.ac.in>

On 04/10/09 14:16, Dag Sverre Seljebotn wrote:
> Prabhu Ramachandran wrote:
>> On 04/09/09 18:04, Dag Sverre Seljebotn wrote:
>>> The "workflow" of the average sciuentific programmer has a big potential
>>> for improvement, and one cannot bring that about by further
>>> fragmentation.
>> I was not advocating fragmentation, any viable solution would be fine.
>> IIRC, SPD itself is based on Sage and surely there will be some exchange
>> of code/ideas between Sage and SPD at some time.  However, given a
>> choice I would prefer a modular set of packages rather than one
>> monolithic monster. I haven't delved into all the existing solutions
> 
> I just wanted to comment on the monolithic monster thing: It does have its
> advantages too. For instance R is included and can be depended upon by any
> Sage script.

Apologies for sounding like someone who is against Sage.  Just for the 
record, I really like Sage and do promote it quite a bit over here.

I think we are digressing.  My point was I never thought that scipy is 
itself a distribution and Robert's comments seem to justify my stance. 
Python(x,y), EPD and Sage all are and Sage also does a whole lot more 
than just bundle stuff.  So bundling PDE tools in scipy doesn't seem 
like the right solution to me.  Thats all.

cheers,
prabhu


From ondrej at certik.cz  Fri Apr 10 06:57:39 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Fri, 10 Apr 2009 03:57:39 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49DF23F4.8050003@aero.iitb.ac.in>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<49DDD96C.50106@aero.iitb.ac.in>
	<f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>
	<49DDED81.3090405@aero.iitb.ac.in>
	<bcf31bbb3e781ff8cb869a058d913898.squirrel@webmail.uio.no>
	<49DF23F4.8050003@aero.iitb.ac.in>
Message-ID: <85b5c3130904100357l78a6ccf8gd50a5014d6c141d9@mail.gmail.com>

On Fri, Apr 10, 2009 at 3:48 AM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> On 04/10/09 14:16, Dag Sverre Seljebotn wrote:
>> Prabhu Ramachandran wrote:
>>> On 04/09/09 18:04, Dag Sverre Seljebotn wrote:
>>>> The "workflow" of the average sciuentific programmer has a big potential
>>>> for improvement, and one cannot bring that about by further
>>>> fragmentation.
>>> I was not advocating fragmentation, any viable solution would be fine.
>>> IIRC, SPD itself is based on Sage and surely there will be some exchange
>>> of code/ideas between Sage and SPD at some time. ?However, given a
>>> choice I would prefer a modular set of packages rather than one
>>> monolithic monster. I haven't delved into all the existing solutions
>>
>> I just wanted to comment on the monolithic monster thing: It does have its
>> advantages too. For instance R is included and can be depended upon by any
>> Sage script.
>
> Apologies for sounding like someone who is against Sage. ?Just for the
> record, I really like Sage and do promote it quite a bit over here.
>
> I think we are digressing. ?My point was I never thought that scipy is
> itself a distribution and Robert's comments seem to justify my stance.
> Python(x,y), EPD and Sage all are and Sage also does a whole lot more
> than just bundle stuff. ?So bundling PDE tools in scipy doesn't seem
> like the right solution to me. ?Thats all.

Yes, but you may use the same kind of argument to support that scipy
should not exist at all and you should just always create a new
project for whatever you do and use Sage to bundle it together.

So it's just a question where to draw the line and I think it's clear
now from this thread that PDE doesn't belong to scipy.

Ondrej


From dagss at student.matnat.uio.no  Fri Apr 10 08:27:28 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Fri, 10 Apr 2009 14:27:28 +0200 (CEST)
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49DF23F4.8050003@aero.iitb.ac.in>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<49DDD96C.50106@aero.iitb.ac.in>
	<f6df0a90babbaf86440474064c1190ca.squirrel@webmail.uio.no>
	<49DDED81.3090405@aero.iitb.ac.in>
	<bcf31bbb3e781ff8cb869a058d913898.squirrel@webmail.uio.no>
	<49DF23F4.8050003@aero.iitb.ac.in>
Message-ID: <3f67cf45ff85f78d9f7962627e554d24.squirrel@webmail.uio.no>

Prabhu Ramachandran wrote:
> On 04/10/09 14:16, Dag Sverre Seljebotn wrote:
>> Prabhu Ramachandran wrote:
>>> On 04/09/09 18:04, Dag Sverre Seljebotn wrote:
>>>> The "workflow" of the average sciuentific programmer has a big
>>>> potential
>>>> for improvement, and one cannot bring that about by further
>>>> fragmentation.
>>> I was not advocating fragmentation, any viable solution would be fine.
>>> IIRC, SPD itself is based on Sage and surely there will be some
>>> exchange
>>> of code/ideas between Sage and SPD at some time.  However, given a
>>> choice I would prefer a modular set of packages rather than one
>>> monolithic monster. I haven't delved into all the existing solutions
>>
>> I just wanted to comment on the monolithic monster thing: It does have
>> its
>> advantages too. For instance R is included and can be depended upon by
>> any
>> Sage script.
>
> Apologies for sounding like someone who is against Sage.  Just for the
> record, I really like Sage and do promote it quite a bit over here.

I didn't take it that way at all! I guess I was just digressing and
continueing on what you said, it didn't have all that much to do with the
concrete matter at hand.

Dag Sverre



From gael.varoquaux at normalesup.org  Fri Apr 10 16:04:50 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 10 Apr 2009 22:04:50 +0200
Subject: [SciPy-dev] LARS algorithm
Message-ID: <20090410200450.GA3641@phare.normalesup.org>

Has anybody implemented the LARS[1] (least angle regression) algorithm for
regularized regression in Python or in C binded in Python?

I am about to start in such endeaviour, but I wanted to check if someone
was willing to share code under a BSD-compatible license.

Ga?l

[1] http://en.wikipedia.org/wiki/Least-angle_regression

PS: Sorry for the cross-post, I just wanted to be really sure that if
anybody was willing to share such code, I would reach him :)


From jsseabold at gmail.com  Fri Apr 10 21:42:35 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Fri, 10 Apr 2009 21:42:35 -0400
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
Message-ID: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>

Hello all,

I am having some trouble compiling the development versions of Scipy
and Numpy from SVN and then getting the tests to run without errors.
>From the errors I've seen and having combed the archives, I wonder if
it's a compiler issue (gnu95 4.3.2).  Or most likely some other user
error...  So far I have tried to avoid installing ATLAS and LAPACK
from source.

I am using openSUSE 11.1 (32-bit), Python 2.6, and the most recent
version of scipy and numpy from SVN.  I have installed the following
all from the openSUSE repo openSUSE_Education

libatlas3
libatlas3-devel
blas
libblas3
libumfpack5_2_0
umfpack-devel
lapack
liblapack3
fftw
fftw-devel
fftw3
fftw3-devel
fftw3-threads
amd
amd-devel
libamd2_2_0

For both Numpy and Scipy, I edited the site.cfg as I discovered was
necessary after a first go around.

[DEFAULT]
library_dirs = /usr/local/lib:/usr/lib
include_dirs = /usr/local/include:/usr/include:/usr/include/suitesparse

And uncommented blas, lapack (not the pthreads), amd, umfpack, fftw

I then ran for numpy

~>python setup.py build --help-fcompiler
Says that gnu95 (4.3.2) is found
~>python setup.py build --fcompiler=gnu95
~>sudo python setup.py install --prefix="/usr"

For Scipy
~>python setup.py build --fcompiler=gnu95
~>sudo python setup.py install --prefix="/usr"

Both install without any errors.

Tests go as follows

>>> np.test()
...
Ran 2036 tests in 10.726s

OK (KNOWNFAIL=1)
<nose.result.TextTestResult run=2036 errors=0 failures=0>

>>> sp.test()
Running unit tests for scipy
NumPy version 1.4.0.dev6859
NumPy is installed in /usr/lib/python2.6/site-packages/numpy
SciPy version 0.8.0.dev5655
SciPy is installed in /usr/lib/python2.6/site-packages/scipy
Python version 2.6 (r26:66714, Feb  3 2009, 20:52:03) [GCC 4.3.2
[gcc-4_3-branch revision 141291]]
nose version 0.10.4
......................................................................................................................................................................................................................................................................E.........................................................../usr/lib/python2.6/site-packages/scipy/io/matlab/tests/test_mio.py:437:
FutureWarning: Using oned_as default value ('column') This will change
to 'row' in future versions
  mfw = MatFile5Writer(StringIO())
......../usr/lib/python2.6/site-packages/scipy/io/matlab/mio.py:84:
FutureWarning: Using struct_as_record default value (False) This will
change to True in future versions
  return MatFile5Reader(byte_stream, **kwargs)
.............Warning: 1000000 bytes requested, 20 bytes read.
./usr/lib/python2.6/site-packages/numpy/lib/utils.py:108:
DeprecationWarning: write_array is deprecated
  warnings.warn(str1, DeprecationWarning)
/usr/lib/python2.6/site-packages/numpy/lib/utils.py:108:
DeprecationWarning: read_array is deprecated
  warnings.warn(str1, DeprecationWarning)
..E..................../usr/lib/python2.6/site-packages/numpy/lib/utils.py:108:
DeprecationWarning: npfile is deprecated
  warnings.warn(str1, DeprecationWarning)
.........................................................................................................................................................EEE....................................................................................................................................................................................................................................................................................................................................................................................................................................E......................................E..../usr/lib/python2.6/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:143:
DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be
removed, install scikits.umfpack instead
  ' install scikits.umfpack instead', DeprecationWarning )
../usr/lib/python2.6/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:78:
DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be
removed, install scikits.umfpack instead
  ' install scikits.umfpack instead', DeprecationWarning )
.....E.......EE............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E...........................................................warning:
specified build_dir '_bad_path_' does not exist or is not writable.
Trying default locations
...warning: specified build_dir '..' does not exist or is not
writable. Trying default locations
..warning: specified build_dir '_bad_path_' does not exist or is not
writable. Trying default locations
...warning: specified build_dir '..' does not exist or is not
writable. Trying default locations
............................building extensions here:
/home/skipper/.python26_compiled/m30
................................................................................................
======================================================================
ERROR: Failure: ImportError
(/usr/lib/python2.6/site-packages/scipy/linalg/clapack.so: undefined
symbol: clapack_sgesv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/interpolate/__init__.py",
line 13, in <module>
    from rbf import Rbf
  File "/usr/lib/python2.6/site-packages/scipy/interpolate/rbf.py",
line 47, in <module>
    from scipy import linalg
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
18, in <module>
    from scipy.linalg import clapack
ImportError: /usr/lib/python2.6/site-packages/scipy/linalg/clapack.so:
undefined symbol: clapack_sgesv

======================================================================
ERROR: test_integer (test_array_import.TestReadArray)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/scipy/io/tests/test_array_import.py",
line 52, in test_integer
    from scipy import stats
  File "/usr/lib/python2.6/site-packages/scipy/stats/__init__.py",
line 7, in <module>
    from stats import *
  File "/usr/lib/python2.6/site-packages/scipy/stats/stats.py", line
199, in <module>
    import scipy.linalg as linalg
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError
(/usr/lib/python2.6/site-packages/scipy/lib/lapack/clapack.so:
undefined symbol: clapack_sgesv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/lib/lapack/__init__.py",
line 16, in <module>
    import clapack
ImportError: /usr/lib/python2.6/site-packages/scipy/lib/lapack/clapack.so:
undefined symbol: clapack_sgesv

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/maxentropy/__init__.py",
line 9, in <module>
    from maxentropy import *
  File "/usr/lib/python2.6/site-packages/scipy/maxentropy/maxentropy.py",
line 75, in <module>
    from scipy.linalg import norm
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: test_implicit (test_odr.TestODR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/scipy/odr/tests/test_odr.py",
line 88, in test_implicit
    out = implicit_odr.run()
  File "/usr/lib/python2.6/site-packages/scipy/odr/odrpack.py", line
1055, in run
    self.output = Output(apply(odr, args, kwds))
TypeError: y must be a sequence or integer (if model is implicit)

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/signal/__init__.py",
line 11, in <module>
    from ltisys import *
  File "/usr/lib/python2.6/site-packages/scipy/signal/ltisys.py", line
9, in <module>
    import scipy.interpolate as interpolate
  File "/usr/lib/python2.6/site-packages/scipy/interpolate/__init__.py",
line 13, in <module>
    from rbf import Rbf
  File "/usr/lib/python2.6/site-packages/scipy/interpolate/rbf.py",
line 47, in <module>
    from scipy import linalg
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/sparse/linalg/dsolve/tests/test_linsolve.py",
line 6, in <module>
    from scipy.linalg import norm, inv
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/sparse/linalg/eigen/lobpcg/tests/test_lobpcg.py",
line 8, in <module>
    from scipy import arange, ones, rand, set_printoptions, r_, diag,
linalg
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py",
line 8, in <module>
    from scipy.linalg import norm
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.6/site-packages/scipy/stats/__init__.py",
line 7, in <module>
    from stats import *
  File "/usr/lib/python2.6/site-packages/scipy/stats/stats.py", line
199, in <module>
    import scipy.linalg as linalg
  File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
line 8, in <module>
    from basic import *
  File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

----------------------------------------------------------------------
Ran 2216 tests in 24.603s

FAILED (errors=11)
<nose.result.TextTestResult run=2216 errors=11 failures=0>

---

Some more possibly useful output (though I'm not quite sure I see any
problem here):

skipper at linux:/usr/lib/python2.6/site-packages/scipy/linalg> ldd flapack.so
        linux-gate.so.1 =>  (0xffffe000)
        /usr/lib/libv4l/v4l2convert.so (0xb8056000)
        liblapack.so.3 => /usr/lib/liblapack.so.3 (0xb77f9000)
        libf77blas.so => /usr/lib/libf77blas.so (0xb77d8000)
        libcblas.so => /usr/lib/libcblas.so (0xb77b6000)
        libatlas.so => /usr/lib/libatlas.so (0xb712e000)
        libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb6fc0000)
        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb6f05000)
        libm.so.6 => /lib/libm.so.6 (0xb6edc000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ecd000)
        libc.so.6 => /lib/libc.so.6 (0xb6d71000)
        libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb6d66000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0xb6cb8000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6c9e000)
        libdl.so.2 => /lib/libdl.so.2 (0xb6c99000)
        libutil.so.1 => /lib/libutil.so.1 (0xb6c95000)
        /lib/ld-linux.so.2 (0xb80c9000)
        libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb6c2e000)

skipper at linux:/usr/lib/python2.6/site-packages/scipy/linalg> ldd clapack.so
        linux-gate.so.1 =>  (0xffffe000)
        /usr/lib/libv4l/v4l2convert.so (0xb8083000)
        liblapack.so.3 => /usr/lib/liblapack.so.3 (0xb7826000)
        libf77blas.so => /usr/lib/libf77blas.so (0xb7805000)
        libcblas.so => /usr/lib/libcblas.so (0xb77e3000)
        libatlas.so => /usr/lib/libatlas.so (0xb715b000)
        libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb6fed000)
        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb6f32000)
        libm.so.6 => /lib/libm.so.6 (0xb6f09000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6efa000)
        libc.so.6 => /lib/libc.so.6 (0xb6d9e000)
        libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb6d93000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0xb6ce5000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6ccb000)
        libdl.so.2 => /lib/libdl.so.2 (0xb6cc6000)
        libutil.so.1 => /lib/libutil.so.1 (0xb6cc2000)
        /lib/ld-linux.so.2 (0xb80a4000)
        libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb6c5b000)

Any help or advice would be much appreciated.  I can provide anymore
information that would be useful.

Cheers,

Skipper


From josef.pktd at gmail.com  Fri Apr 10 23:21:27 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 10 Apr 2009 23:21:27 -0400
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
In-Reply-To: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
References: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
Message-ID: <1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>

On Fri, Apr 10, 2009 at 9:42 PM, Skipper Seabold <jsseabold at gmail.com> wrote:
> Hello all,
>
> I am having some trouble compiling the development versions of Scipy
> and Numpy from SVN and then getting the tests to run without errors.
> >From the errors I've seen and having combed the archives, I wonder if
> it's a compiler issue (gnu95 4.3.2). ?Or most likely some other user
> error... ?So far I have tried to avoid installing ATLAS and LAPACK
> from source.
>
> I am using openSUSE 11.1 (32-bit), Python 2.6, and the most recent
> version of scipy and numpy from SVN. ?I have installed the following
> all from the openSUSE repo openSUSE_Education
>
> libatlas3
> libatlas3-devel
> blas
> libblas3
> libumfpack5_2_0
> umfpack-devel
> lapack
> liblapack3
> fftw
> fftw-devel
> fftw3
> fftw3-devel
> fftw3-threads
> amd
> amd-devel
> libamd2_2_0
>
> For both Numpy and Scipy, I edited the site.cfg as I discovered was
> necessary after a first go around.
>
> [DEFAULT]
> library_dirs = /usr/local/lib:/usr/lib
> include_dirs = /usr/local/include:/usr/include:/usr/include/suitesparse
>
> And uncommented blas, lapack (not the pthreads), amd, umfpack, fftw
>
> I then ran for numpy
>
> ~>python setup.py build --help-fcompiler
> Says that gnu95 (4.3.2) is found
> ~>python setup.py build --fcompiler=gnu95
> ~>sudo python setup.py install --prefix="/usr"
>
> For Scipy
> ~>python setup.py build --fcompiler=gnu95
> ~>sudo python setup.py install --prefix="/usr"
>
> Both install without any errors.
>
> Tests go as follows
>
>>>> np.test()
> ...
> Ran 2036 tests in 10.726s
>
> OK (KNOWNFAIL=1)
> <nose.result.TextTestResult run=2036 errors=0 failures=0>
>
>>>> sp.test()
> Running unit tests for scipy
> NumPy version 1.4.0.dev6859
> NumPy is installed in /usr/lib/python2.6/site-packages/numpy
> SciPy version 0.8.0.dev5655
> SciPy is installed in /usr/lib/python2.6/site-packages/scipy
> Python version 2.6 (r26:66714, Feb ?3 2009, 20:52:03) [GCC 4.3.2
> [gcc-4_3-branch revision 141291]]
> nose version 0.10.4
> ......................................................................................................................................................................................................................................................................E.........................................................../usr/lib/python2.6/site-packages/scipy/io/matlab/tests/test_mio.py:437:
> FutureWarning: Using oned_as default value ('column') This will change
> to 'row' in future versions
> ?mfw = MatFile5Writer(StringIO())
> ......../usr/lib/python2.6/site-packages/scipy/io/matlab/mio.py:84:
> FutureWarning: Using struct_as_record default value (False) This will
> change to True in future versions
> ?return MatFile5Reader(byte_stream, **kwargs)
> .............Warning: 1000000 bytes requested, 20 bytes read.
> ./usr/lib/python2.6/site-packages/numpy/lib/utils.py:108:
> DeprecationWarning: write_array is deprecated
> ?warnings.warn(str1, DeprecationWarning)
> /usr/lib/python2.6/site-packages/numpy/lib/utils.py:108:
> DeprecationWarning: read_array is deprecated
> ?warnings.warn(str1, DeprecationWarning)
> ..E..................../usr/lib/python2.6/site-packages/numpy/lib/utils.py:108:
> DeprecationWarning: npfile is deprecated
> ?warnings.warn(str1, DeprecationWarning)
> .........................................................................................................................................................EEE....................................................................................................................................................................................................................................................................................................................................................................................................................................E......................................E..../usr/lib/python2.6/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:143:
> DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be
> removed, install scikits.umfpack instead
> ?' install scikits.umfpack instead', DeprecationWarning )
> ../usr/lib/python2.6/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:78:
> DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be
> removed, install scikits.umfpack instead
> ?' install scikits.umfpack instead', DeprecationWarning )
> .....E.......EE...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
> ?.............................................E...........................................................warning:
> specified build_dir '_bad_path_' does not exist or is not writable.
> Trying default locations
> ...warning: specified build_dir '..' does not exist or is not
> writable. Trying default locations
> ..warning: specified build_dir '_bad_path_' does not exist or is not
> writable. Trying default locations
> ...warning: specified build_dir '..' does not exist or is not
> writable. Trying default locations
> ............................building extensions here:
> /home/skipper/.python26_compiled/m30
> ................................................................................................
> ======================================================================
> ERROR: Failure: ImportError
> (/usr/lib/python2.6/site-packages/scipy/linalg/clapack.so: undefined
> symbol: clapack_sgesv)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/interpolate/__init__.py",
> line 13, in <module>
> ? ?from rbf import Rbf
> ?File "/usr/lib/python2.6/site-packages/scipy/interpolate/rbf.py",
> line 47, in <module>
> ? ?from scipy import linalg
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 18, in <module>
> ? ?from scipy.linalg import clapack
> ImportError: /usr/lib/python2.6/site-packages/scipy/linalg/clapack.so:
> undefined symbol: clapack_sgesv
>
> ======================================================================
> ERROR: test_integer (test_array_import.TestReadArray)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/scipy/io/tests/test_array_import.py",
> line 52, in test_integer
> ? ?from scipy import stats
> ?File "/usr/lib/python2.6/site-packages/scipy/stats/__init__.py",
> line 7, in <module>
> ? ?from stats import *
> ?File "/usr/lib/python2.6/site-packages/scipy/stats/stats.py", line
> 199, in <module>
> ? ?import scipy.linalg as linalg
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: Failure: ImportError
> (/usr/lib/python2.6/site-packages/scipy/lib/lapack/clapack.so:
> undefined symbol: clapack_sgesv)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/lib/lapack/__init__.py",
> line 16, in <module>
> ? ?import clapack
> ImportError: /usr/lib/python2.6/site-packages/scipy/lib/lapack/clapack.so:
> undefined symbol: clapack_sgesv
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/maxentropy/__init__.py",
> line 9, in <module>
> ? ?from maxentropy import *
> ?File "/usr/lib/python2.6/site-packages/scipy/maxentropy/maxentropy.py",
> line 75, in <module>
> ? ?from scipy.linalg import norm
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: test_implicit (test_odr.TestODR)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/scipy/odr/tests/test_odr.py",
> line 88, in test_implicit
> ? ?out = implicit_odr.run()
> ?File "/usr/lib/python2.6/site-packages/scipy/odr/odrpack.py", line
> 1055, in run
> ? ?self.output = Output(apply(odr, args, kwds))
> TypeError: y must be a sequence or integer (if model is implicit)
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/signal/__init__.py",
> line 11, in <module>
> ? ?from ltisys import *
> ?File "/usr/lib/python2.6/site-packages/scipy/signal/ltisys.py", line
> 9, in <module>
> ? ?import scipy.interpolate as interpolate
> ?File "/usr/lib/python2.6/site-packages/scipy/interpolate/__init__.py",
> line 13, in <module>
> ? ?from rbf import Rbf
> ?File "/usr/lib/python2.6/site-packages/scipy/interpolate/rbf.py",
> line 47, in <module>
> ? ?from scipy import linalg
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/sparse/linalg/dsolve/tests/test_linsolve.py",
> line 6, in <module>
> ? ?from scipy.linalg import norm, inv
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/sparse/linalg/eigen/lobpcg/tests/test_lobpcg.py",
> line 8, in <module>
> ? ?from scipy import arange, ones, rand, set_printoptions, r_, diag,
> linalg
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py",
> line 8, in <module>
> ? ?from scipy.linalg import norm
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ======================================================================
> ERROR: Failure: ImportError (cannot import name flapack)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/loader.py",
> line 364, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "/usr/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/importer.py",
> line 84, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "/usr/lib/python2.6/site-packages/scipy/stats/__init__.py",
> line 7, in <module>
> ? ?from stats import *
> ?File "/usr/lib/python2.6/site-packages/scipy/stats/stats.py", line
> 199, in <module>
> ? ?import scipy.linalg as linalg
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/__init__.py",
> line 8, in <module>
> ? ?from basic import *
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/basic.py", line
> 17, in <module>
> ? ?from lapack import get_lapack_funcs
> ?File "/usr/lib/python2.6/site-packages/scipy/linalg/lapack.py", line
> 17, in <module>
> ? ?from scipy.linalg import flapack
> ImportError: cannot import name flapack
>
> ----------------------------------------------------------------------
> Ran 2216 tests in 24.603s
>
> FAILED (errors=11)
> <nose.result.TextTestResult run=2216 errors=11 failures=0>
>
> ---
>
> Some more possibly useful output (though I'm not quite sure I see any
> problem here):
>
> skipper at linux:/usr/lib/python2.6/site-packages/scipy/linalg> ldd flapack.so
> ? ? ? ?linux-gate.so.1 => ?(0xffffe000)
> ? ? ? ?/usr/lib/libv4l/v4l2convert.so (0xb8056000)
> ? ? ? ?liblapack.so.3 => /usr/lib/liblapack.so.3 (0xb77f9000)
> ? ? ? ?libf77blas.so => /usr/lib/libf77blas.so (0xb77d8000)
> ? ? ? ?libcblas.so => /usr/lib/libcblas.so (0xb77b6000)
> ? ? ? ?libatlas.so => /usr/lib/libatlas.so (0xb712e000)
> ? ? ? ?libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb6fc0000)
> ? ? ? ?libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb6f05000)
> ? ? ? ?libm.so.6 => /lib/libm.so.6 (0xb6edc000)
> ? ? ? ?libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ecd000)
> ? ? ? ?libc.so.6 => /lib/libc.so.6 (0xb6d71000)
> ? ? ? ?libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb6d66000)
> ? ? ? ?libblas.so.3 => /usr/lib/libblas.so.3 (0xb6cb8000)
> ? ? ? ?libpthread.so.0 => /lib/libpthread.so.0 (0xb6c9e000)
> ? ? ? ?libdl.so.2 => /lib/libdl.so.2 (0xb6c99000)
> ? ? ? ?libutil.so.1 => /lib/libutil.so.1 (0xb6c95000)
> ? ? ? ?/lib/ld-linux.so.2 (0xb80c9000)
> ? ? ? ?libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb6c2e000)
>
> skipper at linux:/usr/lib/python2.6/site-packages/scipy/linalg> ldd clapack.so
> ? ? ? ?linux-gate.so.1 => ?(0xffffe000)
> ? ? ? ?/usr/lib/libv4l/v4l2convert.so (0xb8083000)
> ? ? ? ?liblapack.so.3 => /usr/lib/liblapack.so.3 (0xb7826000)
> ? ? ? ?libf77blas.so => /usr/lib/libf77blas.so (0xb7805000)
> ? ? ? ?libcblas.so => /usr/lib/libcblas.so (0xb77e3000)
> ? ? ? ?libatlas.so => /usr/lib/libatlas.so (0xb715b000)
> ? ? ? ?libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb6fed000)
> ? ? ? ?libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb6f32000)
> ? ? ? ?libm.so.6 => /lib/libm.so.6 (0xb6f09000)
> ? ? ? ?libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6efa000)
> ? ? ? ?libc.so.6 => /lib/libc.so.6 (0xb6d9e000)
> ? ? ? ?libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb6d93000)
> ? ? ? ?libblas.so.3 => /usr/lib/libblas.so.3 (0xb6ce5000)
> ? ? ? ?libpthread.so.0 => /lib/libpthread.so.0 (0xb6ccb000)
> ? ? ? ?libdl.so.2 => /lib/libdl.so.2 (0xb6cc6000)
> ? ? ? ?libutil.so.1 => /lib/libutil.so.1 (0xb6cc2000)
> ? ? ? ?/lib/ld-linux.so.2 (0xb80a4000)
> ? ? ? ?libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb6c5b000)
>
> Any help or advice would be much appreciated. ?I can provide anymore
> information that would be useful.
>
> Cheers,
>
> Skipper


If I interpret Davids usually explanations and your logs correctly
then you are mixing fortran compilers, lapack is using gfortran and
you are using g95, which showed up pretty often on the mailing lists.

But this is just pattern recognition, I don't know anything about opensuse.

Josef


From charlesr.harris at gmail.com  Sat Apr 11 00:37:53 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 10 Apr 2009 22:37:53 -0600
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
In-Reply-To: <1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>
References: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
	<1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>
Message-ID: <e06186140904102137j4571ecbej1a8b18fdf0ee87f5@mail.gmail.com>

On Fri, Apr 10, 2009 at 9:21 PM, <josef.pktd at gmail.com> wrote:

> On Fri, Apr 10, 2009 at 9:42 PM, Skipper Seabold <jsseabold at gmail.com>
> wrote:
> > Hello all,
> >
> > I am having some trouble compiling the development versions of Scipy
> > and Numpy from SVN and then getting the tests to run without errors.
> > >From the errors I've seen and having combed the archives, I wonder if
> > it's a compiler issue (gnu95 4.3.2).  Or most likely some other user
> > error...  So far I have tried to avoid installing ATLAS and LAPACK
> > from source.
> >
> > I am using openSUSE 11.1 (32-bit), Python 2.6, and the most recent
> > version of scipy and numpy from SVN.  I have installed the following
> > all from the openSUSE repo openSUSE_Education
> >
> > libatlas3
> > libatlas3-devel
> > blas
> > libblas3
> > libumfpack5_2_0
> > umfpack-devel
> > lapack
> > liblapack3
> > fftw
> > fftw-devel
> > fftw3
> > fftw3-devel
> > fftw3-threads
> > amd
> > amd-devel
> > libamd2_2_0
> >
> > For both Numpy and Scipy, I edited the site.cfg as I discovered was
> > necessary after a first go around.
> >
> > [DEFAULT]
> > library_dirs = /usr/local/lib:/usr/lib
> > include_dirs = /usr/local/include:/usr/include:/usr/include/suitesparse
> >
> > And uncommented blas, lapack (not the pthreads), amd, umfpack, fftw
> >
>

<snip>

>
>
> If I interpret Davids usually explanations and your logs correctly
> then you are mixing fortran compilers, lapack is using gfortran and
> you are using g95, which showed up pretty often on the mailing lists.
>
> But this is just pattern recognition, I don't know anything about opensuse.
>

IIRC, there was some problem with opensuse reported on the mailing list.
<searches> hmm, there was a 32/64 bit issue about two weeks ago. And there
are opensuse repositories with current numpy and scipy
here<http://download.opensuse.org/repositories/Education/>.


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

From thouis at broad.mit.edu  Sat Apr 11 12:37:08 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Sat, 11 Apr 2009 12:37:08 -0400
Subject: [SciPy-dev] regression test for reading compressed matlab streams
Message-ID: <6c17e6f50904110937g6b08550dma58b0a835a06c3f4@mail.gmail.com>

I just submitted a ticket and patch to add a regression test for
reading compressed matlab streams via the mat_reader_factory.
http://projects.scipy.org/scipy/ticket/918

The bug was discovered by Lee Kamentsky, who also wrote the test and a
patch for the 0.7.0 code.  The current development tree no longer has
the bug, due to the rewrites of the compressed stream reader code by
Matthew Brett, so I didn't bother submitting that part of Lee's patch.
 If there's some need for it, let me know.

Ray Jones


From jsseabold at gmail.com  Sat Apr 11 14:17:06 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Sat, 11 Apr 2009 14:17:06 -0400
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
In-Reply-To: <e06186140904102137j4571ecbej1a8b18fdf0ee87f5@mail.gmail.com>
References: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
	<1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>
	<e06186140904102137j4571ecbej1a8b18fdf0ee87f5@mail.gmail.com>
Message-ID: <c048da1c0904111117v23415308t21965094de0f5535@mail.gmail.com>

On Sat, Apr 11, 2009 at 12:37 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Fri, Apr 10, 2009 at 9:21 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Fri, Apr 10, 2009 at 9:42 PM, Skipper Seabold <jsseabold at gmail.com>
>> wrote:
>> > Hello all,
>> >
>> > I am having some trouble compiling the development versions of Scipy
>> > and Numpy from SVN and then getting the tests to run without errors.
>> > >From the errors I've seen and having combed the archives, I wonder if
>> > it's a compiler issue (gnu95 4.3.2). ?Or most likely some other user
>> > error... ?So far I have tried to avoid installing ATLAS and LAPACK
>> > from source.
>> >
>> > I am using openSUSE 11.1 (32-bit), Python 2.6, and the most recent
>> > version of scipy and numpy from SVN. ?I have installed the following
>> > all from the openSUSE repo openSUSE_Education
>> >
>> > libatlas3
>> > libatlas3-devel
>> > blas
>> > libblas3
>> > libumfpack5_2_0
>> > umfpack-devel
>> > lapack
>> > liblapack3
>> > fftw
>> > fftw-devel
>> > fftw3
>> > fftw3-devel
>> > fftw3-threads
>> > amd
>> > amd-devel
>> > libamd2_2_0
>> >
>> > For both Numpy and Scipy, I edited the site.cfg as I discovered was
>> > necessary after a first go around.
>> >
>> > [DEFAULT]
>> > library_dirs = /usr/local/lib:/usr/lib
>> > include_dirs = /usr/local/include:/usr/include:/usr/include/suitesparse
>> >
>> > And uncommented blas, lapack (not the pthreads), amd, umfpack, fftw
>> >
>
> <snip>
>>
>>
>> If I interpret Davids usually explanations and your logs correctly
>> then you are mixing fortran compilers, lapack is using gfortran and
>> you are using g95, which showed up pretty often on the mailing lists.
>>
>> But this is just pattern recognition, I don't know anything about
>> opensuse.
>
> IIRC, there was some problem with opensuse reported on the mailing list.
> <searches> hmm, there was a 32/64 bit issue about two weeks ago. And there
> are opensuse repositories with current numpy and scipy here.
>
> Chuck

Thanks for the pointers.  I've seen discussion of similar problems in
the archives and the build instructions on the site, so I thought it
was a compiler issue.  I still had the same errors when building scipy
with "~>python setup.py build=gfortran" (gfortran as part of gcc 4.3
on opensuse at least), so I wondered if I could get it to work after
compiling BLAS, LAPACK, and ATLAS from source explicitly using
gfortran then installing numpy and scipy explicitly with gfortran.
Still getting the same error messages.

First before I get into the last few things that I can think of, sorry
for all the questions.  If the next few steps don't work, I am open to
switching Linux distributions and seeing if I have more luck because I
am about at the end of my abilities (and time constraint).  I have
seen that Debian-based distributions are usually better for Scipy and
the extensions.  Is there a particular "flavor" that is popular for
Scipy developers?

Ok, last few thoughts.

Is it still true that gcc 3.x compilers are recommended?  Wondering
how old that information is.

Could someone explain this note in the installation instructions found
here: <http://www.scipy.org/Installing_SciPy/BuildingGeneral#head-afafb64f8d0edbe09e7b85c43c08cd5bd5904350>

"NOTE: scipy may not find the libf* names.  You may have to make a
symbolic link from these files to libblas.a and liblapack.a  Numpy
does not seem to have this problem."

I do not have a plain libblas.a after building BLAS, LAPACK, and
ATLAS, only libfblas.a from the BLAS build and libf77blas.a and
libcblas.a from the ATLAS build.

Should I create a symbolic link from libflapack.a to the liblapack.a
that I have after I installed ATLAS following these instructions:
<http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c>

Do I just run
~> ln -s /usr/bin/libflapack.a /usr/bin/liblapack.a

I also wonder if I should have included the compiler flag
"-fno-second-underscore" to make when building LAPACK and ATLAS as is
instructed to do for BLAS.

Thanks for any help,

Skipper


From josef.pktd at gmail.com  Sat Apr 11 14:28:07 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 11 Apr 2009 14:28:07 -0400
Subject: [SciPy-dev] integrate.ode: dop, zvode accessibility
Message-ID: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>

I was looking at the import structure in integrate.

in integrate __init__ there is   `from ode import *`
since ode has a class ode, the module ode is shadowed and not
available for access anymore

So, it seems that there is now way to access zvode and dopri5 and dop853
unless I am mistaken. integrate.dop refers to the fortran library

>>> dir(integrate.dop)
['__doc__', '__file__', '__name__', '__version__', 'dop853', 'dopri5']
>>> integrate.dop.dop853
<fortran object at 0x01B3B8A8>

(In general, I don't like modules and classes or functions that have
the same names when combined with, from ... import *, since it
prevents direct module access of the shadowed module.)

Josef


From josef.pktd at gmail.com  Sat Apr 11 14:52:50 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 11 Apr 2009 14:52:50 -0400
Subject: [SciPy-dev] integrate.ode: dop, zvode accessibility
In-Reply-To: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>
References: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>
Message-ID: <1cd32cbb0904111152u2fab922etc9d3a50a2367d34f@mail.gmail.com>

On Sat, Apr 11, 2009 at 2:28 PM,  <josef.pktd at gmail.com> wrote:
> I was looking at the import structure in integrate.
>
> in integrate __init__ there is ? `from ode import *`
> since ode has a class ode, the module ode is shadowed and not
> available for access anymore
>
> So, it seems that there is now way to access zvode and dopri5 and dop853
> unless I am mistaken. integrate.dop refers to the fortran library
>
>>>> dir(integrate.dop)
> ['__doc__', '__file__', '__name__', '__version__', 'dop853', 'dopri5']
>>>> integrate.dop.dop853
> <fortran object at 0x01B3B8A8>
>
> (In general, I don't like modules and classes or functions that have
> the same names when combined with, from ... import *, since it
> prevents direct module access of the shadowed module.)
>
> Josef
>

to clarify:
They are accessible as integrators in ode and complex_ode but not
directly. So the question is whether they are hidden away
intentionally.

Josef


From gael.varoquaux at normalesup.org  Sat Apr 11 17:45:43 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 11 Apr 2009 23:45:43 +0200
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
In-Reply-To: <c048da1c0904111117v23415308t21965094de0f5535@mail.gmail.com>
References: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
	<1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>
	<e06186140904102137j4571ecbej1a8b18fdf0ee87f5@mail.gmail.com>
	<c048da1c0904111117v23415308t21965094de0f5535@mail.gmail.com>
Message-ID: <20090411214543.GC22984@phare.normalesup.org>

On Sat, Apr 11, 2009 at 02:17:06PM -0400, Skipper Seabold wrote:
> First before I get into the last few things that I can think of, sorry
> for all the questions.  If the next few steps don't work, I am open to
> switching Linux distributions and seeing if I have more luck because I
> am about at the end of my abilities (and time constraint).  I have
> seen that Debian-based distributions are usually better for Scipy and
> the extensions.  Is there a particular "flavor" that is popular for
> Scipy developers?

Stick with mainstream: use Debian or Ubuntu.

I use Ubuntu on most of my boxes, because I like the 6 months release
strategy. Debian stable is usually too old for me (although I do run one
of my server under it). I've also had good experiences with Debian
unstable, though I find it lack the polish of Ubuntu, and is very
slightly more of a moving target.

I should point out that some people of the community are doing hard work
to make Debian (and thus indirectly Ubuntu) an excellent scientific
computing platform.

Ga?l


From charlesr.harris at gmail.com  Sat Apr 11 18:05:56 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 11 Apr 2009 16:05:56 -0600
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
In-Reply-To: <20090411214543.GC22984@phare.normalesup.org>
References: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
	<1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>
	<e06186140904102137j4571ecbej1a8b18fdf0ee87f5@mail.gmail.com>
	<c048da1c0904111117v23415308t21965094de0f5535@mail.gmail.com>
	<20090411214543.GC22984@phare.normalesup.org>
Message-ID: <e06186140904111505v5c1e6510qdbdcde34bec67fc3@mail.gmail.com>

On Sat, Apr 11, 2009 at 3:45 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Sat, Apr 11, 2009 at 02:17:06PM -0400, Skipper Seabold wrote:
> > First before I get into the last few things that I can think of, sorry
> > for all the questions.  If the next few steps don't work, I am open to
> > switching Linux distributions and seeing if I have more luck because I
> > am about at the end of my abilities (and time constraint).  I have
> > seen that Debian-based distributions are usually better for Scipy and
> > the extensions.  Is there a particular "flavor" that is popular for
> > Scipy developers?
>
> Stick with mainstream: use Debian or Ubuntu.


> I use Ubuntu on most of my boxes, because I like the 6 months release
> strategy. Debian stable is usually too old for me (although I do run one
> of my server under it). I've also had good experiences with Debian
> unstable, though I find it lack the polish of Ubuntu, and is very
> slightly more of a moving target.
>

And I prefer Fedora because it isn't a pain to install on software raid1 and
doesn't require an hour or two to set up for software development. Suse was
my favorite years ago, I wonder what happened?

Ubuntu is easiest to upgrade, however, and the unfree codecs and video
drivers are easier to install.

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

From stefan at sun.ac.za  Sat Apr 11 23:12:17 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 12 Apr 2009 05:12:17 +0200
Subject: [SciPy-dev] regression test for reading compressed matlab
	streams
In-Reply-To: <6c17e6f50904110937g6b08550dma58b0a835a06c3f4@mail.gmail.com>
References: <6c17e6f50904110937g6b08550dma58b0a835a06c3f4@mail.gmail.com>
Message-ID: <9457e7c80904112012m4fb7c1b8g55bc330e88d7eca9@mail.gmail.com>

Thanks, Thouis.  Fixed in r5656.

Regards
St?fan

2009/4/11 Thouis (Ray) Jones <thouis at broad.mit.edu>:
> I just submitted a ticket and patch to add a regression test for
> reading compressed matlab streams via the mat_reader_factory.
> http://projects.scipy.org/scipy/ticket/918


From jtravs at gmail.com  Sun Apr 12 07:35:01 2009
From: jtravs at gmail.com (John Travers)
Date: Sun, 12 Apr 2009 12:35:01 +0100
Subject: [SciPy-dev] integrate.ode: dop, zvode accessibility
In-Reply-To: <1cd32cbb0904111152u2fab922etc9d3a50a2367d34f@mail.gmail.com>
References: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>
	<1cd32cbb0904111152u2fab922etc9d3a50a2367d34f@mail.gmail.com>
Message-ID: <3a1077e70904120435o1a24a650md097c9a8b38e6250@mail.gmail.com>

On Sat, Apr 11, 2009 at 7:52 PM,  <josef.pktd at gmail.com> wrote:
> On Sat, Apr 11, 2009 at 2:28 PM, ?<josef.pktd at gmail.com> wrote:
>> I was looking at the import structure in integrate.

The design of ode module has many problems. We discussed previously on
this list (a few months ago, and again, about 9 months before that)
about a possible re-design. There are a few good ideas left in the
archives. Maybe we should collect these points together and put them
on the developers wiki somewhere, for further discussion.

I was planning to have a stab at this and I think Pauli was
considering it too, but I haven't found the time yet and will not for
about another month or two.

Cheers,
John


From josef.pktd at gmail.com  Sun Apr 12 08:30:42 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 12 Apr 2009 08:30:42 -0400
Subject: [SciPy-dev] integrate.ode: dop, zvode accessibility
In-Reply-To: <3a1077e70904120435o1a24a650md097c9a8b38e6250@mail.gmail.com>
References: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>
	<1cd32cbb0904111152u2fab922etc9d3a50a2367d34f@mail.gmail.com>
	<3a1077e70904120435o1a24a650md097c9a8b38e6250@mail.gmail.com>
Message-ID: <1cd32cbb0904120530n1e89e557p5313fe89c20afdd9@mail.gmail.com>

On Sun, Apr 12, 2009 at 7:35 AM, John Travers <jtravs at gmail.com> wrote:
> On Sat, Apr 11, 2009 at 7:52 PM, ?<josef.pktd at gmail.com> wrote:
>> On Sat, Apr 11, 2009 at 2:28 PM, ?<josef.pktd at gmail.com> wrote:
>>> I was looking at the import structure in integrate.
>
> The design of ode module has many problems. We discussed previously on
> this list (a few months ago, and again, about 9 months before that)
> about a possible re-design. There are a few good ideas left in the
> archives. Maybe we should collect these points together and put them
> on the developers wiki somewhere, for further discussion.
>
> I was planning to have a stab at this and I think Pauli was
> considering it too, but I haven't found the time yet and will not for
> about another month or two.

Thanks,
 I'm still trying to figure out how the scipy sub-packages are
structured, and I was a bit surprised when I was looking for dopri5,
that I found mainly the fortran module, before finding the indirect
access through ode.

Josef


From general.mooney at googlemail.com  Sun Apr 12 09:58:42 2009
From: general.mooney at googlemail.com (=?ISO-8859-1?Q?Ciar=E1n_Mooney?=)
Date: Sun, 12 Apr 2009 14:58:42 +0100
Subject: [SciPy-dev] [Announcement] Europython 2009
Message-ID: <3e4e51a80904120658o735478c3xb6508e9e14ad27f1@mail.gmail.com>

Hi,


There has been a inkling of interest in a Scipy/Numpy tutorial on the
Europython 2009 lists. But we need someone to lead it! So even though
the deadline for papers has passed, they may still be open to an
offer.

If not, please come along anyway to mingle, meet and network with
other python-ista's.

The following is from the Europython Commitee.

======

On behalf of the EuroPython 2009 organisation it is my privilege and
honour to announce the 'Call for Participation' for EuroPython 2009!
EuroPython is the conference for the communities around Python,
including the Django, Zope and Plone communities.

This years conference will be held in Birmingham, UK from Monday 29th
June to Saturday 4th July 2009.

Talk & Themes

Do you have something you wish to present at EuroPython? Go to
http://www.europython.eu/talks/cfp/ for this years themes and
submissions criteria, the deadline is on 5th April 2009.

Other Talks, Activities and Events

Have you got something which does not fit the above? Visit
http://www.europython.eu/talks/

Help Us Out

We could use a hand - any contribution is welcome. Please take a look
at http://www.europython.eu/contact/ .

Sponsors

An unique opportunity to affiliate with the prestigious EuroPython
conference! http://www.europython.eu/sponsors/

Spread the Word

Improve our publicity by distributing this announcement in your corner
of the community, please coordinate this with the organizers:
http://www.europython.eu/contact/

General Information

For more information about the conference, please visit
http://www.europython.eu/

Looking forward to seeing you!

The EuroPython Team

===========

Regards,

Ciar?n


From pav at iki.fi  Sun Apr 12 11:34:01 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 12 Apr 2009 15:34:01 +0000 (UTC)
Subject: [SciPy-dev] integrate.ode: dop, zvode accessibility
References: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>
	<1cd32cbb0904111152u2fab922etc9d3a50a2367d34f@mail.gmail.com>
Message-ID: <grt1l9$u1p$2@ger.gmane.org>

Sat, 11 Apr 2009 14:52:50 -0400, josef.pktd wrote:
[clip]
> to clarify:
> They are accessible as integrators in ode and complex_ode but not
> directly. So the question is whether they are hidden away intentionally.

Yes, they're hidden away intentionally, since they can be used only via 
the 'ode' and 'complex_ode' classes. The shadowing of 'class ode' and 
ode.py is not good either, IMHO.

-- 
Pauli Virtanen



From pav at iki.fi  Sun Apr 12 11:50:29 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 12 Apr 2009 15:50:29 +0000 (UTC)
Subject: [SciPy-dev] integrate.ode: dop, zvode accessibility
References: <1cd32cbb0904111128k5be0398bo91d08a4c25bcb9fd@mail.gmail.com>
	<1cd32cbb0904111152u2fab922etc9d3a50a2367d34f@mail.gmail.com>
	<3a1077e70904120435o1a24a650md097c9a8b38e6250@mail.gmail.com>
Message-ID: <grt2k5$u1p$3@ger.gmane.org>

Sun, 12 Apr 2009 12:35:01 +0100, John Travers wrote:

> On Sat, Apr 11, 2009 at 7:52 PM,  <josef.pktd at gmail.com> wrote:
>> On Sat, Apr 11, 2009 at 2:28 PM, ?<josef.pktd at gmail.com> wrote:
>>> I was looking at the import structure in integrate.
> 
> The design of ode module has many problems. We discussed previously on
> this list (a few months ago, and again, about 9 months before that)
> about a possible re-design. There are a few good ideas left in the
> archives. Maybe we should collect these points together and put them on
> the developers wiki somewhere, for further discussion.
> 
> I was planning to have a stab at this and I think Pauli was considering
> it too, but I haven't found the time yet and will not for about another
> month or two.

I added a wiki page for drafting what we want here:

	http://projects.scipy.org/scipy/wiki/OdeintRedesign

and a related ticket. Maybe this is useful.

-- 
Pauli Virtanen



From jsseabold at gmail.com  Sun Apr 12 23:36:32 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Sun, 12 Apr 2009 23:36:32 -0400
Subject: [SciPy-dev] Scipy Compile and Testing Problem from SVN
In-Reply-To: <e06186140904111505v5c1e6510qdbdcde34bec67fc3@mail.gmail.com>
References: <c048da1c0904101842u4dcb42c4u730b6c924ef3fa08@mail.gmail.com>
	<1cd32cbb0904102021s683eb27fs38e87e7989b9123c@mail.gmail.com>
	<e06186140904102137j4571ecbej1a8b18fdf0ee87f5@mail.gmail.com>
	<c048da1c0904111117v23415308t21965094de0f5535@mail.gmail.com>
	<20090411214543.GC22984@phare.normalesup.org>
	<e06186140904111505v5c1e6510qdbdcde34bec67fc3@mail.gmail.com>
Message-ID: <c048da1c0904122036n3d7f3c8cx61af519499626b0@mail.gmail.com>

On Sat, Apr 11, 2009 at 6:05 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Sat, Apr 11, 2009 at 3:45 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>>
>> On Sat, Apr 11, 2009 at 02:17:06PM -0400, Skipper Seabold wrote:
>> > First before I get into the last few things that I can think of, sorry
>> > for all the questions. ?If the next few steps don't work, I am open to
>> > switching Linux distributions and seeing if I have more luck because I
>> > am about at the end of my abilities (and time constraint). ?I have
>> > seen that Debian-based distributions are usually better for Scipy and
>> > the extensions. ?Is there a particular "flavor" that is popular for
>> > Scipy developers?
>>
>> Stick with mainstream: use Debian or Ubuntu.
>>
>> I use Ubuntu on most of my boxes, because I like the 6 months release
>> strategy. Debian stable is usually too old for me (although I do run one
>> of my server under it). I've also had good experiences with Debian
>> unstable, though I find it lack the polish of Ubuntu, and is very
>> slightly more of a moving target.

Thanks for the suggestions.  I've got the development versions of both
numpy and scipy up and running on Kubuntu Jaunty 64-bit (I really like
where KDE 4.x is headed).  It didn't go completely without hiccups,
but it was pretty straightforward.

I receive the same test results as is found here
<http://mail.scipy.org/pipermail/scipy-dev/2009-March/011555.html> but
at least it's a start.

> And I prefer Fedora because it isn't a pain to install on software raid1 and
> doesn't require an hour or two to set up for software development. Suse was
> my favorite years ago, I wonder what happened?

Hope I'm not too off topic, but there are some good things going on
with openSUSE.  Yast is a pretty helpful tool in particular, but it
doesn't seem like they're too focused on scientific computing.  IIRC
from the forums, a few people had left over the years after problems
with LAPACK specifically.  Probably some people on here.  I should've
taken heed.

> Ubuntu is easiest to upgrade, however, and the unfree codecs and video
> drivers are easier to install.

I was pleasantly surprised at the handling of this.  The community
seems to be a little better organized as well.  I see why they say
it's the preferred route for new Linux users.

Skipper


From xavier.gnata at gmail.com  Mon Apr 13 13:38:04 2009
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Mon, 13 Apr 2009 19:38:04 +0200
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
Message-ID: <49E3787C.5040300@gmail.com>

Hi,

This bug is still present in 0.8.0.dev5656:

======================================================================
FAIL: test_pbdv (test_basic.TestCephes)                              
----------------------------------------------------------------------
Traceback (most recent call last):                                   
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 370, in
test_pbdv                                                                  
   
assert_equal(cephes.pbdv(1,0),(0.0,0.0))                                         

  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 182, in assert_equal
    assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg),
verbose)
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 189, in assert_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal:
item=1

 ACTUAL: 1.0
 DESIRED: 0.0

A bug free testsuite is a very important item to advertise scipy in a
industrial context.
Could someone help me to kill this old bug? (ubuntu 64bits).


Xavier


From jsalvati at u.washington.edu  Mon Apr 13 13:54:36 2009
From: jsalvati at u.washington.edu (John Salvatier)
Date: Mon, 13 Apr 2009 10:54:36 -0700
Subject: [SciPy-dev] Question including a boundary value problem solver
	in SciPy
Message-ID: <113e17f20904131054i58a08e49q2d50d2f97aa98e78@mail.gmail.com>

Sorry for my slow response to this, I had some trouble getting added to the
scipy-dev list.

I did not realize that SciPy did not depend on Fortran 90. It is too bad
that my wrapper cannot be included in the main distribution.

Could you tell me who I should talk to about creating a SciKit?

Also, I am interested in the wrapper you have made; could you point me to
your code or send it to me? Perhaps I can improve my own code by looking at
yours.

I am also aware of the other boundary value solver, and I think it *would*
be a good idea to have them both in a single SciKit. I will look into this
in the future.

Bests,
John Salvatier

> <jsalvati at u.washington.edu <http://mail.scipy.org/mailman/listinfo/scipy-dev>> wrote:
> >* Hello,
> *>*
> *>* I am not sure this is the right place to ask this question, but I have
> *>* wrapped a boundary value problem solver based on the Fortran code
> *>* BVP_SOLVER. The PyPi page is here, and I have a tutorial for it here.
> *
> scipy-dev. I have cross-posted this reply. Please respond to the
> scipy-dev thread.
>
> >*
> *>* I am interested in integrating this into SciPy, so I have two questions: 1)
> *>* Does this type of thing belong in SciPy? 2) if it is, what are the steps to
> *>* getting this included in into SciPy?
> *>*
> *
> Hi John,
>
> This would be a very welcome addition!
>
> I also made a wrapper for this code a few years back. Apart from the
> license issues, which it sounds like you are solving, the main problem
> with direct inclusion is that it is written in fortran 90, which scipy
> currently does not depend on.
>
> At the time I was told that making it a scikit would be the best
> option for inclusion, and I think that is still true. This allows
> scipy to still be independent of fortran 90 code. On the other hand,
> as gfortran is now getting more stable and reasonably fast maybe it is
> time to re-visit this issue.
>
> Given that over the past two years I haven't made any moves to
> actually make a scikit, then I guess you have more momentum to go
> ahead with this. Note that there is a different boundary bvalue
> problem solver available
> (http://www.elisanet.fi/ptvirtan/software/bvp/index.html), it would be
> nice if both were combined into a single scikit.
>
> Cheers,
> John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090413/a0f4121f/attachment.html>

From stefan at sun.ac.za  Mon Apr 13 14:17:10 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 13 Apr 2009 20:17:10 +0200
Subject: [SciPy-dev] Question including a boundary value problem solver
	in SciPy
In-Reply-To: <113e17f20904131054i58a08e49q2d50d2f97aa98e78@mail.gmail.com>
References: <113e17f20904131054i58a08e49q2d50d2f97aa98e78@mail.gmail.com>
Message-ID: <9457e7c80904131117u2c8ec110kdf3d3384e0394522@mail.gmail.com>

Hi John

2009/4/13 John Salvatier <jsalvati at u.washington.edu>:
> Could you tell me who I should talk to about creating a SciKit?

Any package that is named scikits.* on the Python Package Index is
listed on http://scikits.appspot.com.  You can take a look at the
example package,

http://scikits.appspot.com/example

You may host the package anywhere you like (e.g. github, bitbucket,
etc.), or we can give you access to scikits SVN, where most of the
other projects are currently located.  You may also want to register
on the scikits trac:

http://projects.scipy.org/scikits

Regards
St?fan


From pav at iki.fi  Mon Apr 13 17:17:19 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 13 Apr 2009 21:17:19 +0000 (UTC)
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
References: <49E3787C.5040300@gmail.com>
Message-ID: <gs0a4v$59s$6@ger.gmane.org>

Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
> This bug is still present in 0.8.0.dev5656:
[clip]
> A bug free testsuite is a very important item to advertise scipy in a
> industrial context. Could someone help me to kill this old bug? 
> (ubuntu 64bits).

If you want to help, the first step in fixing special.pbdv would be to 
write improved tests for it; just edit test_basic.py to add relevant 
tests, and do

	svn diff test_basic.py > test-special-pbdv.patch

and attach the patch to the corresponding Trac ticket:

	http://projects.scipy.org/scipy/ticket/803

Tests for checking the function values at a couple of special points and 
around "difficult points" (singularities, zeros) would be useful for us.

-- 
Pauli Virtanen



From xavier.gnata at gmail.com  Mon Apr 13 17:47:16 2009
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Mon, 13 Apr 2009 23:47:16 +0200
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
In-Reply-To: <gs0a4v$59s$6@ger.gmane.org>
References: <49E3787C.5040300@gmail.com> <gs0a4v$59s$6@ger.gmane.org>
Message-ID: <49E3B2E4.3010207@gmail.com>

Pauli Virtanen wrote:
> Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
>   
>> This bug is still present in 0.8.0.dev5656:
>>     
> [clip]
>   
>> A bug free testsuite is a very important item to advertise scipy in a
>> industrial context. Could someone help me to kill this old bug? 
>> (ubuntu 64bits).
>>     
>
> If you want to help, the first step in fixing special.pbdv would be to 
> write improved tests for it; just edit test_basic.py to add relevant 
> tests, and do
>
> 	svn diff test_basic.py > test-special-pbdv.patch
>
> and attach the patch to the corresponding Trac ticket:
>
> 	http://projects.scipy.org/scipy/ticket/803
>
> Tests for checking the function values at a couple of special points and 
> around "difficult points" (singularities, zeros) would be useful for us.
>
>   
Well it could be no problem but first I would like to get some feedback
on my comments on
http://projects.scipy.org/scipy/ticket/803
Special functions are tricky things...many slightly different ways to
define them...

Xavier



From pav at iki.fi  Mon Apr 13 18:57:00 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 13 Apr 2009 22:57:00 +0000 (UTC)
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
References: <49E3787C.5040300@gmail.com> <gs0a4v$59s$6@ger.gmane.org>
	<49E3B2E4.3010207@gmail.com>
Message-ID: <gs0fvs$59s$8@ger.gmane.org>

Mon, 13 Apr 2009 23:47:16 +0200, Xavier Gnata wrote:
[clip]
> Well it could be no problem but first I would like to get some feedback
> on my comments on
> http://projects.scipy.org/scipy/ticket/803 Special functions are tricky
> things...many slightly different ways to define them...

Yes, the test is wrong (fixed in r5657), and it appears the second output 
from pbdv has nothing to do with the gradient of Dv even though the 
docstring says otherwise.

Apparently, the Specfun Fortran code for PBDV is bogus or incorrectly 
documented.

-- 
Pauli Virtanen



From alan at ajackson.org  Mon Apr 13 18:48:43 2009
From: alan at ajackson.org (Alan Jackson)
Date: Mon, 13 Apr 2009 17:48:43 -0500
Subject: [SciPy-dev] Porting to windows 64
Message-ID: <20090413174843.43a94a5b@ajackson.org>

Behind the scenes of REvolution's 64-bit Windows port of R

http://blog.revolution-computing.com/2009/04/behind-the-scenes-64bit-r.html

-- 
-----------------------------------------------------------------------
| Alan K. Jackson            | To see a World in a Grain of Sand      |
| alan at ajackson.org          | And a Heaven in a Wild Flower,         |
| www.ajackson.org           | Hold Infinity in the palm of your hand |
| Houston, Texas             | And Eternity in an hour. - Blake       |
-----------------------------------------------------------------------


From pav at iki.fi  Mon Apr 13 19:30:37 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 13 Apr 2009 23:30:37 +0000 (UTC)
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
References: <49E3787C.5040300@gmail.com>
Message-ID: <gs0hut$59s$9@ger.gmane.org>

Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:

> Hi,
> 
> This bug is still present in 0.8.0.dev5656:
> 
> ======================================================================
> FAIL: test_pbdv (test_basic.TestCephes)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
test_basic.py",
> line 370, in
> test_pbdv
[clip]

Should be fixed in r5658. There was at least a likely off-by-one memory 
overflow issue in the PBDV wrappers.

Please test the most recent SVN version to see if it works now as 
expected.

-- 
Pauli Virtanen



From xavier.gnata at gmail.com  Mon Apr 13 19:54:37 2009
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Tue, 14 Apr 2009 01:54:37 +0200
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
In-Reply-To: <gs0hut$59s$9@ger.gmane.org>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
Message-ID: <49E3D0BD.30007@gmail.com>

Pauli Virtanen wrote:
> Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
>
>   
>> Hi,
>>
>> This bug is still present in 0.8.0.dev5656:
>>
>> ======================================================================
>> FAIL: test_pbdv (test_basic.TestCephes)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File
>> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
>>     
> test_basic.py",
>   
>> line 370, in
>> test_pbdv
>>     
> [clip]
>
> Should be fixed in r5658. There was at least a likely off-by-one memory 
> overflow issue in the PBDV wrappers.
>
> Please test the most recent SVN version to see if it works now as 
> expected.
>
>   

ok it is fixed. Thanks.

Xavier



From cournape at gmail.com  Tue Apr 14 01:22:25 2009
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 14 Apr 2009 14:22:25 +0900
Subject: [SciPy-dev] Numpy/Scipy GSOC project(s)
In-Reply-To: <73531abb0904081433l7295e181g9de0a350e64e7e5d@mail.gmail.com>
References: <73531abb0903300136k3cd1e9e2r23e749b0ec0695e0@mail.gmail.com>
	<49D0952E.2010202@ar.media.kyoto-u.ac.jp>
	<73531abb0903310936r7eaf2a8exaa587b4c129790c1@mail.gmail.com>
	<73531abb0903310942h414f42d0m2bc4efd5fed97a06@mail.gmail.com>
	<5b8d13220904012149h9dbead3p7e65f8e26454049f@mail.gmail.com>
	<73531abb0904081433l7295e181g9de0a350e64e7e5d@mail.gmail.com>
Message-ID: <5b8d13220904132222x7704c254g9a5c0f17f4545102@mail.gmail.com>

Hi Ross,

2009/4/9 ross smith <rjsm at umich.edu>:
> I've had a run of bad luck (burglary) and haven't been able to reply for any
> updates.

Sorry to hear that.

> I did submit a draft proposal for this project on time but it needs some
> work.? One coment from Josef was that sgnal.lti, would need some help with
> documentation and testing along with extending it for MIMO, with the caveat
> that this might be too much for a gsoc project. [1]? any other opinions on
> if this would be too tough?

I think it is harder than other tasks related to scipy.signal (it is a
rather major new feature, which requires designing new APIs). I have
updated the application with some comments which were previously only
private.

You mentioned that you have some experience with signal processing
(designing some max/msp plugins). Could you update your application
with your background in signal processing ? Being more precise about
the features you feel capable of improving may improve your proposal,

cheers,

David


From nmb at wartburg.edu  Tue Apr 14 10:08:22 2009
From: nmb at wartburg.edu (Neil Martinsen-Burrell)
Date: Tue, 14 Apr 2009 14:08:22 +0000 (UTC)
Subject: [SciPy-dev]
	=?utf-8?q?Question_including_a_boundary_value_problem?=
	=?utf-8?q?_solver=09in_SciPy?=
References: <113e17f20904131054i58a08e49q2d50d2f97aa98e78@mail.gmail.com>
Message-ID: <loom.20090414T140423-619@post.gmane.org>

John Salvatier <jsalvati <at> u.washington.edu> writes:


> Sorry for my slow response to this, I had some trouble getting added to the 
> scipy-dev list. I did not realize that SciPy did not depend on Fortran 90. It 
> is too bad that my wrapper cannot be included in the main distribution. Could 
> you tell me who I should talk to about creating a SciKit?Also, I am 
> interested in the wrapper you have made; could you point me to your code or 
> send it to me? Perhaps I can improve my own code by looking at yours. I am 
> also aware of the other boundary value solver, and I think it *would* be a 
> good idea to have them both in a single SciKit.

I think that a BVP scikit would be a wonderful addition.  Along those lines, I
have a question.  I'm looking for a BVP solver that could be wrapped in python
that handles non-separated (particularly periodic) boundary conditions.  I've
looked at the classic Netlib codes, as well as the (excellent F90) BVP_SOLVER
that you've wrapped, but as far as I can tell, they are only for separated BCs.
 Do you know of a freely available periodic BVP code?  (Matlab's bvp4c can
handle non-separated BCs, but it is certainly not free.)

-Neil




From rob.clewley at gmail.com  Tue Apr 14 13:31:48 2009
From: rob.clewley at gmail.com (Rob Clewley)
Date: Tue, 14 Apr 2009 13:31:48 -0400
Subject: [SciPy-dev] Question including a boundary value problem solver
	in SciPy
In-Reply-To: <loom.20090414T140423-619@post.gmane.org>
References: <113e17f20904131054i58a08e49q2d50d2f97aa98e78@mail.gmail.com>
	<loom.20090414T140423-619@post.gmane.org>
Message-ID: <a749952d0904141031i3cfa4bcm6cae000539086af4@mail.gmail.com>

> ?I'm looking for a BVP solver that could be wrapped in python
> that handles non-separated (particularly periodic) boundary conditions. ?I've
> looked at the classic Netlib codes, as well as the (excellent F90) BVP_SOLVER
> that you've wrapped, but as far as I can tell, they are only for separated BCs.
> ?Do you know of a freely available periodic BVP code? ?(Matlab's bvp4c can
> handle non-separated BCs, but it is certainly not free.)
>
> -Neil

I think AUTO's BVP solver allows for periodic boundary conditions (you
can read demos by looking at the package docs and website) but we
haven't wrapped this part of AUTO into python yet. If you want to help
do that it would be great - I don't have the time!

-Rob


From ondrej at certik.cz  Tue Apr 14 16:42:31 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 14 Apr 2009 13:42:31 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
Message-ID: <85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>

On Wed, Apr 8, 2009 at 4:04 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Wed, Apr 8, 2009 at 17:43, Ondrej Certik <ondrej at certik.cz> wrote:
>> so I guess scipy should be like a bare matlab and all toolboxes should
>> go to scikits?
>
> Not necessarily *bare* Matlab, but that's roughly my take. Personally,
> I don't feel a need to put everything numerical possible into scipy
> itself. That way lies madness, IMO. A single Python package just isn't
> the right technology to contain that much code.
>
> I see scipy as primarily providing the fundamentals. In addition, it
> also serves as a home for numerical code that would otherwise have no
> home. I see no benefit in pulling in existing projects that are
> thriving on their own. As for PDEs, specifically, I think the domain
> is rich enough that it can usefully live in its own package better
> than being put into scipy. While there may be some fundamentals that
> you can pull out that might make sense to live in scipy (some simple
> good-enough mesh generation as you suggest), you will inevitably need
> more options, more sophisticated mesh generation, more dependencies,
> etc., that fits the development life cycle of a PDE-dedicated package
> more than scipy.
>

So to conclude this thread, it seems to me that what Robert wrote
above is the mission statement for scipy:

------------
SciPy mission statement:

SciPy is providing the fundamentals for all scientific codes in
Python, in addition, it
also serves as a home for numerical code that would otherwise have no
home. Existing projects, that are thriving on their own (e.g. PDE
solvers) should stay as separate projects.
---------------------

> In other words, the important question isn't, "Can scipy do this?" but
> rather, "Can Python do this?".


So it's clear that besides scipy itself, there should be a all in one
solution, like EPD (commercial), Sage (GPL), or SPD (GPL, but in
principle if all the Sage scripts are rewritten, could be BSD) that I
am working on.

There needs to be something, that people can take and customize to
create their own all in one solutions, e.g. for PDE, or for biology,
for mathematics (that is Sage) or I don't know what.
Too bad I need to sleep some time, otherwise I'd be working on this
nonstop to make this happen.

Ondrej


From gael.varoquaux at normalesup.org  Tue Apr 14 16:56:06 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 14 Apr 2009 22:56:06 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
Message-ID: <20090414205606.GD30875@phare.normalesup.org>

On Tue, Apr 14, 2009 at 01:42:31PM -0700, Ondrej Certik wrote:
> There needs to be something, that people can take and customize to
> create their own all in one solutions, e.g. for PDE, or for biology,
> for mathematics (that is Sage) or I don't know what.
> Too bad I need to sleep some time, otherwise I'd be working on this
> nonstop to make this happen.

I am with you here (but not working on it :( ).

I didn't add anything to the discussion on PDE's, but all the time during
this discussion I had in mind the interface nightmare problem: I don't
care which PDE solver I use, if it has an interface I know. So we need a
package to implement a base interface, that I can depend on. The solver
behind this interface might not be performant, it is just there as a
back. Scipy does seem a natural slot for such code.

Ga?l


From robert.kern at gmail.com  Tue Apr 14 17:43:46 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 14 Apr 2009 16:43:46 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <20090414205606.GD30875@phare.normalesup.org>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com> 
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com> 
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com> 
	<20090414205606.GD30875@phare.normalesup.org>
Message-ID: <3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>

On Tue, Apr 14, 2009 at 15:56, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Apr 14, 2009 at 01:42:31PM -0700, Ondrej Certik wrote:
>> There needs to be something, that people can take and customize to
>> create their own all in one solutions, e.g. for PDE, or for biology,
>> for mathematics (that is Sage) or I don't know what.
>> Too bad I need to sleep some time, otherwise I'd be working on this
>> nonstop to make this happen.
>
> I am with you here (but not working on it :( ).
>
> I didn't add anything to the discussion on PDE's, but all the time during
> this discussion I had in mind the interface nightmare problem: I don't
> care which PDE solver I use, if it has an interface I know. So we need a
> package to implement a base interface, that I can depend on. The solver
> behind this interface might not be performant, it is just there as a
> back. Scipy does seem a natural slot for such code.

I conjecture, though, that the interface is the critical
differentiator (ahem, no pun intended) between implementations.

-- 
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 gael.varoquaux at normalesup.org  Tue Apr 14 17:47:06 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 14 Apr 2009 23:47:06 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<20090414205606.GD30875@phare.normalesup.org>
	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>
Message-ID: <20090414214706.GF30875@phare.normalesup.org>

On Tue, Apr 14, 2009 at 04:43:46PM -0500, Robert Kern wrote:
> I conjecture, though, that the interface is the critical
> differentiator (ahem, no pun intended) between implementations.

Then let's have a good fight, and get over it :).

Ga?l

PS: same thing for interpolation, and optimisation :P


From robert.kern at gmail.com  Tue Apr 14 17:59:39 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 14 Apr 2009 16:59:39 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <20090414214706.GF30875@phare.normalesup.org>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com> 
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com> 
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com> 
	<20090414205606.GD30875@phare.normalesup.org>
	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com> 
	<20090414214706.GF30875@phare.normalesup.org>
Message-ID: <3d375d730904141459l712f9fa9lfad10f09199cdc7f@mail.gmail.com>

On Tue, Apr 14, 2009 at 16:47, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Apr 14, 2009 at 04:43:46PM -0500, Robert Kern wrote:
>> I conjecture, though, that the interface is the critical
>> differentiator (ahem, no pun intended) between implementations.
>
> Then let's have a good fight, and get over it :).
>
> Ga?l
>
> PS: same thing for interpolation, and optimisation :P

I suspect the problems are much worse for PDEs than either of those.
Just the different mesh representations alone make it difficult to
provide a uniform implementation.

-- 
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 strawman at astraw.com  Tue Apr 14 18:39:18 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 14 Apr 2009 15:39:18 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
Message-ID: <49E51096.4020106@astraw.com>

Ondrej Certik wrote:

> So it's clear that besides scipy itself, there should be a all in one
> solution, like EPD (commercial), Sage (GPL), or SPD (GPL, but in
> principle if all the Sage scripts are rewritten, could be BSD) that I
> am working on.
> 
> There needs to be something, that people can take and customize to
> create their own all in one solutions, e.g. for PDE, or for biology,
> for mathematics (that is Sage) or I don't know what.

I call that Debian/Ubuntu. Package management is one thing that Debian
got really right. I don't really see the value in re-inventing Debian
package management. Why not just use it?

> Too bad I need to sleep some time, otherwise I'd be working on this
> nonstop to make this happen.

I notice you already are working pretty close to nonstop on packaging
for Debian, so go a bit easier on yourself. :)


From robert.kern at gmail.com  Tue Apr 14 18:43:19 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 14 Apr 2009 17:43:19 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E51096.4020106@astraw.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com> 
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com> 
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com> 
	<49E51096.4020106@astraw.com>
Message-ID: <3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>

On Tue, Apr 14, 2009 at 17:39, Andrew Straw <strawman at astraw.com> wrote:
> Ondrej Certik wrote:
>
>> So it's clear that besides scipy itself, there should be a all in one
>> solution, like EPD (commercial), Sage (GPL), or SPD (GPL, but in
>> principle if all the Sage scripts are rewritten, could be BSD) that I
>> am working on.
>>
>> There needs to be something, that people can take and customize to
>> create their own all in one solutions, e.g. for PDE, or for biology,
>> for mathematics (that is Sage) or I don't know what.
>
> I call that Debian/Ubuntu. Package management is one thing that Debian
> got really right. I don't really see the value in re-inventing Debian
> package management. Why not just use it?

If you can really restrict your deployments just to a single
distribution of a single OS, great. Many of us are not in that
position.

-- 
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 gael.varoquaux at normalesup.org  Tue Apr 14 18:43:46 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 15 Apr 2009 00:43:46 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E51096.4020106@astraw.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
Message-ID: <20090414224346.GH30875@phare.normalesup.org>

On Tue, Apr 14, 2009 at 03:39:18PM -0700, Andrew Straw wrote:
> I call that Debian/Ubuntu. Package management is one thing that Debian
> got really right. I don't really see the value in re-inventing Debian
> package management. Why not just use it?

Because you have to be root on the box for this. In most labs, you may be
root one a few boxes, but rarely on the cluster. In addition, at many
workplaces, you are not root on your own box (and anyhow, they rule out
Debian, usually).

Ga?l, a Debian/Ubuntu fan, too.


From strawman at astraw.com  Tue Apr 14 19:37:45 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 14 Apr 2009 16:37:45 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
Message-ID: <49E51E49.90208@astraw.com>

Robert Kern wrote:
> On Tue, Apr 14, 2009 at 17:39, Andrew Straw <strawman at astraw.com> wrote:
>> Ondrej Certik wrote:
>>
>>> So it's clear that besides scipy itself, there should be a all in one
>>> solution, like EPD (commercial), Sage (GPL), or SPD (GPL, but in
>>> principle if all the Sage scripts are rewritten, could be BSD) that I
>>> am working on.
>>>
>>> There needs to be something, that people can take and customize to
>>> create their own all in one solutions, e.g. for PDE, or for biology,
>>> for mathematics (that is Sage) or I don't know what.
>> I call that Debian/Ubuntu. Package management is one thing that Debian
>> got really right. I don't really see the value in re-inventing Debian
>> package management. Why not just use it?
> 
> If you can really restrict your deployments just to a single
> distribution of a single OS, great. Many of us are not in that
> position.

Well, fink ports the Debian package management to Mac OS X. Does
something equivalent exist for Windows? The actual Debian file formats
are pretty simple, so it seems like it should be do-able.

The no root issue is another setback for my suggestion. I guess porting
the Debian package management isn't going to help there...

Maybe what is needed is an entirely unprivileged-user Debian-inspired
distribution and package management system that doesn't bother
installing the low-level system stuff (e.g. the kernel, X11/Windows
GUI/Mac OS X GUI) but will keep a copy of everything from libpng, to
cairo, to ATLAS, to numpy/scipy/etc in the user's area. This sounds like
a generally useful thing, and not one that is specific to Python.
Perhaps such a project could actually take off.

-Andrew


From robert.kern at gmail.com  Tue Apr 14 19:40:01 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 14 Apr 2009 18:40:01 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E51E49.90208@astraw.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com> 
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com> 
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com> 
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com> 
	<49E51E49.90208@astraw.com>
Message-ID: <3d375d730904141640k19dbb901q1577df1778c05cd1@mail.gmail.com>

On Tue, Apr 14, 2009 at 18:37, Andrew Straw <strawman at astraw.com> wrote:
> Robert Kern wrote:
>> On Tue, Apr 14, 2009 at 17:39, Andrew Straw <strawman at astraw.com> wrote:
>>> Ondrej Certik wrote:
>>>
>>>> So it's clear that besides scipy itself, there should be a all in one
>>>> solution, like EPD (commercial), Sage (GPL), or SPD (GPL, but in
>>>> principle if all the Sage scripts are rewritten, could be BSD) that I
>>>> am working on.
>>>>
>>>> There needs to be something, that people can take and customize to
>>>> create their own all in one solutions, e.g. for PDE, or for biology,
>>>> for mathematics (that is Sage) or I don't know what.
>>> I call that Debian/Ubuntu. Package management is one thing that Debian
>>> got really right. I don't really see the value in re-inventing Debian
>>> package management. Why not just use it?
>>
>> If you can really restrict your deployments just to a single
>> distribution of a single OS, great. Many of us are not in that
>> position.
>
> Well, fink ports the Debian package management to Mac OS X.

Not really, no.

> Does
> something equivalent exist for Windows?

No.

> The actual Debian file formats
> are pretty simple, so it seems like it should be do-able.

You would think, wouldn't you?

> The no root issue is another setback for my suggestion. I guess porting
> the Debian package management isn't going to help there...
>
> Maybe what is needed is an entirely unprivileged-user Debian-inspired
> distribution and package management system that doesn't bother
> installing the low-level system stuff (e.g. the kernel, X11/Windows
> GUI/Mac OS X GUI) but will keep a copy of everything from libpng, to
> cairo, to ATLAS, to numpy/scipy/etc in the user's area. This sounds like
> a generally useful thing, and not one that is specific to Python.
> Perhaps such a project could actually take off.

There have been many abortive attempts. None have actually caught on.

-- 
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 cournape at gmail.com  Tue Apr 14 20:00:14 2009
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 15 Apr 2009 09:00:14 +0900
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
Message-ID: <5b8d13220904141700n228309b3q280b0abe88d5fbc0@mail.gmail.com>

On Wed, Apr 15, 2009 at 5:42 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>
>
> So it's clear that besides scipy itself, there should be a all in one
> solution, like EPD (commercial), Sage (GPL), or SPD (GPL, but in
> principle if all the Sage scripts are rewritten, could be BSD) that I
> am working on.

I am not sure it is that clear. If you take one of the most successful
open source software for numerical computation, R, they have a totally
opposite solution: CRAN. They don't integrate anything themselves, but
you have ~2000 packages for extremely specialized tools. It is easier
for R than for us, because they can do whatever they want to make it
happen, whereas we have to play well with other tools, since we are
python.

cheers,

David


From cournape at gmail.com  Tue Apr 14 20:23:44 2009
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 15 Apr 2009 09:23:44 +0900
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E51E49.90208@astraw.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
	<49E51E49.90208@astraw.com>
Message-ID: <5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>

On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:

>
> Well, fink ports the Debian package management to Mac OS X. Does
> something equivalent exist for Windows? The actual Debian file formats
> are pretty simple, so it seems like it should be do-able.

What makes debian such a well integrated system is not so much the
scripts - after all, rpm .spec files, debian files, port (BSd system)
files are not that different. What matters is how polish the actual
packages are. That's already difficult to do for one platform. That
becomes very very difficult for many packages. The whole setuptools
thing is a fiasco IMHO partly because it ignores this problem and
gives the illusion it is easy (installing is easy, because it is just
installing files, uninstalling is easy because it is just removing
files - that's like saying programming is easy because it just moves
bytes in memory). When I worked in a company doing proprietary
software for windows/mac, you had one guy whose sole job is to make
sure everything installs properly. That's very time consuming, because
every little detail matters - and a mistake in the installer is a deal
breaker and costs a lot to the company.

> Maybe what is needed is an entirely unprivileged-user Debian-inspired
> distribution and package management system that doesn't bother
> installing the low-level system stuff (e.g. the kernel, X11/Windows
> GUI/Mac OS X GUI) but will keep a copy of everything from libpng, to
> cairo, to ATLAS, to numpy/scipy/etc in the user's area. This sounds like
> a generally useful thing, and not one that is specific to Python.
> Perhaps such a project could actually take off.

The idea is too engrained in unix I think, if only "philosophically".
Technically, having a system with many dependencies would not work
very well on windows I think. Usually, on windows, you just ship
everything you need in your package (many windows softwares bundle
their own C runtime for example), and a software is a snapshot of a
set of softwares which works and has been tested together. Then, every
software has its own update mechanism if it is big enough (acrobat
reader, vmware, etc...).

David


From ondrej at certik.cz  Tue Apr 14 20:50:23 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 14 Apr 2009 17:50:23 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<20090414205606.GD30875@phare.normalesup.org>
	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>
Message-ID: <85b5c3130904141750u366d130dva1fe2c68fbecdce4@mail.gmail.com>

On Tue, Apr 14, 2009 at 2:43 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Tue, Apr 14, 2009 at 15:56, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Tue, Apr 14, 2009 at 01:42:31PM -0700, Ondrej Certik wrote:
>>> There needs to be something, that people can take and customize to
>>> create their own all in one solutions, e.g. for PDE, or for biology,
>>> for mathematics (that is Sage) or I don't know what.
>>> Too bad I need to sleep some time, otherwise I'd be working on this
>>> nonstop to make this happen.
>>
>> I am with you here (but not working on it :( ).
>>
>> I didn't add anything to the discussion on PDE's, but all the time during
>> this discussion I had in mind the interface nightmare problem: I don't
>> care which PDE solver I use, if it has an interface I know. So we need a
>> package to implement a base interface, that I can depend on. The solver
>> behind this interface might not be performant, it is just there as a
>> back. Scipy does seem a natural slot for such code.
>
> I conjecture, though, that the interface is the critical
> differentiator (ahem, no pun intended) between implementations.

So if you all seem to agree to that scipy mission, do you think it
could be put on the scipy front page? :) Is there anything I can do to
make this happen?



As to the distribution thing --- as long as it's your own box, or you
have the root rights, Debian/Ubuntu is the best (for me). But if you
are on Mac, or a cluster (often my case), other computer, lab, or
windows, you are stuck. There were attempts to create a source
distribution and all of them utterly failed, e.g. see this thread I
started on sage-devel not so long ago:

http://groups.google.com/group/sage-devel/browse_thread/thread/a8d89440bdff814b/

The only way forward is to use something that has already pulled off,
that has a large support across all the architectures (*now*, not in
couple years, that's very important), that has a large user community,
etc. E.g. Sage. Then take it and customize it. Imho that is the only
chance, instead of starting something new.

Hopefully soon Debian Developer,
Ondrej


From robert.kern at gmail.com  Tue Apr 14 21:11:04 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 14 Apr 2009 20:11:04 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904141750u366d130dva1fe2c68fbecdce4@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com> 
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com> 
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com> 
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com> 
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com> 
	<20090414205606.GD30875@phare.normalesup.org>
	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com> 
	<85b5c3130904141750u366d130dva1fe2c68fbecdce4@mail.gmail.com>
Message-ID: <3d375d730904141811t34f7a687r3ddcc4b41c96e33@mail.gmail.com>

On Tue, Apr 14, 2009 at 19:50, Ondrej Certik <ondrej at certik.cz> wrote:
> On Tue, Apr 14, 2009 at 2:43 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Tue, Apr 14, 2009 at 15:56, Gael Varoquaux
>> <gael.varoquaux at normalesup.org> wrote:
>>> On Tue, Apr 14, 2009 at 01:42:31PM -0700, Ondrej Certik wrote:
>>>> There needs to be something, that people can take and customize to
>>>> create their own all in one solutions, e.g. for PDE, or for biology,
>>>> for mathematics (that is Sage) or I don't know what.
>>>> Too bad I need to sleep some time, otherwise I'd be working on this
>>>> nonstop to make this happen.
>>>
>>> I am with you here (but not working on it :( ).
>>>
>>> I didn't add anything to the discussion on PDE's, but all the time during
>>> this discussion I had in mind the interface nightmare problem: I don't
>>> care which PDE solver I use, if it has an interface I know. So we need a
>>> package to implement a base interface, that I can depend on. The solver
>>> behind this interface might not be performant, it is just there as a
>>> back. Scipy does seem a natural slot for such code.
>>
>> I conjecture, though, that the interface is the critical
>> differentiator (ahem, no pun intended) between implementations.
>
> So if you all seem to agree to that scipy mission, do you think it
> could be put on the scipy front page? :) Is there anything I can do to
> make this happen?

I don't think it's worded well as a mission statement although I,
naturally, agree with the content.

-- 
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  Wed Apr 15 00:56:31 2009
From: jh at physics.ucf.edu (Joe Harrington)
Date: Wed, 15 Apr 2009 00:56:31 -0400
Subject: [SciPy-dev] JOB: write numpy docs
In-Reply-To: <wl8vdprq8n4.fsf@glup.physics.ucf.edu> (message from Joe
	Harrington on Mon, 30 Mar 2009 12:26:39 -0400)
References: <wl8vdprq8n4.fsf@glup.physics.ucf.edu>
Message-ID: <wl8eivubjls.fsf@glup.physics.ucf.edu>

So far I have no takers for the numpy doc job (below), and the lack of
activity on docs.scipy.org indicates nobody new is preparing an
application.  This job is open (as a subcontract) to international
applicants.  It could be part-time, if a suitable full-time person is
not available.  It could be a volunteer job, if you're gainfully
employed and would prefer it that way.  If you have substantial free
time this summer and you want to have full docs for numpy, please
contact me.

Thanks,

--jh--

Date: Mon, 30 Mar 2009 12:26:39 -0400
To: Scipy Developers <scipy-dev at scipy.org>,
    Scipy Users <scipy-user at scipy.org>,
    Numpy Discussion <numpy-discussion at scipy.org>
Subject: JOB: write numpy docs
From: Joe Harrington <jh at physics.ucf.edu>
CC: jh at physics.ucf.edu
Reply-to: jh at physics.ucf.edu

Last year's Doc Marathon got us off to a great start on documenting
NumPy!  But, there's still much work to be done, and SciPy after that.
It's time to gear up for doing it again.

Critical to last year's success was Stefan van der Walt's committed
time, but he will be unable to play that role this year.  So, I am
looking to hire someone to write NumPy docs and help coordinate the
doc project and its volunteers.  The job includes working with me, the
doc team, doc volunteers, and developers to:

write and review a lot of docs, mainly those that others don't want to write
help define milestones
organize campaigns and volunteer teams to meet them
research the NumPy and SciPy source codes to help plan:
  the eventual SciPy documentation
  the writing of a good User Manual
work with the packaging team to meet their release deadlines
perform other duties as assigned

I am seeking someone to work full time if possible, and at least half
time, from mid-April (or soon thereafter) through at least the
(northern) summer.  Candidates must be experienced NumPy and SciPy
programmers; familiarity under the hood is a strong plus.  They must
also demonstrate their ability to produce excellent docs on the
docs.SciPy.org wiki.  Having contributed at a high level to an
open-source community, especially to SciPy, is a big plus.  Ability to
take direction, work with and lead a team, and to work for extended
periods without direct supervision on a list of assigned tasks are all
critical.  The applicant must be able to function well in a Linux
environment; familiarity with multiple platforms is a plus.

Please reply directly to me by email only.  Include the following (PDF
or ASCII formats strongly preferred):

CV

Statement of interest, qualifications per requirements above,
availability, and wage expectations.

Contact info for at least 3 professional references.

Links to doc wiki pages for which you wrote the initial draft
Links to doc wiki pages started by others to which you contributed
  significantly (edited, reviewed, proofed)

The position is open until filled; candidates with complete
applications by April 15 will receive full consideration.  This is an
open posting.  Candidates who have not written any pages on the doc
wiki yet have several weeks in which to do so.

Pay will be commensurate with experience (up to a point).  Relocation
is not necessary.  Candidates will need to provide their own computer
and internet access.  The University of Central Florida is an equal
opportunity, equal access, affirmative action employer.

--jh--
Prof. Joseph Harrington
Department of Physics
MAP 414
4000 Central Florida Blvd.
University of Central Florida
Orlando, FL 32816-2385
(407) 823-3416 voice
(407) 823-5112 fax
(407) 823-2325 physics office
jh at physics.ucf.edu



From gael.varoquaux at normalesup.org  Wed Apr 15 01:06:30 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 15 Apr 2009 07:06:30 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <5b8d13220904141700n228309b3q280b0abe88d5fbc0@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<5b8d13220904141700n228309b3q280b0abe88d5fbc0@mail.gmail.com>
Message-ID: <20090415050630.GA28627@phare.normalesup.org>

On Wed, Apr 15, 2009 at 09:00:14AM +0900, David Cournapeau wrote:
> I am not sure it is that clear. If you take one of the most successful
> open source software for numerical computation, R, they have a totally
> opposite solution: CRAN. They don't integrate anything themselves, but
> you have ~2000 packages for extremely specialized tools. It is easier
> for R than for us, because they can do whatever they want to make it
> happen, whereas we have to play well with other tools, since we are
> python.

I am curious: how reliable is RCRAN, with regards to complex compiled
packages. For instance, do they ever run in the gfortran/g77 problems?

Maybe once numpy provides a suitable build environment (by exposing its C
API to packages) and with some improvement of distutils/setuptools, we
can go part way there.

Ga?l


From gael.varoquaux at normalesup.org  Wed Apr 15 01:11:58 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 15 Apr 2009 07:11:58 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
References: <49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
	<49E51E49.90208@astraw.com>
	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
Message-ID: <20090415051158.GB28627@phare.normalesup.org>

On Wed, Apr 15, 2009 at 09:23:44AM +0900, David Cournapeau wrote:
> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:


> > Well, fink ports the Debian package management to Mac OS X. Does
> > something equivalent exist for Windows? The actual Debian file formats
> > are pretty simple, so it seems like it should be do-able.

> What makes debian such a well integrated system is not so much the
> scripts - after all, rpm .spec files, debian files, port (BSd system)
> files are not that different. What matters is how polish the actual
> packages are. That's already difficult to do for one platform. That
> becomes very very difficult for many packages. The whole setuptools
> thing is a fiasco IMHO partly because it ignores this problem and
> gives the illusion it is easy (installing is easy, because it is just
> installing files, uninstalling is easy because it is just removing
> files - that's like saying programming is easy because it just moves
> bytes in memory). 

Right, a debian package by itself does not mean anything. What is
important is that, at an instant t, the debian archive strives to be a
self-consistent set of packages, that all build and run together, with
known relationship.

I think that one thing that contributes a lot to the quality of debian
packages (real ones, not fink, I don't know for fink) is that, under
Debian and Ubuntu, they are built is isolated environments. That way no
build or installation side effects creep in. Making a Debian package for
your soft is a great way to make sure that it really builds, 100% of the
time, because if it doesn't, one of the different build bots will find it
for you.

That culture is totally absent from Python packaging.

Ga?l


From gael.varoquaux at normalesup.org  Wed Apr 15 01:16:10 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 15 Apr 2009 07:16:10 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904141811t34f7a687r3ddcc4b41c96e33@mail.gmail.com>
References: <49D9C9F9.6010109@aero.iitb.ac.in>
	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<20090414205606.GD30875@phare.normalesup.org>
	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>
	<85b5c3130904141750u366d130dva1fe2c68fbecdce4@mail.gmail.com>
	<3d375d730904141811t34f7a687r3ddcc4b41c96e33@mail.gmail.com>
Message-ID: <20090415051610.GC28627@phare.normalesup.org>

On Tue, Apr 14, 2009 at 08:11:04PM -0500, Robert Kern wrote:
> I don't think it's worded well as a mission statement although I,
> naturally, agree with the content.

It still could go on the scipy.org frontpage, no? Ondrej, this is a wiki,
go ahead and edit it, if we don't agree with your changes, we'll mention
it. Try to make it look nice (very important). The front page tends to
get over cluttered, I believe you should try and rearrange the content in
order not to really make it any longer than it is.

Ga?l


From robert.kern at gmail.com  Wed Apr 15 01:21:37 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 15 Apr 2009 00:21:37 -0500
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <20090415051610.GC28627@phare.normalesup.org>
References: <49D9C9F9.6010109@aero.iitb.ac.in>
	<49DA5061.9060002@lpta.in2p3.fr> 
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com> 
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com> 
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com> 
	<20090414205606.GD30875@phare.normalesup.org>
	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com> 
	<85b5c3130904141750u366d130dva1fe2c68fbecdce4@mail.gmail.com> 
	<3d375d730904141811t34f7a687r3ddcc4b41c96e33@mail.gmail.com> 
	<20090415051610.GC28627@phare.normalesup.org>
Message-ID: <3d375d730904142221id36066fvf48fb3524d84342a@mail.gmail.com>

On Wed, Apr 15, 2009 at 00:16, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Apr 14, 2009 at 08:11:04PM -0500, Robert Kern wrote:
>> I don't think it's worded well as a mission statement although I,
>> naturally, agree with the content.
>
> It still could go on the scipy.org frontpage, no? Ondrej, this is a wiki,
> go ahead and edit it, if we don't agree with your changes, we'll mention
> it. Try to make it look nice (very important). The front page tends to
> get over cluttered, I believe you should try and rearrange the content in
> order not to really make it any longer than it is.

I believe the front page is restricted.

-- 
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 cimrman3 at ntc.zcu.cz  Wed Apr 15 03:51:56 2009
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Wed, 15 Apr 2009 09:51:56 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <3d375d730904141459l712f9fa9lfad10f09199cdc7f@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<20090414205606.GD30875@phare.normalesup.org>	<3d375d730904141443r1842f1a8kfa32924ce4943dd8@mail.gmail.com>
	<20090414214706.GF30875@phare.normalesup.org>
	<3d375d730904141459l712f9fa9lfad10f09199cdc7f@mail.gmail.com>
Message-ID: <49E5921C.8080306@ntc.zcu.cz>

Robert Kern wrote:
> On Tue, Apr 14, 2009 at 16:47, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Tue, Apr 14, 2009 at 04:43:46PM -0500, Robert Kern wrote:
>>> I conjecture, though, that the interface is the critical
>>> differentiator (ahem, no pun intended) between implementations.
>> Then let's have a good fight, and get over it :).
>>
>> Ga?l
>>
>> PS: same thing for interpolation, and optimisation :P
> 
> I suspect the problems are much worse for PDEs than either of those.
> Just the different mesh representations alone make it difficult to
> provide a uniform implementation.

True enough. In SfePy, we describe problems (PDEs) to solve by using 
regular Python files, which is nice and easy, but the interface, i.e. 
all that can be in those files and understood by the solver, is rather 
tightly coupled with what the solver can do - its implementation. The 
topic of PDE solvers is really very broad, even if we restrict "just" to 
the finite element method, and there is not a silver bullet interface 
that would work for everybody.

Just my 2 cents, as a guy that writes finite element codes for 
not-so-small time.

r.




From Nicolas.Rougier at loria.fr  Wed Apr 15 04:39:59 2009
From: Nicolas.Rougier at loria.fr (Nicolas Rougier)
Date: Wed, 15 Apr 2009 10:39:59 +0200
Subject: [SciPy-dev] glipy, OpenGL IPython terminal with numpy support
Message-ID: <1239784799.4307.6.camel@sulfur.loria.fr>



Hello,

I've made a Python/IPython terminal using pyglet with embedded support
for numpy arrays (1D or 2D). It uses OpenGL and is pretty fast.

It does not aim at replacing matplotlib or mayavi mlab module but is
rahter aimed at quick experimentations or debugging.

I've setup a launchpad glipy project at:
https://launchpad.net/glipy

as well as a rudimentary homepage:
http://webloria.loria.fr/~rougier/glipy/

for those who want to test it. It is still an early beta version and may
be plenty of bugs...


Nicolas



From dagss at student.matnat.uio.no  Wed Apr 15 04:58:41 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Wed, 15 Apr 2009 10:58:41 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>	<49E51096.4020106@astraw.com>	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>	<49E51E49.90208@astraw.com>
	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
Message-ID: <49E5A1C1.3090901@student.matnat.uio.no>

David Cournapeau wrote:
> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
> 
>> Well, fink ports the Debian package management to Mac OS X. Does
>> something equivalent exist for Windows? The actual Debian file formats
>> are pretty simple, so it seems like it should be do-able.
> 
> What makes debian such a well integrated system is not so much the
> scripts - after all, rpm .spec files, debian files, port (BSd system)
> files are not that different. What matters is how polish the actual
> packages are. That's already difficult to do for one platform. That

+1

The reason Sage installs works is because Michael Abshoff works as 
release manager. Making sure, e.g., that one software package isn't 
upgraded until the rest of the packages can handle the upgrade.

Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be 
something that works at one point in time, but then requires fulltime 
supervision to keep it working, and really not much better than 
setuptools foir the reasons David mentions.

The reason a system as complex as Sage actually works is not the 
technology (what, untar and run a script...) but the release schedules, 
comprehensive regression testing, Michael Abshoff etc.


-- 
Dag Sverre


From dagss at student.matnat.uio.no  Wed Apr 15 05:09:08 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Wed, 15 Apr 2009 11:09:08 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E5A1C1.3090901@student.matnat.uio.no>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<49D9C9F9.6010109@aero.iitb.ac.in>	<80b160a0904060858n57e534bcx57247995636b6b72@mail.gmail.com>	<49DA5061.9060002@lpta.in2p3.fr>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>	<49E51096.4020106@astraw.com>	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>	<49E51E49.90208@astraw.com>	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
	<49E5A1C1.3090901@student.matnat.uio.no>
Message-ID: <49E5A434.6080204@student.matnat.uio.no>

Dag Sverre Seljebotn wrote:
> David Cournapeau wrote:
>> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
>>
>>> Well, fink ports the Debian package management to Mac OS X. Does
>>> something equivalent exist for Windows? The actual Debian file formats
>>> are pretty simple, so it seems like it should be do-able.
>> What makes debian such a well integrated system is not so much the
>> scripts - after all, rpm .spec files, debian files, port (BSd system)
>> files are not that different. What matters is how polish the actual
>> packages are. That's already difficult to do for one platform. That
> 
> +1
> 
> The reason Sage installs works is because Michael Abshoff works as 
> release manager. Making sure, e.g., that one software package isn't 
> upgraded until the rest of the packages can handle the upgrade.
> 
> Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be 
> something that works at one point in time, but then requires fulltime 
> supervision to keep it working, and really not much better than 
> setuptools foir the reasons David mentions.

The major point I'm trying to make here is that if you have Sage version 
  x.y.z, that autoatically implies Python version a.b, NumPy version c.d 
and SciPy version e.f; all tested by someone else to fit together.

Unless the same will be the case for SPD, it just won't work as it must. 
And if it is not keyed 1:1 to Sage releases, there's going to be much 
work duplication.

The package system is not the problem; distribution maintainance is.

-- 
Dag Sverre


From ondrej at certik.cz  Wed Apr 15 04:54:55 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 15 Apr 2009 01:54:55 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E5A1C1.3090901@student.matnat.uio.no>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<49DA5061.9060002@lpta.in2p3.fr>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
	<49E51E49.90208@astraw.com>
	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
	<49E5A1C1.3090901@student.matnat.uio.no>
Message-ID: <85b5c3130904150154h4510c8f5mc321c3ec580eb09c@mail.gmail.com>

On Wed, Apr 15, 2009 at 1:58 AM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> wrote:
> David Cournapeau wrote:
>> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
>>
>>> Well, fink ports the Debian package management to Mac OS X. Does
>>> something equivalent exist for Windows? The actual Debian file formats
>>> are pretty simple, so it seems like it should be do-able.
>>
>> What makes debian such a well integrated system is not so much the
>> scripts - after all, rpm .spec files, debian files, port (BSd system)
>> files are not that different. What matters is how polish the actual
>> packages are. That's already difficult to do for one platform. That
>
> +1
>
> The reason Sage installs works is because Michael Abshoff works as
> release manager. Making sure, e.g., that one software package isn't
> upgraded until the rest of the packages can handle the upgrade.
>
> Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be
> something that works at one point in time, but then requires fulltime
> supervision to keep it working, and really not much better than
> setuptools foir the reasons David mentions.
>
> The reason a system as complex as Sage actually works is not the
> technology (what, untar and run a script...) but the release schedules,
> comprehensive regression testing, Michael Abshoff etc.

Yes, my plan is to get it tied to Sage releases and work as close as
possible with Sage guys.

Ondrej


From ondrej at certik.cz  Wed Apr 15 05:04:36 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 15 Apr 2009 02:04:36 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E5A434.6080204@student.matnat.uio.no>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>
	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
	<49E51E49.90208@astraw.com>
	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
	<49E5A1C1.3090901@student.matnat.uio.no>
	<49E5A434.6080204@student.matnat.uio.no>
Message-ID: <85b5c3130904150204l594c30a6x568c7dc1d62ad2b3@mail.gmail.com>

On Wed, Apr 15, 2009 at 2:09 AM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> wrote:
> Dag Sverre Seljebotn wrote:
>> David Cournapeau wrote:
>>> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
>>>
>>>> Well, fink ports the Debian package management to Mac OS X. Does
>>>> something equivalent exist for Windows? The actual Debian file formats
>>>> are pretty simple, so it seems like it should be do-able.
>>> What makes debian such a well integrated system is not so much the
>>> scripts - after all, rpm .spec files, debian files, port (BSd system)
>>> files are not that different. What matters is how polish the actual
>>> packages are. That's already difficult to do for one platform. That
>>
>> +1
>>
>> The reason Sage installs works is because Michael Abshoff works as
>> release manager. Making sure, e.g., that one software package isn't
>> upgraded until the rest of the packages can handle the upgrade.
>>
>> Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be
>> something that works at one point in time, but then requires fulltime
>> supervision to keep it working, and really not much better than
>> setuptools foir the reasons David mentions.
>
> The major point I'm trying to make here is that if you have Sage version
> ?x.y.z, that autoatically implies Python version a.b, NumPy version c.d
> and SciPy version e.f; all tested by someone else to fit together.
>
> Unless the same will be the case for SPD, it just won't work as it must.
> And if it is not keyed 1:1 to Sage releases, there's going to be much
> work duplication.
>
> The package system is not the problem; distribution maintainance is.

Yep, that's why I chose Sage, because in my experience Sage is by far
the most tested and robust opensource source distribution.

Besides that, both William and Michael are interested in helping me
out, for example William and Mike Hansen just spent an evening
disentangling the Sage notebook, so that we can use it in SPD and they
can use it in the windows port:

http://trac.sagemath.org/sage_trac/ticket/5789

while in the scipy community, unfortunately, I can still see many
doubts if this effort is really needed/worthy, etc. So I first need to
deliver some results, then hopefully more people will join. I can't do
this myself alone, so I chose Sage.

Ondrej


From dagss at student.matnat.uio.no  Wed Apr 15 06:20:07 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Wed, 15 Apr 2009 12:20:07 +0200
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904150204l594c30a6x568c7dc1d62ad2b3@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>	<49E51096.4020106@astraw.com>	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>	<49E51E49.90208@astraw.com>	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>	<49E5A1C1.3090901@student.matnat.uio.no>	<49E5A434.6080204@student.matnat.uio.no>
	<85b5c3130904150204l594c30a6x568c7dc1d62ad2b3@mail.gmail.com>
Message-ID: <49E5B4D7.4060609@student.matnat.uio.no>

Ondrej Certik wrote:
> On Wed, Apr 15, 2009 at 2:09 AM, Dag Sverre Seljebotn
> <dagss at student.matnat.uio.no> wrote:
>> Dag Sverre Seljebotn wrote:
>>> David Cournapeau wrote:
>>>> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
>>>>
>>>>> Well, fink ports the Debian package management to Mac OS X. Does
>>>>> something equivalent exist for Windows? The actual Debian file formats
>>>>> are pretty simple, so it seems like it should be do-able.
>>>> What makes debian such a well integrated system is not so much the
>>>> scripts - after all, rpm .spec files, debian files, port (BSd system)
>>>> files are not that different. What matters is how polish the actual
>>>> packages are. That's already difficult to do for one platform. That
>>> +1
>>>
>>> The reason Sage installs works is because Michael Abshoff works as
>>> release manager. Making sure, e.g., that one software package isn't
>>> upgraded until the rest of the packages can handle the upgrade.
>>>
>>> Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be
>>> something that works at one point in time, but then requires fulltime
>>> supervision to keep it working, and really not much better than
>>> setuptools foir the reasons David mentions.
>> The major point I'm trying to make here is that if you have Sage version
>>  x.y.z, that autoatically implies Python version a.b, NumPy version c.d
>> and SciPy version e.f; all tested by someone else to fit together.
>>
>> Unless the same will be the case for SPD, it just won't work as it must.
>> And if it is not keyed 1:1 to Sage releases, there's going to be much
>> work duplication.
>>
>> The package system is not the problem; distribution maintainance is.
> 
> Yep, that's why I chose Sage, because in my experience Sage is by far
> the most tested and robust opensource source distribution.
> 
> Besides that, both William and Michael are interested in helping me
> out, for example William and Mike Hansen just spent an evening
> disentangling the Sage notebook, so that we can use it in SPD and they
> can use it in the windows port:
> 
> http://trac.sagemath.org/sage_trac/ticket/5789
> 
> while in the scipy community, unfortunately, I can still see many
> doubts if this effort is really needed/worthy, etc. So I first need to
> deliver some results, then hopefully more people will join. I can't do
> this myself alone, so I chose Sage.

Well, I'm not really part of the SciPy community, but now that I 
understand the project better I'm very positive. Especially since it 
seems it will bring nice cleanups to the Sage codebase. Good luck with it!

(Myself I will probably just continue to use the gigabyte of disk space 
for a full Sage (what is 1 gig anyway in this day and age?), but I 
understand that others have other needs -- especially Windows support).

-- 
Dag Sverre


From ondrej at certik.cz  Wed Apr 15 06:13:25 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 15 Apr 2009 03:13:25 -0700
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <49E5B4D7.4060609@student.matnat.uio.no>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>
	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>
	<49E51096.4020106@astraw.com>
	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>
	<49E51E49.90208@astraw.com>
	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>
	<49E5A1C1.3090901@student.matnat.uio.no>
	<49E5A434.6080204@student.matnat.uio.no>
	<85b5c3130904150204l594c30a6x568c7dc1d62ad2b3@mail.gmail.com>
	<49E5B4D7.4060609@student.matnat.uio.no>
Message-ID: <85b5c3130904150313o2b9ce600mdd4700e8e85bb39d@mail.gmail.com>

On Wed, Apr 15, 2009 at 3:20 AM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> wrote:
> Ondrej Certik wrote:
>> On Wed, Apr 15, 2009 at 2:09 AM, Dag Sverre Seljebotn
>> <dagss at student.matnat.uio.no> wrote:
>>> Dag Sverre Seljebotn wrote:
>>>> David Cournapeau wrote:
>>>>> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
>>>>>
>>>>>> Well, fink ports the Debian package management to Mac OS X. Does
>>>>>> something equivalent exist for Windows? The actual Debian file formats
>>>>>> are pretty simple, so it seems like it should be do-able.
>>>>> What makes debian such a well integrated system is not so much the
>>>>> scripts - after all, rpm .spec files, debian files, port (BSd system)
>>>>> files are not that different. What matters is how polish the actual
>>>>> packages are. That's already difficult to do for one platform. That
>>>> +1
>>>>
>>>> The reason Sage installs works is because Michael Abshoff works as
>>>> release manager. Making sure, e.g., that one software package isn't
>>>> upgraded until the rest of the packages can handle the upgrade.
>>>>
>>>> Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be
>>>> something that works at one point in time, but then requires fulltime
>>>> supervision to keep it working, and really not much better than
>>>> setuptools foir the reasons David mentions.
>>> The major point I'm trying to make here is that if you have Sage version
>>> ?x.y.z, that autoatically implies Python version a.b, NumPy version c.d
>>> and SciPy version e.f; all tested by someone else to fit together.
>>>
>>> Unless the same will be the case for SPD, it just won't work as it must.
>>> And if it is not keyed 1:1 to Sage releases, there's going to be much
>>> work duplication.
>>>
>>> The package system is not the problem; distribution maintainance is.
>>
>> Yep, that's why I chose Sage, because in my experience Sage is by far
>> the most tested and robust opensource source distribution.
>>
>> Besides that, both William and Michael are interested in helping me
>> out, for example William and Mike Hansen just spent an evening
>> disentangling the Sage notebook, so that we can use it in SPD and they
>> can use it in the windows port:
>>
>> http://trac.sagemath.org/sage_trac/ticket/5789
>>
>> while in the scipy community, unfortunately, I can still see many
>> doubts if this effort is really needed/worthy, etc. So I first need to
>> deliver some results, then hopefully more people will join. I can't do
>> this myself alone, so I chose Sage.
>
> Well, I'm not really part of the SciPy community, but now that I
> understand the project better I'm very positive. Especially since it
> seems it will bring nice cleanups to the Sage codebase. Good luck with it!
>
> (Myself I will probably just continue to use the gigabyte of disk space
> for a full Sage (what is 1 gig anyway in this day and age?), but I
> understand that others have other needs -- especially Windows support).

It's not only about 1 gig --- first it takes long time to download for
me, it takes about 30 min to unpack on my slow laptop, but that could
be overcome -- a big problem is that Sage doesn't build on our cluster
(some problems in some math packages, that I don't need), that's a
showstopper. SPD does build there.

Plus I want to create custom all in one solutions for our code, e.g.
for PDE, so the result will be much more than 1 gig after including
all the custom code (e.g. all solvers, etc.).

Ondrej


From jh at physics.ucf.edu  Wed Apr 15 09:49:48 2009
From: jh at physics.ucf.edu (Joe Harrington)
Date: Wed, 15 Apr 2009 09:49:48 -0400
Subject: [SciPy-dev] glipy, OpenGL IPython terminal with numpy support
In-Reply-To: <mailman.12404.1239789887.2878.scipy-dev@scipy.org>
	(scipy-dev-request@scipy.org)
References: <mailman.12404.1239789887.2878.scipy-dev@scipy.org>
Message-ID: <wl8ab6iauwz.fsf@glup.physics.ucf.edu>

Nicolas Rougier <Nicolas.Rougier at loria.fr> wrote:

> I've made a Python/IPython terminal using pyglet with embedded support
> for numpy arrays (1D or 2D). It uses OpenGL and is pretty fast.
> 
> It does not aim at replacing matplotlib or mayavi mlab module but is
> rahter aimed at quick experimentations or debugging.
> 
> I've setup a launchpad glipy project at:
> https://launchpad.net/glipy
> 
> as well as a rudimentary homepage:
> http://webloria.loria.fr/~rougier/glipy/
> 
> for those who want to test it. It is still an early beta version and may
> be plenty of bugs...
> 
> 
> Nicolas

Nicolas, this is awesome, a perfect teaching tool!  I'd like to use it
in my class.  Will it be stable in time for Fall classes?

Some thoughts:

Would it be possible to (optionally) detach the graphics from the
text, so that they're in separate windows and you just see the current
figure?

How about using (optionally) an external display program like DS9,
which has great features for interactively exploring the data in a
floating 2D array (scale contrast, brightness, and displayed data
range with the mouse; change colormaps; blink image sets; panel
images; annotate images; etc?).  This package is used widely in the
astronomy community.  Basically, what you're doing would automate the
repetitious act of sending every line's result to DS9 manually, and
provide basic capability for compositing images before display.

--jh--


From flyeng4 at gmail.com  Wed Apr 15 12:58:49 2009
From: flyeng4 at gmail.com (William Purcell)
Date: Wed, 15 Apr 2009 11:58:49 -0500
Subject: [SciPy-dev] Edit rights - Numpy doc editor
Message-ID: <6edf24ba0904150958v1b7fa310if1569428ebcfd41a@mail.gmail.com>

Would someone enable my edit rights for the Numpy documentation editor?

username -- flyeng4

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090415/f2dcb334/attachment.html>

From gael.varoquaux at normalesup.org  Wed Apr 15 13:02:15 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 15 Apr 2009 19:02:15 +0200
Subject: [SciPy-dev] Edit rights - Numpy doc editor
In-Reply-To: <6edf24ba0904150958v1b7fa310if1569428ebcfd41a@mail.gmail.com>
References: <6edf24ba0904150958v1b7fa310if1569428ebcfd41a@mail.gmail.com>
Message-ID: <20090415170215.GC29230@phare.normalesup.org>

On Wed, Apr 15, 2009 at 11:58:49AM -0500, William Purcell wrote:
>    Would someone enable my edit rights for the Numpy documentation editor?

>    username -- flyeng4

Done.

Ga?l


From xavier.gnata at gmail.com  Wed Apr 15 16:13:26 2009
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Wed, 15 Apr 2009 22:13:26 +0200
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
In-Reply-To: <gs0hut$59s$9@ger.gmane.org>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
Message-ID: <49E63FE6.2010901@gmail.com>

Pauli Virtanen wrote:
> Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
>
>   
>> Hi,
>>
>> This bug is still present in 0.8.0.dev5656:
>>
>> ======================================================================
>> FAIL: test_pbdv (test_basic.TestCephes)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File
>> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
>>     
> test_basic.py",
>   
>> line 370, in
>> test_pbdv
>>     
> [clip]
>
> Should be fixed in r5658. There was at least a likely off-by-one memory 
> overflow issue in the PBDV wrappers.
>
> Please test the most recent SVN version to see if it works now as 
> expected.
>
>   
'0.8.0.dev5661' and there is still a bug:
======================================================================
FAIL: test_pbdv (test_basic.TestCephes)                              
----------------------------------------------------------------------
Traceback (most recent call last):                                   
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 370, in
test_pbdv                                                                  
   
assert_equal(cephes.pbdv(1,0),(0.0,0.0))                                         

  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 182, in assert_equal
    assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg),
verbose)
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 189, in assert_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal:
item=1

 ACTUAL: 1.0
 DESIRED: 0.0

BWT, is there a way to compile scipy/numpy in debug mode and to run it
under valgrind?

Xavier


From pav at iki.fi  Wed Apr 15 16:35:32 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 15 Apr 2009 20:35:32 +0000 (UTC)
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com>
Message-ID: <gs5gej$qlp$3@ger.gmane.org>

Wed, 15 Apr 2009 22:13:26 +0200, Xavier Gnata wrote:
[clip]
> '0.8.0.dev5661' and there is still a bug:
> ======================================================================
> FAIL: test_pbdv (test_basic.TestCephes)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
test_basic.py",
> line 370, in
> test_pbdv
>    
> assert_equal(cephes.pbdv(1,0),(0.0,0.0))

You have a stale install or something similar, that line is not there any 
more in r5661.

[clip]
> BWT, is there a way to compile scipy/numpy in debug mode and to run it
> under valgrind?

Yes,

	python2.5 setup.py build --debug

	valgrind python2.5 -c 'import scipy; scipy.test()'

-- 
Pauli Virtanen



From xavier.gnata at gmail.com  Wed Apr 15 17:31:39 2009
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Wed, 15 Apr 2009 23:31:39 +0200
Subject: [SciPy-dev] 0.8.0.dev5656 test_pbdv bug
In-Reply-To: <gs5gej$qlp$3@ger.gmane.org>
References: <49E3787C.5040300@gmail.com>
	<gs0hut$59s$9@ger.gmane.org>	<49E63FE6.2010901@gmail.com>
	<gs5gej$qlp$3@ger.gmane.org>
Message-ID: <49E6523B.2040201@gmail.com>

Pauli Virtanen wrote:
> Wed, 15 Apr 2009 22:13:26 +0200, Xavier Gnata wrote:
> [clip]
>   
>> '0.8.0.dev5661' and there is still a bug:
>> ======================================================================
>> FAIL: test_pbdv (test_basic.TestCephes)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File
>> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
>>     
> test_basic.py",
>   
>> line 370, in
>> test_pbdv
>>    
>> assert_equal(cephes.pbdv(1,0),(0.0,0.0))
>>     
>
> You have a stale install or something similar, that line is not there any 
> more in r5661.
>   
Well I'm do not understand this point
Looking at
http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py
I can read :

def test_pbdv(self):
        assert_equal(cephes.pbdv(1,0),(0.0,0.0)

This website claims I'm looking at


    Revision 5661: /trunk/scipy/special/tests


I'm must be missing something...sorry for the noise....

> [clip]
>   
>> BWT, is there a way to compile scipy/numpy in debug mode and to run it
>> under valgrind?
>>     
>
> Yes,
>
> 	python2.5 setup.py build --debug
>
> 	valgrind python2.5 -c 'import scipy; scipy.test()'
>
>   

ok thanks.

Xavier



From gilles.rochefort at gmail.com  Wed Apr 15 18:43:39 2009
From: gilles.rochefort at gmail.com (Gilles Rochefort)
Date: Thu, 16 Apr 2009 00:43:39 +0200
Subject: [SciPy-dev] Patching fmin_l_bfgs_b in scipy.optimize
In-Reply-To: <9457e7c80901060058j2f79bd8ax8abf85641a00865b@mail.gmail.com>
References: <49484F0E.4000409@gmail.com> <49485775.9010506@creativetrax.com>	
	<4948598C.7050000@gmail.com>
	<9457e7c80901060058j2f79bd8ax8abf85641a00865b@mail.gmail.com>
Message-ID: <49E6631B.8000501@gmail.com>


First, I apology not to did it sooner, but as one said,  it is never too 
late ;-)

So, I finally issued a ticket with a patch file generated from current 
svn revision r5661 ...

http://projects.scipy.org/scipy/ticket/923

Gilles.

> Hi Gilles
>
> If your patch hasn't yet been applied, please file a ticket on the
> developer page
>
> http://projects.scipy.org/scipy/scipy
>
> so that we don't forget to attend to this issue.
>
> Cheers
> St?fan
>
> 2008/12/17 Gilles Rochefort <gilles.rochefort at gmail.com>:
>   
>> Thanks for the advice,
>> here is my new patch !
>>
>> Regards,
>> Gilles.
>>
>> jason-sage at creativetrax.com a ?crit :
>>
>> Gilles Rochefort wrote:
>>
>>
>> Hi,
>>
>> I had some troubles getting a stable version of fmin_l_bfgs_b. I got a
>> segmentation fault
>> as soon as I turned a different value than -1 to iprint argument.
>>     

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: scipy-optimize-lbfgsb-r5661.patch
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090416/9d647587/attachment.ksh>

From pav at iki.fi  Wed Apr 15 19:06:22 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 15 Apr 2009 23:06:22 +0000 (UTC)
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com>
Message-ID: <gs5p9e$n48$3@ger.gmane.org>


Hi all,

Commit r5661 apparently reverted some previous commits: compare

	http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5660
	http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5661

looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read
"cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that

	http://projects.scipy.org/scipy/changeset/5661

does not show that this change was made. It seems like bzr-svn did something
clever...


Moreover,

	svn diff -r 5660:5661 test_basic.py

says

	svn: Unable to find repository location for 'test_basic.py' in revision 5660

which is unexpected.


The Git repository indicates that something like this occurred:

       5655 5656 5657 5658 5659 5660
	o----o----o----o----o----o----o 5661
         \___________________________/

So, the revision 5661 is based on 5655. Now, bzr-svn has done something
and silently reverted the changesets 5656-5660 so that the reversion
does not appear in the commit 5661. (Surprisingly, git-svn *recognized* this
as a merge!) The full diff appears to be

	$ git diff --stat 746e23..svn/trunk
	INSTALL.txt                                       |  222 ++++++++++++++-------
	scipy/io/matlab/tests/data/test_skip_variable.mat |  Bin 20225 -> 0 bytes
	scipy/io/matlab/tests/test_mio.py                 |   31 +---
	scipy/special/specfun_wrappers.c                  |    6 +-
	scipy/special/tests/test_basic.py                 |   31 +---
	scipy/stats/distributions.py                      |    2 +-

So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at
the commit message for r5661 more closely, it says ". (copied from trunk)",
and indeed "svn log ." indicates that r5661 is based on r5660.

Does someone understand SVN enough to know what happened and how
to revert it, if needed?

My guess would be

	svn cp http://svn.scipy.org/svn/scipy/trunk at 5660 http://svn.scipy.org/svn/scipy/trunk

    ***

Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote:
[clip]
> Well I'm do not understand this point Looking at
> http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I
> can read :
> 
> def test_pbdv(self):
>         assert_equal(cephes.pbdv(1,0),(0.0,0.0)
> 
> This website claims I'm looking at
> 
> 
>     Revision 5661: /trunk/scipy/special/tests
> 
> I'm must be missing something...sorry for the noise....

Good catch, you're completely right! Something strange is going on.
I only checked it via looking at the commits in

	http://projects.scipy.org/scipy/timeline

and as you can see, none of the commits after 5657 actually reverts the 
change, so I assumed it was still there...

-- 
Pauli Virtanen



From josef.pktd at gmail.com  Wed Apr 15 19:30:05 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 15 Apr 2009 19:30:05 -0400
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <gs5p9e$n48$3@ger.gmane.org>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
Message-ID: <1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>

On Wed, Apr 15, 2009 at 7:06 PM, Pauli Virtanen <pav at iki.fi> wrote:
>
> Hi all,
>
> Commit r5661 apparently reverted some previous commits: compare
>
> ? ? ? ?http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5660
> ? ? ? ?http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5661
>
> looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read
> "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that
>
> ? ? ? ?http://projects.scipy.org/scipy/changeset/5661
>
> does not show that this change was made. It seems like bzr-svn did something
> clever...
>
>
> Moreover,
>
> ? ? ? ?svn diff -r 5660:5661 test_basic.py
>
> says
>
> ? ? ? ?svn: Unable to find repository location for 'test_basic.py' in revision 5660
>
> which is unexpected.
>
>
> The Git repository indicates that something like this occurred:
>
> ? ? ? 5655 5656 5657 5658 5659 5660
> ? ? ? ?o----o----o----o----o----o----o 5661
> ? ? ? ? \___________________________/
>
> So, the revision 5661 is based on 5655. Now, bzr-svn has done something
> and silently reverted the changesets 5656-5660 so that the reversion
> does not appear in the commit 5661. (Surprisingly, git-svn *recognized* this
> as a merge!) The full diff appears to be
>
> ? ? ? ?$ git diff --stat 746e23..svn/trunk
> ? ? ? ?INSTALL.txt ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ?222 ++++++++++++++-------
> ? ? ? ?scipy/io/matlab/tests/data/test_skip_variable.mat | ?Bin 20225 -> 0 bytes
> ? ? ? ?scipy/io/matlab/tests/test_mio.py ? ? ? ? ? ? ? ? | ? 31 +---
> ? ? ? ?scipy/special/specfun_wrappers.c ? ? ? ? ? ? ? ? ?| ? ?6 +-
> ? ? ? ?scipy/special/tests/test_basic.py ? ? ? ? ? ? ? ? | ? 31 +---
> ? ? ? ?scipy/stats/distributions.py ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
>
> So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at
> the commit message for r5661 more closely, it says ". (copied from trunk)",
> and indeed "svn log ." indicates that r5661 is based on r5660.
>
> Does someone understand SVN enough to know what happened and how
> to revert it, if needed?
>
> My guess would be
>
> ? ? ? ?svn cp http://svn.scipy.org/svn/scipy/trunk at 5660 http://svn.scipy.org/svn/scipy/trunk
>
> ? ?***
>
> Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote:
> [clip]
>> Well I'm do not understand this point Looking at
>> http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I
>> can read :
>>
>> def test_pbdv(self):
>> ? ? ? ? assert_equal(cephes.pbdv(1,0),(0.0,0.0)
>>
>> This website claims I'm looking at
>>
>>
>> ? ? Revision 5661: /trunk/scipy/special/tests
>>
>> I'm must be missing something...sorry for the noise....
>
> Good catch, you're completely right! Something strange is going on.
> I only checked it via looking at the commits in
>
> ? ? ? ?http://projects.scipy.org/scipy/timeline
>
> and as you can see, none of the commits after 5657 actually reverts the
> change, so I assumed it was still there...
>
> --
> Pauli Virtanen
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


I think that's my fault, but I haven't figured out how to revert this.

I tried to use bzr-svn but something looked strange, but I thought it
is only the large commit message.

Can you undo whatever happened in
http://projects.scipy.org/scipy/changeset/5661, and I won't try this
anymore if it messes up the repository and not just the commit
message.

Sorry,

Josef


From charlesr.harris at gmail.com  Wed Apr 15 20:25:35 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 15 Apr 2009 18:25:35 -0600
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
Message-ID: <e06186140904151725h62c194b0sd098dffce16e3f39@mail.gmail.com>

On Wed, Apr 15, 2009 at 5:30 PM, <josef.pktd at gmail.com> wrote:

> On Wed, Apr 15, 2009 at 7:06 PM, Pauli Virtanen <pav at iki.fi> wrote:
> >
> > Hi all,
> >
> > Commit r5661 apparently reverted some previous commits: compare
> >
> >
> http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5660
> >
> http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5661
> >
> > looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read
> > "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that
> >
> >        http://projects.scipy.org/scipy/changeset/5661
> >
> > does not show that this change was made. It seems like bzr-svn did
> something
> > clever...
> >
> >
> > Moreover,
> >
> >        svn diff -r 5660:5661 test_basic.py
> >
> > says
> >
> >        svn: Unable to find repository location for 'test_basic.py' in
> revision 5660
> >
> > which is unexpected.
> >
> >
> > The Git repository indicates that something like this occurred:
> >
> >       5655 5656 5657 5658 5659 5660
> >        o----o----o----o----o----o----o 5661
> >         \___________________________/
> >
> > So, the revision 5661 is based on 5655. Now, bzr-svn has done something
> > and silently reverted the changesets 5656-5660 so that the reversion
> > does not appear in the commit 5661. (Surprisingly, git-svn *recognized*
> this
> > as a merge!) The full diff appears to be
> >
> >        $ git diff --stat 746e23..svn/trunk
> >        INSTALL.txt                                       |  222
> ++++++++++++++-------
> >        scipy/io/matlab/tests/data/test_skip_variable.mat |  Bin 20225 ->
> 0 bytes
> >        scipy/io/matlab/tests/test_mio.py                 |   31 +---
> >        scipy/special/specfun_wrappers.c                  |    6 +-
> >        scipy/special/tests/test_basic.py                 |   31 +---
> >        scipy/stats/distributions.py                      |    2 +-
> >
> > So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at
> > the commit message for r5661 more closely, it says ". (copied from
> trunk)",
> > and indeed "svn log ." indicates that r5661 is based on r5660.
> >
> > Does someone understand SVN enough to know what happened and how
> > to revert it, if needed?
> >
> > My guess would be
> >
> >        svn cp http://svn.scipy.org/svn/scipy/trunk at 5660
> http://svn.scipy.org/svn/scipy/trunk
> >
> >    ***
> >
> > Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote:
> > [clip]
> >> Well I'm do not understand this point Looking at
> >> http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.pyI
> >> can read :
> >>
> >> def test_pbdv(self):
> >>         assert_equal(cephes.pbdv(1,0),(0.0,0.0)
> >>
> >> This website claims I'm looking at
> >>
> >>
> >>     Revision 5661: /trunk/scipy/special/tests
> >>
> >> I'm must be missing something...sorry for the noise....
> >
> > Good catch, you're completely right! Something strange is going on.
> > I only checked it via looking at the commits in
> >
> >        http://projects.scipy.org/scipy/timeline
> >
> > and as you can see, none of the commits after 5657 actually reverts the
> > change, so I assumed it was still there...
> >
> > --
> > Pauli Virtanen
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
>
>
> I think that's my fault, but I haven't figured out how to revert this.
>
> I tried to use bzr-svn but something looked strange, but I thought it
> is only the large commit message.
>
> Can you undo whatever happened in
> http://projects.scipy.org/scipy/changeset/5661, and I won't try this
> anymore if it messes up the repository and not just the commit
> message.
>

I found reverting the central svn repository to be a total PITA. If someone
still has the correct versions of the files the easiest thing to do is just
commit them.

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

From josef.pktd at gmail.com  Wed Apr 15 21:19:44 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 15 Apr 2009 21:19:44 -0400
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
Message-ID: <1cd32cbb0904151819y65452e2r957489d26d8269c0@mail.gmail.com>

On Wed, Apr 15, 2009 at 7:30 PM,  <josef.pktd at gmail.com> wrote:
> On Wed, Apr 15, 2009 at 7:06 PM, Pauli Virtanen <pav at iki.fi> wrote:
>>
>> Hi all,
>>
>> Commit r5661 apparently reverted some previous commits: compare
>>
>> ? ? ? ?http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5660
>> ? ? ? ?http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic.py?rev=5661
>>
>> looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read
>> "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that
>>
>> ? ? ? ?http://projects.scipy.org/scipy/changeset/5661
>>
>> does not show that this change was made. It seems like bzr-svn did something
>> clever...
>>
>>
>> Moreover,
>>
>> ? ? ? ?svn diff -r 5660:5661 test_basic.py
>>
>> says
>>
>> ? ? ? ?svn: Unable to find repository location for 'test_basic.py' in revision 5660
>>
>> which is unexpected.
>>
>>
>> The Git repository indicates that something like this occurred:
>>
>> ? ? ? 5655 5656 5657 5658 5659 5660
>> ? ? ? ?o----o----o----o----o----o----o 5661
>> ? ? ? ? \___________________________/
>>
>> So, the revision 5661 is based on 5655. Now, bzr-svn has done something
>> and silently reverted the changesets 5656-5660 so that the reversion
>> does not appear in the commit 5661. (Surprisingly, git-svn *recognized* this
>> as a merge!) The full diff appears to be
>>
>> ? ? ? ?$ git diff --stat 746e23..svn/trunk
>> ? ? ? ?INSTALL.txt ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ?222 ++++++++++++++-------
>> ? ? ? ?scipy/io/matlab/tests/data/test_skip_variable.mat | ?Bin 20225 -> 0 bytes
>> ? ? ? ?scipy/io/matlab/tests/test_mio.py ? ? ? ? ? ? ? ? | ? 31 +---
>> ? ? ? ?scipy/special/specfun_wrappers.c ? ? ? ? ? ? ? ? ?| ? ?6 +-
>> ? ? ? ?scipy/special/tests/test_basic.py ? ? ? ? ? ? ? ? | ? 31 +---
>> ? ? ? ?scipy/stats/distributions.py ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
>>
>> So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at
>> the commit message for r5661 more closely, it says ". (copied from trunk)",
>> and indeed "svn log ." indicates that r5661 is based on r5660.
>>
>> Does someone understand SVN enough to know what happened and how
>> to revert it, if needed?
>>
>> My guess would be
>>
>> ? ? ? ?svn cp http://svn.scipy.org/svn/scipy/trunk at 5660 http://svn.scipy.org/svn/scipy/trunk
>>
>> ? ?***
>>
>> Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote:
>> [clip]
>>> Well I'm do not understand this point Looking at
>>> http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I
>>> can read :
>>>
>>> def test_pbdv(self):
>>> ? ? ? ? assert_equal(cephes.pbdv(1,0),(0.0,0.0)
>>>
>>> This website claims I'm looking at
>>>
>>>
>>> ? ? Revision 5661: /trunk/scipy/special/tests
>>>
>>> I'm must be missing something...sorry for the noise....
>>
>> Good catch, you're completely right! Something strange is going on.
>> I only checked it via looking at the commits in
>>
>> ? ? ? ?http://projects.scipy.org/scipy/timeline
>>
>> and as you can see, none of the commits after 5657 actually reverts the
>> change, so I assumed it was still there...
>>
>> --
>> Pauli Virtanen
>>
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
> I think that's my fault, but I haven't figured out how to revert this.
>
> I tried to use bzr-svn but something looked strange, but I thought it
> is only the large commit message.
>
> Can you undo whatever happened in
> http://projects.scipy.org/scipy/changeset/5661, and I won't try this
> anymore if it messes up the repository and not just the commit
> message.
>
> Sorry,
>
> Josef
>

I figured out what I did wrong. It is all my fault for over-riding a
bzr warning.

The short version:
I forced a branch/checkout based on svn r5655 together with a new
change (revision 5661) back into the svn repository.

my setup:
C:/Josef/eclipsegworkspace/scipy-trunk-new/
is a checkout branch, but didn't realize that if I push anything on
this branch, it gets by default immediately committed to the svn
repository also.
Now, I know that when I pushed my changes this checkout was at  svn r5655

C:\Josef\eclipsegworkspace\scipy-branch
is a regular branch in which I am working in, this was also at   svn r5655

Next is a case of ignored warnings even if nothing seemed wrong. These
are the relevant commands, I checked several other things, but I never
checked with the remote svn repository.

> cd C:\Josef\eclipsegworkspace\scipy-branch
> bzr push C:/Josef/eclipsegworkspace/scipy-trunk-new/
bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".

> bzr merge C:/Josef/eclipsegworkspace/scipy-trunk-new/
Nothing to do.

> bzr push  --overwrite C:/Josef/eclipsegworkspace/scipy-trunk-new/
All changes applied successfully.
Pushed up to revision 4967.


The last overwrite push, not only pushed to my local checkout, but
directly also to the scipy svn repository.
My mistake was that I thought, I still had one safety layer between me
and the scipy svn, that I will still need to push from the checkout to
the remote repository. Additionally, I'm pretty sure, I never told bzr
my scipy svn password.

For now I stick with svn, and set up my own test repository until I
have more practice with decentralized version control.

Are the svn data base (svnadmin verify) and the trac data base
internally still consistent?

Sorry about this.

Josef

"Foolproof systems to not take into account the ingenuity of fools." Gene Brown


From opossumnano at gmail.com  Wed Apr 15 21:27:36 2009
From: opossumnano at gmail.com (Tiziano Zito)
Date: Thu, 16 Apr 2009 03:27:36 +0200
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <e06186140904151725h62c194b0sd098dffce16e3f39@mail.gmail.com>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
	<e06186140904151725h62c194b0sd098dffce16e3f39@mail.gmail.com>
Message-ID: <20090416012735.GA11817@notami.bccn-berlin>

On Wed 15 Apr, 18:25, Charles R Harris wrote:
> > > The Git repository indicates that something like this occurred:
> > >
> > >       5655 5656 5657 5658 5659 5660
> > >        o----o----o----o----o----o----o 5661
> > >         \___________________________/
> > >
> > I think that's my fault, but I haven't figured out how to revert this.
> >
> > Can you undo whatever happened in
> > http://projects.scipy.org/scipy/changeset/5661, and I won't try this
> > anymore if it messes up the repository and not just the commit
> > message.
> 
> I found reverting the central svn repository to be a total PITA. If someone
> still has the correct versions of the files the easiest thing to do is just
> commit them.

I had just checked out revision 5660, so I could commit it back again if
it's needed, but one would probably need to change all relevant
files in order to convince svn that they are new, and then manually
solve all conflicts by accepting my own version. Let me know, I
could do it around 6:30 AM UTC on Apr 16!

ciao,
tiziano



From charlesr.harris at gmail.com  Wed Apr 15 21:34:41 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 15 Apr 2009 19:34:41 -0600
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <20090416012735.GA11817@notami.bccn-berlin>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
	<e06186140904151725h62c194b0sd098dffce16e3f39@mail.gmail.com>
	<20090416012735.GA11817@notami.bccn-berlin>
Message-ID: <e06186140904151834oeec052co20c95310086e72fc@mail.gmail.com>

On Wed, Apr 15, 2009 at 7:27 PM, Tiziano Zito <opossumnano at gmail.com> wrote:

> On Wed 15 Apr, 18:25, Charles R Harris wrote:
> > > > The Git repository indicates that something like this occurred:
> > > >
> > > >       5655 5656 5657 5658 5659 5660
> > > >        o----o----o----o----o----o----o 5661
> > > >         \___________________________/
> > > >
> > > I think that's my fault, but I haven't figured out how to revert this.
> > >
> > > Can you undo whatever happened in
> > > http://projects.scipy.org/scipy/changeset/5661, and I won't try this
> > > anymore if it messes up the repository and not just the commit
> > > message.
> >
> > I found reverting the central svn repository to be a total PITA. If
> someone
> > still has the correct versions of the files the easiest thing to do is
> just
> > commit them.
>
> I had just checked out revision 5660, so I could commit it back again if
> it's needed, but one would probably need to change all relevant
> files in order to convince svn that they are new, and then manually
> solve all conflicts by accepting my own version. Let me know, I
> could do it around 6:30 AM UTC on Apr 16!
>

Rename the relevent good files,  check out the latest svn revision, replace
the files with your good versions and commit. If someone knows an easier way
please let me know. Fixing svn after a corrupted commit almost drove me
crazy when I had to do it.

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

From opossumnano at gmail.com  Thu Apr 16 03:08:58 2009
From: opossumnano at gmail.com (Tiziano Zito)
Date: Thu, 16 Apr 2009 09:08:58 +0200
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <e06186140904151834oeec052co20c95310086e72fc@mail.gmail.com>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<1cd32cbb0904151630v245a5cd0h87c8c3c59e18dddb@mail.gmail.com>
	<e06186140904151725h62c194b0sd098dffce16e3f39@mail.gmail.com>
	<20090416012735.GA11817@notami.bccn-berlin>
	<e06186140904151834oeec052co20c95310086e72fc@mail.gmail.com>
Message-ID: <20090416070858.GA12282@notami.bccn-berlin>

On Wed 15 Apr, 19:34, Charles R Harris wrote:
> > I had just checked out revision 5660, so I could commit it back again if
> > it's needed, but one would probably need to change all relevant
> > files in order to convince svn that they are new, and then manually
> > solve all conflicts by accepting my own version. Let me know, I
> > could do it around 6:30 AM UTC on Apr 16!
> >
> 
> Rename the relevent good files,  check out the latest svn revision, replace
> the files with your good versions and commit. If someone knows an easier way
> please let me know. Fixing svn after a corrupted commit almost drove me
> crazy when I had to do it.
> 

ok. can you come up with a list of the relevant good files? I don't
want to screw up things even more. joseph? pauli?
if someone posts the list of files I can immediately start the rescuing
procedure ;-)

ciao,
tiziano



From david at ar.media.kyoto-u.ac.jp  Thu Apr 16 03:04:02 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 16 Apr 2009 16:04:02 +0900
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <gs5p9e$n48$3@ger.gmane.org>
References: <49E3787C.5040300@gmail.com>
	<gs0hut$59s$9@ger.gmane.org>	<49E63FE6.2010901@gmail.com>
	<gs5gej$qlp$3@ger.gmane.org>	<49E6523B.2040201@gmail.com>
	<gs5p9e$n48$3@ger.gmane.org>
Message-ID: <49E6D862.50406@ar.media.kyoto-u.ac.jp>

Pauli Virtanen wrote:
>
> 	$ git diff --stat 746e23..svn/trunk
> 	INSTALL.txt                                       |  222 ++++++++++++++-------
> 	scipy/io/matlab/tests/data/test_skip_variable.mat |  Bin 20225 -> 0 bytes
> 	scipy/io/matlab/tests/test_mio.py                 |   31 +---
> 	scipy/special/specfun_wrappers.c                  |    6 +-
> 	scipy/special/tests/test_basic.py                 |   31 +---
> 	scipy/stats/distributions.py                      |    2 +-
>
> So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at
> the commit message for r5661 more closely, it says ". (copied from trunk)",
> and indeed "svn log ." indicates that r5661 is based on r5660.
>
> Does someone understand SVN enough to know what happened and how
> to revert it, if needed?
>   

I am looking at it right now. Since I can make a copy of the svn
repository, I will try your approach locally, and put it online if it works.

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Thu Apr 16 03:41:33 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 16 Apr 2009 16:41:33 +0900
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <gs5p9e$n48$3@ger.gmane.org>
References: <49E3787C.5040300@gmail.com>
	<gs0hut$59s$9@ger.gmane.org>	<49E63FE6.2010901@gmail.com>
	<gs5gej$qlp$3@ger.gmane.org>	<49E6523B.2040201@gmail.com>
	<gs5p9e$n48$3@ger.gmane.org>
Message-ID: <49E6E12D.5070701@ar.media.kyoto-u.ac.jp>

Pauli Virtanen wrote:
> The Git repository indicates that something like this occurred:
>
>        5655 5656 5657 5658 5659 5660
> 	o----o----o----o----o----o----o 5661
>          \___________________________/
>
> So, the revision 5661 is based on 5655. 

You can see this from svn as well, using the -v option of log:

svn log -r -v HEAD http://svn.scipy.org/svn/numpy/trunk

"""
------------------------------------------------------------------------
r5661 | josef | 2009-04-16 02:30:58 +0900 (Thu, 16 Apr 2009) | 1 line
Changed paths:
   R /trunk (from /trunk:5655)
   M /trunk/scipy/stats/distributions.py

use np.power in rdist (test commit with bzr)
------------------------------------------------------------------------
"""

The 'R' meaning replace. I don't know why bzr did this - it looks like a
bzr-svn bug to me.

I don't know what's best. I tried your suggestion locally:

svn cp file:///usr/media/src/dsp/scipy_trans/yo/trunk at 5660
file:///usr/media/src/dsp/scipy_trans/yo/trunk

but this creates a new trunk directory inside trunk. Omitting the trunk
for the copy destination does not work, svn complains about overwriting
an existing directory.

I don't know what's best: rewriting the svn repository (keep everything
up to 5660 and then commit 5661 as Josef intended, i.e. just changing
distributions.py), or doing the same by reverting the changes.

cheers,

David


From pav at iki.fi  Thu Apr 16 04:28:27 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 16 Apr 2009 08:28:27 +0000 (UTC)
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<49E6E12D.5070701@ar.media.kyoto-u.ac.jp>
Message-ID: <gs6q7b$vl2$1@ger.gmane.org>

Thu, 16 Apr 2009 16:41:33 +0900, David Cournapeau kirjoitti:
> Pauli Virtanen wrote:
>> The Git repository indicates that something like this occurred:
>>
>>        5655 5656 5657 5658 5659 5660
>> 	o----o----o----o----o----o----o 5661
>>          \___________________________/
>>
>> So, the revision 5661 is based on 5655.
> 
> You can see this from svn as well, using the -v option of log:
> 
> svn log -r -v HEAD http://svn.scipy.org/svn/numpy/trunk

Yes, if you know to look for it. But in Git it was obvious what happened, 
since its data model is simpler, so I looked first at it :)

[clip]
> The 'R' meaning replace. I don't know why bzr did this - it looks like a
> bzr-svn bug to me.
> 
> I don't know what's best. I tried your suggestion locally:
> 
> svn cp file:///usr/media/src/dsp/scipy_trans/yo/trunk at 5660
> file:///usr/media/src/dsp/scipy_trans/yo/trunk
> 
> but this creates a new trunk directory inside trunk. Omitting the trunk
> for the copy destination does not work, svn complains about overwriting
> an existing directory.

Does

	svn rm file:///.../yo/trunk
	svn cp file:///.../yo/trunk at 5660 file:///.../yo/trunk

work then?

> I don't know what's best: rewriting the svn repository (keep everything
> up to 5660 and then commit 5661 as Josef intended, i.e. just changing
> distributions.py), or doing the same by reverting the changes.

I'd rather try to restore the trunk tree to 5660 and commit on top of 
that; otherwise you can't do

	svn diff -r 5660:5661 test_basic.py

since SVN thinks 5660 lives in a different directory than 5661 although 
the directories have the same name...

Who said SVN is simple :)

-- 
Pauli Virtanen



From david at ar.media.kyoto-u.ac.jp  Thu Apr 16 04:35:45 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 16 Apr 2009 17:35:45 +0900
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <gs6q7b$vl2$1@ger.gmane.org>
References: <49E3787C.5040300@gmail.com>
	<gs0hut$59s$9@ger.gmane.org>	<49E63FE6.2010901@gmail.com>
	<gs5gej$qlp$3@ger.gmane.org>	<49E6523B.2040201@gmail.com>
	<gs5p9e$n48$3@ger.gmane.org>	<49E6E12D.5070701@ar.media.kyoto-u.ac.jp>
	<gs6q7b$vl2$1@ger.gmane.org>
Message-ID: <49E6EDE1.6060004@ar.media.kyoto-u.ac.jp>

Pauli Virtanen wrote:
>
> Yes, if you know to look for it. But in Git it was obvious what happened, 
> since its data model is simpler, so I looked first at it :)
>   

Oh, yes, definitely :) I felt safer to check that svn reported this as
well, though.

>
> Does
>
> 	svn rm file:///.../yo/trunk
> 	svn cp file:///.../yo/trunk at 5660 file:///.../yo/trunk
>
> work then?
>   

I guess it would, but I am afraid it would horribly break the whole
history (the file ids would be different).

> I'd rather try to restore the trunk tree to 5660 and commit on top of 
> that; otherwise you can't do
>
> 	svn diff -r 5660:5661 test_basic.py
>
> since SVN thinks 5660 lives in a different directory than 5661 although 
> the directories have the same name...
>   

Rewriting/restoring the repository is technically better, because we can
erase the error, and it is guaranteed it won't break any history-related
features in svn. But I don't know what it means for people who have
checked out revision 5661 before the rewriting, which worries me a bit.
Maybe that's not very important.

> Who said SVN is simple :)
>   

:)

David



From Nicolas.Rougier at loria.fr  Thu Apr 16 09:09:43 2009
From: Nicolas.Rougier at loria.fr (Nicolas Rougier)
Date: Thu, 16 Apr 2009 15:09:43 +0200
Subject: [SciPy-dev] glipy, OpenGL IPython terminal with numpy support
In-Reply-To: <wl8ab6iauwz.fsf@glup.physics.ucf.edu>
References: <mailman.12404.1239789887.2878.scipy-dev@scipy.org>
	<wl8ab6iauwz.fsf@glup.physics.ucf.edu>
Message-ID: <1239887383.10826.2.camel@sulfur.loria.fr>


Thanks.
I do not know when glipy will be stable, it mainly depends on users whow
want to test it and report bugs. Concerning possible extensions, I
prefer right now to concentrate on the very basics to try to offer a
stable applications. I fear that extensions will have to wait.

Nicolas


On Wed, 2009-04-15 at 09:49 -0400, Joe Harrington wrote:
> Nicolas Rougier <Nicolas.Rougier at loria.fr> wrote:
> 
> > I've made a Python/IPython terminal using pyglet with embedded support
> > for numpy arrays (1D or 2D). It uses OpenGL and is pretty fast.
> > 
> > It does not aim at replacing matplotlib or mayavi mlab module but is
> > rahter aimed at quick experimentations or debugging.
> > 
> > I've setup a launchpad glipy project at:
> > https://launchpad.net/glipy
> > 
> > as well as a rudimentary homepage:
> > http://webloria.loria.fr/~rougier/glipy/
> > 
> > for those who want to test it. It is still an early beta version and may
> > be plenty of bugs...
> > 
> > 
> > Nicolas
> 
> Nicolas, this is awesome, a perfect teaching tool!  I'd like to use it
> in my class.  Will it be stable in time for Fall classes?
> 
> Some thoughts:
> 
> Would it be possible to (optionally) detach the graphics from the
> text, so that they're in separate windows and you just see the current
> figure?
> 
> How about using (optionally) an external display program like DS9,
> which has great features for interactively exploring the data in a
> floating 2D array (scale contrast, brightness, and displayed data
> range with the mouse; change colormaps; blink image sets; panel
> images; annotate images; etc?).  This package is used widely in the
> astronomy community.  Basically, what you're doing would automate the
> repetitious act of sending every line's result to DS9 manually, and
> provide basic capability for compositing images before display.
> 
> --jh--
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From charlesr.harris at gmail.com  Thu Apr 16 12:42:32 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 16 Apr 2009 10:42:32 -0600
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <49E6EDE1.6060004@ar.media.kyoto-u.ac.jp>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<49E6E12D.5070701@ar.media.kyoto-u.ac.jp> <gs6q7b$vl2$1@ger.gmane.org>
	<49E6EDE1.6060004@ar.media.kyoto-u.ac.jp>
Message-ID: <e06186140904160942l2bc80e96icfa79c6bfd325362@mail.gmail.com>

On Thu, Apr 16, 2009 at 2:35 AM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> Pauli Virtanen wrote:
> >
> > Yes, if you know to look for it. But in Git it was obvious what happened,
> > since its data model is simpler, so I looked first at it :)
> >
>
> Oh, yes, definitely :) I felt safer to check that svn reported this as
> well, though.
>
> >
> > Does
> >
> >       svn rm file:///.../yo/trunk
> >       svn cp file:///.../yo/trunk at 5660 file:///.../yo/trunk
> >
> > work then?
> >
>
> I guess it would, but I am afraid it would horribly break the whole
> history (the file ids would be different).
>
> > I'd rather try to restore the trunk tree to 5660 and commit on top of
> > that; otherwise you can't do
> >
> >       svn diff -r 5660:5661 test_basic.py
> >
> > since SVN thinks 5660 lives in a different directory than 5661 although
> > the directories have the same name...
> >
>
> Rewriting/restoring the repository is technically better, because we can
> erase the error, and it is guaranteed it won't break any history-related
> features in svn. But I don't know what it means for people who have
> checked out revision 5661 before the rewriting, which worries me a bit.
> Maybe that's not very important.
>

The diffs on trac for r5656-r5660 look valid. Just download them and patch
the files.

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

From prabhu at aero.iitb.ac.in  Thu Apr 16 13:25:16 2009
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Thu, 16 Apr 2009 22:55:16 +0530
Subject: [SciPy-dev] the scipy mission, include finite element solver
In-Reply-To: <85b5c3130904150204l594c30a6x568c7dc1d62ad2b3@mail.gmail.com>
References: <85b5c3130904051445q751d9a6eo6bc4e036f2f2a279@mail.gmail.com>	<85b5c3130904081543r32c274fbyb5cd4025125049b8@mail.gmail.com>	<3d375d730904081604s2c19bac9x7edd87da42645ebf@mail.gmail.com>	<85b5c3130904141342h9704168mbeda0c8c0a597b73@mail.gmail.com>	<49E51096.4020106@astraw.com>	<3d375d730904141543u671c63dfp245849f081016afd@mail.gmail.com>	<49E51E49.90208@astraw.com>	<5b8d13220904141723g19d40de9w6f674359f23a8e3e@mail.gmail.com>	<49E5A1C1.3090901@student.matnat.uio.no>	<49E5A434.6080204@student.matnat.uio.no>
	<85b5c3130904150204l594c30a6x568c7dc1d62ad2b3@mail.gmail.com>
Message-ID: <49E769FC.3030003@aero.iitb.ac.in>

On 04/15/09 14:34, Ondrej Certik wrote:
> Besides that, both William and Michael are interested in helping me
> out, for example William and Mike Hansen just spent an evening
> disentangling the Sage notebook, so that we can use it in SPD and they
> can use it in the windows port:
> 
> http://trac.sagemath.org/sage_trac/ticket/5789
> 
> while in the scipy community, unfortunately, I can still see many
> doubts if this effort is really needed/worthy, etc. So I first need to

Well, in case you refer to me, I think SPD is a great idea!  Thanks for 
doing it.

cheers,
prabhu


From cournape at gmail.com  Thu Apr 16 14:06:03 2009
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 17 Apr 2009 03:06:03 +0900
Subject: [SciPy-dev] SVN "corruption" / bzr-svn oddity?
In-Reply-To: <e06186140904160942l2bc80e96icfa79c6bfd325362@mail.gmail.com>
References: <49E3787C.5040300@gmail.com> <gs0hut$59s$9@ger.gmane.org>
	<49E63FE6.2010901@gmail.com> <gs5gej$qlp$3@ger.gmane.org>
	<49E6523B.2040201@gmail.com> <gs5p9e$n48$3@ger.gmane.org>
	<49E6E12D.5070701@ar.media.kyoto-u.ac.jp> <gs6q7b$vl2$1@ger.gmane.org>
	<49E6EDE1.6060004@ar.media.kyoto-u.ac.jp>
	<e06186140904160942l2bc80e96icfa79c6bfd325362@mail.gmail.com>
Message-ID: <5b8d13220904161106t3f980edfoc20b0bdca83218b6@mail.gmail.com>

On Fri, Apr 17, 2009 at 1:42 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Thu, Apr 16, 2009 at 2:35 AM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
>>
>> Rewriting/restoring the repository is technically better, because we can
>> erase the error, and it is guaranteed it won't break any history-related
>> features in svn. But I don't know what it means for people who have
>> checked out revision 5661 before the rewriting, which worries me a bit.
>> Maybe that's not very important.

I ended up using git revert functionality to revert Josef commit, and
replay commit 5661 on the current svn "tip" as Josef intended (only
changing pow to np.pow). According to diff at least, there no
unexpected diff between r5660 and HEAD,

David


From david at ar.media.kyoto-u.ac.jp  Fri Apr 17 01:22:14 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 17 Apr 2009 14:22:14 +0900
Subject: [SciPy-dev] Scheduling 0.7.1
Message-ID: <49E81206.8020608@ar.media.kyoto-u.ac.jp>

Hi,

    I would like to release 0.7.1 relatively soon. There are a few
low-hanging fruits, and here is a proposed schedule. Since no new
features are added for 0.7.1, I don't think we really need a beta:

- RC: 11th May (Monday)
- Release: 18th May (Monday)

My own interests are:
    - distribute a 0.7.1 binary for python 2.6 on windows and maybe mac
os x.
    - make sure 0.7.1 is a universal build on mac os x (it is broken ATM).
    - fix some major segfaults/memleak in scipy.signal.lfilter, some of
which were regressions compared to 0.6.0

So if you have some things (only bugs/doc enhancements, no new
features), please backport them ASAP,

cheers,

David


From gael.varoquaux at normalesup.org  Fri Apr 17 03:01:04 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 17 Apr 2009 09:01:04 +0200
Subject: [SciPy-dev] Scheduling 0.7.1
In-Reply-To: <49E81206.8020608@ar.media.kyoto-u.ac.jp>
References: <49E81206.8020608@ar.media.kyoto-u.ac.jp>
Message-ID: <20090417070104.GA22239@phare.normalesup.org>

On Fri, Apr 17, 2009 at 02:22:14PM +0900, David Cournapeau wrote:
>     I would like to release 0.7.1 relatively soon. There are a few
> low-hanging fruits, and here is a proposed schedule. Since no new
> features are added for 0.7.1, I don't think we really need a beta:

> - RC: 11th May (Monday)
> - Release: 18th May (Monday)

> My own interests are:
>     - distribute a 0.7.1 binary for python 2.6 on windows and maybe mac
> os x.
>     - make sure 0.7.1 is a universal build on mac os x (it is broken ATM).
>     - fix some major segfaults/memleak in scipy.signal.lfilter, some of
> which were regressions compared to 0.6.0

Any chance matlab reader gets fixed? 

http://projects.scipy.org/scipy/ticket/885

Cheers,

Ga?l


From stefan at sun.ac.za  Fri Apr 17 05:49:27 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 17 Apr 2009 11:49:27 +0200
Subject: [SciPy-dev] Scheduling 0.7.1
In-Reply-To: <20090417070104.GA22239@phare.normalesup.org>
References: <49E81206.8020608@ar.media.kyoto-u.ac.jp>
	<20090417070104.GA22239@phare.normalesup.org>
Message-ID: <9457e7c80904170249x50013e64n7323c26476288d38@mail.gmail.com>

Hi Gael

2009/4/17 Gael Varoquaux <gael.varoquaux at normalesup.org>:
> Any chance matlab reader gets fixed?
>
> http://projects.scipy.org/scipy/ticket/885

If you can provide a test case, I'll add it today.

Cheers
St?fan


From gael.varoquaux at normalesup.org  Fri Apr 17 05:52:08 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 17 Apr 2009 11:52:08 +0200
Subject: [SciPy-dev] Scheduling 0.7.1
In-Reply-To: <9457e7c80904170249x50013e64n7323c26476288d38@mail.gmail.com>
References: <49E81206.8020608@ar.media.kyoto-u.ac.jp>
	<20090417070104.GA22239@phare.normalesup.org>
	<9457e7c80904170249x50013e64n7323c26476288d38@mail.gmail.com>
Message-ID: <20090417095208.GF24080@phare.normalesup.org>

On Fri, Apr 17, 2009 at 11:49:27AM +0200, St?fan van der Walt wrote:
> 2009/4/17 Gael Varoquaux <gael.varoquaux at normalesup.org>:
> > Any chance matlab reader gets fixed?

> > http://projects.scipy.org/scipy/ticket/885

> If you can provide a test case, I'll add it today.

Not really, the corresponding file is big, and I don't know how to
extract the part that triggers the bug. I was hoping the maintainer of
this package of scipy (Matthew?) would know simply by looking at the fix
how to create a test.

Ga?l


From thouis at broad.mit.edu  Fri Apr 17 14:57:46 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Fri, 17 Apr 2009 14:57:46 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists if
	index is a list?
Message-ID: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>

Current behavior:
>>> from scipy import ndimage
>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
[1.0, 4.0]
>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
1.0
>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
1.0

I think the second result should be [1.0].  We're using the ndimage
code for image processing, and have to wrap the measurement functions
to make the code general for the case where there is only one object
in the image.

Less important, though it might make sense, is to have this code
return [] rather than raising an exception:
>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[])


Ray Jones


From xavier.gnata at gmail.com  Fri Apr 17 15:33:19 2009
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Fri, 17 Apr 2009 21:33:19 +0200
Subject: [SciPy-dev] 0.8.0.dev5677 test status on ubuntu 64bits.
Message-ID: <49E8D97F.1020007@gmail.com>

Hi,

On my box, scipy.test() has never been so close to a perfect score :)
On ubuntu 64bits up to date, I get:

3 failures due to target accuracy problems.
1 error in test_implicit (the test in completely buggy)
1 faillure in test_yv_cephes_vs_amos

======================================================================               

ERROR: test_implicit
(test_odr.TestODR)                                              
----------------------------------------------------------------------               

Traceback (most recent call
last):                                                   
  File
"/usr/local/lib/python2.6/dist-packages/scipy/odr/tests/test_odr.py",
line 88, in
test_implicit                                                                     

    out =
implicit_odr.run()                                                         
  File "/usr/local/lib/python2.6/dist-packages/scipy/odr/odrpack.py",
line 1055, in
run                                                                                    

    self.output = Output(apply(odr, args,
kwds))                                     
TypeError: y must be a sequence or integer (if model is
implicit)                    

======================================================================
FAIL: test_random_real (test_basic.TestSingleIFFT)                   
----------------------------------------------------------------------
Traceback (most recent call last):                                   
  File
"/usr/local/lib/python2.6/dist-packages/scipy/fftpack/tests/test_basic.py",
line 206, in
test_random_real                                                           
    assert_array_almost_equal (y2,
x)                                                
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 537, in
assert_array_almost_equal                                                             

    header='Arrays are not almost
equal')                                            
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 395, in
assert_array_compare                                                                  

    raise
AssertionError(msg)                                                        
AssertionError:                                                                      

Arrays are not almost
equal                                                          

(mismatch 0.900900900901%)
 x: array([ 0.90677679 +1.39698386e-08j,  0.28927034 +3.25962901e-09j,
        0.13077791 +6.23986125e-08j,  0.04575246 -2.03919583e-08j,   
        0.15793833 +2.15254765e-08j,  0.85683167 -1.69426109e-08j,...
 y: array([ 0.90677708,  0.28927055,  0.13077785,  0.04575244,  0.15793809,
        0.85683167,  0.8643328 ,  0.23614296,  0.59372395,  0.37073961,   
        0.30814797,  0.89584029,  0.00581159,  0.07267515,  0.77166247,...

======================================================================
FAIL: test_yn_zeros (test_basic.TestBessel)                          
----------------------------------------------------------------------
Traceback (most recent call last):                                   
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 1602, in
test_yn_zeros                                                             
    488.98055964441374646],
rtol=1e-19)                                              
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 38, in
assert_tol_equal                                                            

    verbose=verbose,
header=header)                                                  
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 395, in
assert_array_compare                                                                  

    raise
AssertionError(msg)                                                        
AssertionError:                                                                      

Not equal to tolerance rtol=1e-19,
atol=0                                            

(mismatch 100.0%)
 x: array([ 450.136,  463.057,  472.807,  481.274,  488.981])
 y: array([ 450.136,  463.057,  472.807,  481.274,  488.981])

======================================================================
FAIL: test_ynp_zeros (test_basic.TestBessel)                         
----------------------------------------------------------------------
Traceback (most recent call last):                                   
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 1608, in
test_ynp_zeros                                                            
    assert_tol_equal(yvp(443, ao), 0,
atol=1e-15)                                    
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 38, in
assert_tol_equal                                                            

    verbose=verbose,
header=header)                                                  
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 395, in
assert_array_compare                                                                  

    raise
AssertionError(msg)                                                        
AssertionError:                                                                      

Not equal to tolerance rtol=1e-07,
atol=1e-15                                        

(mismatch 100.0%)
 x: array([  1.239e-10,  -8.119e-16,   3.608e-16,   5.898e-16,   1.226e-15])
 y: array(0)                                                               

======================================================================
FAIL: test_yv_cephes_vs_amos (test_basic.TestBessel)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 1668, in test_yv_cephes_vs_amos
    self.check_cephes_vs_amos(yv, yn, rtol=1e-11, atol=1e-305)
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py",
line 1657, in check_cephes_vs_amos
    assert c2.imag != 0, (v, z)
AssertionError: (301, 1.0)

FAILED (KNOWNFAIL=2, SKIP=17, errors=1, failures=4)

SKIP=17 ? I'm not sure if it is normal or not.

Xavier, who really think that the testsuite is a key element of scipy.


From andrei.avk at gmail.com  Fri Apr 17 17:47:43 2009
From: andrei.avk at gmail.com (AK)
Date: Fri, 17 Apr 2009 17:47:43 -0400
Subject: [SciPy-dev] Request of edit rights
Message-ID: <49E8F8FF.4020508@gmail.com>

Hi, I'd like to request edit rights for wiki, my username is RainyDay. 
thanks, -andrei


From robert.kern at gmail.com  Fri Apr 17 17:51:30 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 17 Apr 2009 16:51:30 -0500
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <49E8F8FF.4020508@gmail.com>
References: <49E8F8FF.4020508@gmail.com>
Message-ID: <3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>

On Fri, Apr 17, 2009 at 16:47, AK <andrei.avk at gmail.com> wrote:
> Hi, I'd like to request edit rights for wiki, my username is RainyDay.

What do you want to edit?

-- 
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 andrei.avk at gmail.com  Fri Apr 17 18:01:14 2009
From: andrei.avk at gmail.com (AK)
Date: Fri, 17 Apr 2009 18:01:14 -0400
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
Message-ID: <49E8FC2A.8040806@gmail.com>

Robert Kern wrote:
> On Fri, Apr 17, 2009 at 16:47, AK <andrei.avk at gmail.com> wrote:
>   
>> Hi, I'd like to request edit rights for wiki, my username is RainyDay.
>>     
>
> What do you want to edit?
>
>   
I was going to start with lib.scimath.logn() and then go down the list 
and see what else I could edit.. I saw post by Joseph Harrington on 
Python jobs page and I'm going to try to write a few docs and see how 
that goes. If you need to restrict editing rights to one package, let me 
know and I'll look around and see which package I could work on. -andrei


From robert.kern at gmail.com  Fri Apr 17 18:08:17 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 17 Apr 2009 17:08:17 -0500
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <49E8FC2A.8040806@gmail.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com> 
	<49E8FC2A.8040806@gmail.com>
Message-ID: <3d375d730904171508u72eb581ayee4febda28a5ecd5@mail.gmail.com>

On Fri, Apr 17, 2009 at 17:01, AK <andrei.avk at gmail.com> wrote:
> Robert Kern wrote:
>> On Fri, Apr 17, 2009 at 16:47, AK <andrei.avk at gmail.com> wrote:
>>
>>> Hi, I'd like to request edit rights for wiki, my username is RainyDay.
>>>
>>
>> What do you want to edit?
>>
>>
> I was going to start with lib.scimath.logn() and then go down the list
> and see what else I could edit.. I saw post by Joseph Harrington on
> Python jobs page and I'm going to try to write a few docs and see how
> that goes. If you need to restrict editing rights to one package, let me
> know and I'll look around and see which package I could work on. -andrei

Ah, okay, you meant the docs wiki rather than the main wiki. Someone
else will have to take care of that.

I asked because one doesn't need any special rights to contribute to
the main wiki. Belonging to the EditorsGroup, i.e. having "edit
rights", allow one to do more destructive things like deleting pages.
You can understand why I would want to know something about you before
giving you those.  :-)

-- 
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 andrei.avk at gmail.com  Fri Apr 17 18:16:07 2009
From: andrei.avk at gmail.com (AK)
Date: Fri, 17 Apr 2009 18:16:07 -0400
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <3d375d730904171508u72eb581ayee4febda28a5ecd5@mail.gmail.com>
References: <49E8F8FF.4020508@gmail.com>	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com>
	<3d375d730904171508u72eb581ayee4febda28a5ecd5@mail.gmail.com>
Message-ID: <49E8FFA7.80601@gmail.com>

Robert Kern wrote:
> On Fri, Apr 17, 2009 at 17:01, AK <andrei.avk at gmail.com> wrote:
>   
>> Robert Kern wrote:
>>     
>>> On Fri, Apr 17, 2009 at 16:47, AK <andrei.avk at gmail.com> wrote:
>>>
>>>       
>>>> Hi, I'd like to request edit rights for wiki, my username is RainyDay.
>>>>
>>>>         
>>> What do you want to edit?
>>>
>>>
>>>       
>> I was going to start with lib.scimath.logn() and then go down the list
>> and see what else I could edit.. I saw post by Joseph Harrington on
>> Python jobs page and I'm going to try to write a few docs and see how
>> that goes. If you need to restrict editing rights to one package, let me
>> know and I'll look around and see which package I could work on. -andrei
>>     
>
> Ah, okay, you meant the docs wiki rather than the main wiki. Someone
> else will have to take care of that.
>
> I asked because one doesn't need any special rights to contribute to
> the main wiki. Belonging to the EditorsGroup, i.e. having "edit
> rights", allow one to do more destructive things like deleting pages.
> You can understand why I would want to know something about you before
> giving you those.  :-)
>
>   
Sure thing, I should have mentioned the python job page post.. can't
have people just deleting page left and right :). -andrei


From aahz at pythoncraft.com  Fri Apr 17 20:53:52 2009
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 17 Apr 2009 17:53:52 -0700
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <49E8FC2A.8040806@gmail.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com>
Message-ID: <20090418005352.GC4950@panix.com>

On Fri, Apr 17, 2009, AK wrote:
> Robert Kern wrote:
>> On Fri, Apr 17, 2009 at 16:47, AK <andrei.avk at gmail.com> wrote:
>>>   
>>> Hi, I'd like to request edit rights for wiki, my username is RainyDay.
>>
>> What do you want to edit?
>   
> I was going to start with lib.scimath.logn() and then go down the list 
> and see what else I could edit.. I saw post by Joseph Harrington on 
> Python jobs page and I'm going to try to write a few docs and see how 
> that goes. If you need to restrict editing rights to one package, let me 
> know and I'll look around and see which package I could work on.

Looks likes it's a competition!  ;-)  I would also like edit rights for
the same reason, my username is "Aahz" (surprise, surprise).
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair


From andrei.avk at gmail.com  Fri Apr 17 21:14:33 2009
From: andrei.avk at gmail.com (AK)
Date: Fri, 17 Apr 2009 21:14:33 -0400
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <20090418005352.GC4950@panix.com>
References: <49E8F8FF.4020508@gmail.com>	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>	<49E8FC2A.8040806@gmail.com>
	<20090418005352.GC4950@panix.com>
Message-ID: <49E92979.1040801@gmail.com>

Aahz wrote:
> On Fri, Apr 17, 2009, AK wrote:
>   
>> Robert Kern wrote:
>>     
>>> On Fri, Apr 17, 2009 at 16:47, AK <andrei.avk at gmail.com> wrote:
>>>       
>>>>   
>>>> Hi, I'd like to request edit rights for wiki, my username is RainyDay.
>>>>         
>>> What do you want to edit?
>>>       
>>   
>> I was going to start with lib.scimath.logn() and then go down the list 
>> and see what else I could edit.. I saw post by Joseph Harrington on 
>> Python jobs page and I'm going to try to write a few docs and see how 
>> that goes. If you need to restrict editing rights to one package, let me 
>> know and I'll look around and see which package I could work on.
>>     
>
> Looks likes it's a competition!  ;-)  I would also like edit rights for
> the same reason, my username is "Aahz" (surprise, surprise).
>   
Doh! Competition.. I was first! Just kidding :) -andrei


From aahz at pythoncraft.com  Fri Apr 17 21:28:20 2009
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 17 Apr 2009 18:28:20 -0700
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <49E92979.1040801@gmail.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com> <20090418005352.GC4950@panix.com>
	<49E92979.1040801@gmail.com>
Message-ID: <20090418012820.GA13121@panix.com>

On Fri, Apr 17, 2009, AK wrote:
> Aahz wrote:
>>
>> Looks likes it's a competition!  ;-)  I would also like edit rights for
>> the same reason, my username is "Aahz" (surprise, surprise).
>   
> Doh! Competition.. I was first! Just kidding :)

You may have been first to request edit rights, but I was actually first
to respond because I cheated.  (I'm a python.org webmaster, so I saw the
listing before it was posted.)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair


From zachary.pincus at yale.edu  Fri Apr 17 22:06:57 2009
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Fri, 17 Apr 2009 22:06:57 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
Message-ID: <18239520-DA02-4895-88C9-B5B21B533011@yale.edu>

> Current behavior:
>>>> from scipy import ndimage
>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
> [1.0, 4.0]
>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
> 1.0
>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
> 1.0
>
> I think the second result should be [1.0].  We're using the ndimage
> code for image processing, and have to wrap the measurement functions
> to make the code general for the case where there is only one object
> in the image.

I've run into this too, and had the same thought. It's such a corner- 
case that it doesn't seem like gratuitous API-breakage to make this  
fix...

Zach


From gael.varoquaux at normalesup.org  Sat Apr 18 05:14:06 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 18 Apr 2009 11:14:06 +0200
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <20090418005352.GC4950@panix.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com> <20090418005352.GC4950@panix.com>
Message-ID: <20090418091406.GA16064@phare.normalesup.org>

On Fri, Apr 17, 2009 at 05:53:52PM -0700, Aahz wrote:
> > I was going to start with lib.scimath.logn() and then go down the list 
> > and see what else I could edit.. I saw post by Joseph Harrington on 
> > Python jobs page and I'm going to try to write a few docs and see how 
> > that goes. If you need to restrict editing rights to one package, let me 
> > know and I'll look around and see which package I could work on.

> Looks likes it's a competition!  ;-)  I would also like edit rights for
> the same reason, my username is "Aahz" (surprise, surprise).

I have given both of you edit rights.

Ga?l


From thouis at broad.mit.edu  Sat Apr 18 16:47:50 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Sat, 18 Apr 2009 16:47:50 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com> 
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
Message-ID: <6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>

Here's a first attempt at a patch.  It fixes the corner case of a
single index to match the index type (scalar for scalar, list for
single element sequence), also the case of index=[] to return [] for
any measurement.  Finally, it improves type checking of the index
type, which was only being checked for sum() and not any of the other
measurements (?).

Zach, would you mind reviewing?  If it looks good, I'll add some tests
for the new functionality and submit a patch via trac.

Ray

On Fri, Apr 17, 2009 at 22:06, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> Current behavior:
>>>>> from scipy import ndimage
>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
>> [1.0, 4.0]
>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
>> 1.0
>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
>> 1.0
>>
>> I think the second result should be [1.0]. ?We're using the ndimage
>> code for image processing, and have to wrap the measurement functions
>> to make the code general for the case where there is only one object
>> in the image.
>
> I've run into this too, and had the same thought. It's such a corner-
> case that it doesn't seem like gratuitous API-breakage to make this
> fix...
>
> Zach
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-make-output-agree-with-index-argument-for-single-ind.patch
Type: application/octet-stream
Size: 12120 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090418/d669b7fd/attachment.obj>

From thouis at broad.mit.edu  Sat Apr 18 19:28:47 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Sat, 18 Apr 2009 19:28:47 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com> 
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
Message-ID: <6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>

My last patch did not do the right thing for ndimage.extrema(), which
needs to return 4 values with the same semantics.  I've attached an
addendum.

Ray Jones


On Sat, Apr 18, 2009 at 16:47, Thouis (Ray) Jones <thouis at broad.mit.edu> wrote:
> Here's a first attempt at a patch. ?It fixes the corner case of a
> single index to match the index type (scalar for scalar, list for
> single element sequence), also the case of index=[] to return [] for
> any measurement. ?Finally, it improves type checking of the index
> type, which was only being checked for sum() and not any of the other
> measurements (?).
>
> Zach, would you mind reviewing? ?If it looks good, I'll add some tests
> for the new functionality and submit a patch via trac.
>
> Ray
>
> On Fri, Apr 17, 2009 at 22:06, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>>> Current behavior:
>>>>>> from scipy import ndimage
>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
>>> [1.0, 4.0]
>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
>>> 1.0
>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
>>> 1.0
>>>
>>> I think the second result should be [1.0]. ?We're using the ndimage
>>> code for image processing, and have to wrap the measurement functions
>>> to make the code general for the case where there is only one object
>>> in the image.
>>
>> I've run into this too, and had the same thought. It's such a corner-
>> case that it doesn't seem like gratuitous API-breakage to make this
>> fix...
>>
>> Zach
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-special-case-for-extrema.patch
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090418/3efe0ca4/attachment.obj>

From zachary.pincus at yale.edu  Sat Apr 18 20:16:43 2009
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Sat, 18 Apr 2009 20:16:43 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
Message-ID: <35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>

I'm looking over the patch currently, but let me ask a quick question  
first: is there a performance (or other) reason to not just do the  
list-wrapping/unwrapping thing in Python, rather than in the C code?

Zach




On Apr 18, 2009, at 7:28 PM, Thouis (Ray) Jones wrote:

> My last patch did not do the right thing for ndimage.extrema(), which
> needs to return 4 values with the same semantics.  I've attached an
> addendum.
>
> Ray Jones
>
>
> On Sat, Apr 18, 2009 at 16:47, Thouis (Ray) Jones <thouis at broad.mit.edu 
> > wrote:
>> Here's a first attempt at a patch.  It fixes the corner case of a
>> single index to match the index type (scalar for scalar, list for
>> single element sequence), also the case of index=[] to return [] for
>> any measurement.  Finally, it improves type checking of the index
>> type, which was only being checked for sum() and not any of the other
>> measurements (?).
>>
>> Zach, would you mind reviewing?  If it looks good, I'll add some  
>> tests
>> for the new functionality and submit a patch via trac.
>>
>> Ray
>>
>> On Fri, Apr 17, 2009 at 22:06, Zachary Pincus <zachary.pincus at yale.edu 
>> > wrote:
>>>> Current behavior:
>>>>>>> from scipy import ndimage
>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
>>>> [1.0, 4.0]
>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
>>>> 1.0
>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
>>>> 1.0
>>>>
>>>> I think the second result should be [1.0].  We're using the ndimage
>>>> code for image processing, and have to wrap the measurement  
>>>> functions
>>>> to make the code general for the case where there is only one  
>>>> object
>>>> in the image.
>>>
>>> I've run into this too, and had the same thought. It's such a  
>>> corner-
>>> case that it doesn't seem like gratuitous API-breakage to make this
>>> fix...
>>>
>>> Zach
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>
> <0002-special-case-for- 
> extrema.patch>_______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From thouis at broad.mit.edu  Sat Apr 18 22:21:24 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Sat, 18 Apr 2009 22:21:24 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com> 
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com> 
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com> 
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
Message-ID: <6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>

I don't believe so.  I considered that, but there have to be some
changes made to the C code to handle empty lists and better error
checking, so figured I'd keep most of the changes in the same file.

Each of the functions calling statistics() could wrap it with
something that does the right thing with the return value given the
type of index().  Let me know if you think that would be cleaner.

Ray

On Sat, Apr 18, 2009 at 20:16, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> I'm looking over the patch currently, but let me ask a quick question
> first: is there a performance (or other) reason to not just do the
> list-wrapping/unwrapping thing in Python, rather than in the C code?
>
> Zach
>
>
>
>
> On Apr 18, 2009, at 7:28 PM, Thouis (Ray) Jones wrote:
>
>> My last patch did not do the right thing for ndimage.extrema(), which
>> needs to return 4 values with the same semantics. ?I've attached an
>> addendum.
>>
>> Ray Jones
>>
>>
>> On Sat, Apr 18, 2009 at 16:47, Thouis (Ray) Jones <thouis at broad.mit.edu
>> > wrote:
>>> Here's a first attempt at a patch. ?It fixes the corner case of a
>>> single index to match the index type (scalar for scalar, list for
>>> single element sequence), also the case of index=[] to return [] for
>>> any measurement. ?Finally, it improves type checking of the index
>>> type, which was only being checked for sum() and not any of the other
>>> measurements (?).
>>>
>>> Zach, would you mind reviewing? ?If it looks good, I'll add some
>>> tests
>>> for the new functionality and submit a patch via trac.
>>>
>>> Ray
>>>
>>> On Fri, Apr 17, 2009 at 22:06, Zachary Pincus <zachary.pincus at yale.edu
>>> > wrote:
>>>>> Current behavior:
>>>>>>>> from scipy import ndimage
>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
>>>>> [1.0, 4.0]
>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
>>>>> 1.0
>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
>>>>> 1.0
>>>>>
>>>>> I think the second result should be [1.0]. ?We're using the ndimage
>>>>> code for image processing, and have to wrap the measurement
>>>>> functions
>>>>> to make the code general for the case where there is only one
>>>>> object
>>>>> in the image.
>>>>
>>>> I've run into this too, and had the same thought. It's such a
>>>> corner-
>>>> case that it doesn't seem like gratuitous API-breakage to make this
>>>> fix...
>>>>
>>>> Zach
>>>> _______________________________________________
>>>> Scipy-dev mailing list
>>>> Scipy-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>
>> <0002-special-case-for-
>> extrema.patch>_______________________________________________
>> 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  Sat Apr 18 22:50:14 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 18 Apr 2009 22:50:14 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
Message-ID: <1cd32cbb0904181950y5efeccb2v65895d0e32a5247f@mail.gmail.com>

On Sat, Apr 18, 2009 at 10:21 PM, Thouis (Ray) Jones
<thouis at broad.mit.edu> wrote:
> I don't believe so. ?I considered that, but there have to be some
> changes made to the C code to handle empty lists and better error
> checking, so figured I'd keep most of the changes in the same file.
>
> Each of the functions calling statistics() could wrap it with
> something that does the right thing with the return value given the
> type of index(). ?Let me know if you think that would be cleaner.
>
> Ray
>
> On Sat, Apr 18, 2009 at 20:16, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> I'm looking over the patch currently, but let me ask a quick question
>> first: is there a performance (or other) reason to not just do the
>> list-wrapping/unwrapping thing in Python, rather than in the C code?
>>
>> Zach
>>
>>
>>
>>
>> On Apr 18, 2009, at 7:28 PM, Thouis (Ray) Jones wrote:
>>
>>> My last patch did not do the right thing for ndimage.extrema(), which
>>> needs to return 4 values with the same semantics. ?I've attached an
>>> addendum.
>>>
>>> Ray Jones
>>>
>>>
>>> On Sat, Apr 18, 2009 at 16:47, Thouis (Ray) Jones <thouis at broad.mit.edu
>>> > wrote:
>>>> Here's a first attempt at a patch. ?It fixes the corner case of a
>>>> single index to match the index type (scalar for scalar, list for
>>>> single element sequence), also the case of index=[] to return [] for
>>>> any measurement. ?Finally, it improves type checking of the index
>>>> type, which was only being checked for sum() and not any of the other
>>>> measurements (?).
>>>>
>>>> Zach, would you mind reviewing? ?If it looks good, I'll add some
>>>> tests
>>>> for the new functionality and submit a patch via trac.
>>>>
>>>> Ray
>>>>
>>>> On Fri, Apr 17, 2009 at 22:06, Zachary Pincus <zachary.pincus at yale.edu
>>>> > wrote:
>>>>>> Current behavior:
>>>>>>>>> from scipy import ndimage
>>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
>>>>>> [1.0, 4.0]
>>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
>>>>>> 1.0
>>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
>>>>>> 1.0
>>>>>>
>>>>>> I think the second result should be [1.0]. ?We're using the ndimage
>>>>>> code for image processing, and have to wrap the measurement
>>>>>> functions
>>>>>> to make the code general for the case where there is only one
>>>>>> object
>>>>>> in the image.
>>>>>
>>>>> I've run into this too, and had the same thought. It's such a
>>>>> corner-
>>>>> case that it doesn't seem like gratuitous API-breakage to make this
>>>>> fix...


If I understand correctly what you are doing, then this is related to tickets
http://projects.scipy.org/scipy/ticket/412 and 868.

Are you able to check these? It would be good to get rid of some
segfaults in ndimage.

Thanks,
Josef


From thouis at broad.mit.edu  Sun Apr 19 09:52:15 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Sun, 19 Apr 2009 09:52:15 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <1cd32cbb0904181950y5efeccb2v65895d0e32a5247f@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com> 
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com> 
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com> 
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com> 
	<1cd32cbb0904181950y5efeccb2v65895d0e32a5247f@mail.gmail.com>
Message-ID: <6c17e6f50904190652y67e44165r5830409dc97bebe@mail.gmail.com>

On Sat, Apr 18, 2009 at 22:50,  <josef.pktd at gmail.com> wrote:
> If I understand correctly what you are doing, then this is related to tickets
> http://projects.scipy.org/scipy/ticket/412 and 868.
>
> Are you able to check these? It would be good to get rid of some
> segfaults in ndimage.

It's not directly related, but I can look into it.

How general should label/index types be?  I'd be happy if it accepted
arbitrary scalar arrays for labels and single scalars or sequences for
the index.  I 'd rather not implement something that would accept
arbitrary types in the label array (i.e., strings or lists).

I think I addressed the segmentation fault from ticket 868, but will
add a test for that to be sure.

Ray Jones


From zachary.pincus at yale.edu  Sun Apr 19 09:55:29 2009
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Sun, 19 Apr 2009 09:55:29 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
Message-ID: <038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>

> I don't believe so.  I considered that, but there have to be some
> changes made to the C code to handle empty lists and better error
> checking, so figured I'd keep most of the changes in the same file.

I figured the wrapper could could just not even bother calling into C  
in the case of an empty list? But in any case, additional error  
checking is good.

> Each of the functions calling statistics() could wrap it with
> something that does the right thing with the return value given the
> type of index().  Let me know if you think that would be cleaner.

Not sure if it would be cleaner to keep it in python, but I figured  
there would be a lower potential for bugs. Since this patch is already  
written, it's probably easiest to use it, and I'll give it a close read.

Also the tickets Josef pointed out are related, and at least 868 needs  
fixing. Should those checks be in C or python? (I'm not sure what  
functional limitation is actually imposed by the bug in 412...)

Zach



> Ray
>
> On Sat, Apr 18, 2009 at 20:16, Zachary Pincus  
> <zachary.pincus at yale.edu> wrote:
>> I'm looking over the patch currently, but let me ask a quick question
>> first: is there a performance (or other) reason to not just do the
>> list-wrapping/unwrapping thing in Python, rather than in the C code?
>>
>> Zach
>>
>>
>>
>>
>> On Apr 18, 2009, at 7:28 PM, Thouis (Ray) Jones wrote:
>>
>>> My last patch did not do the right thing for ndimage.extrema(),  
>>> which
>>> needs to return 4 values with the same semantics.  I've attached an
>>> addendum.
>>>
>>> Ray Jones
>>>
>>>
>>> On Sat, Apr 18, 2009 at 16:47, Thouis (Ray) Jones <thouis at broad.mit.edu
>>>> wrote:
>>>> Here's a first attempt at a patch.  It fixes the corner case of a
>>>> single index to match the index type (scalar for scalar, list for
>>>> single element sequence), also the case of index=[] to return []  
>>>> for
>>>> any measurement.  Finally, it improves type checking of the index
>>>> type, which was only being checked for sum() and not any of the  
>>>> other
>>>> measurements (?).
>>>>
>>>> Zach, would you mind reviewing?  If it looks good, I'll add some
>>>> tests
>>>> for the new functionality and submit a patch via trac.
>>>>
>>>> Ray
>>>>
>>>> On Fri, Apr 17, 2009 at 22:06, Zachary Pincus <zachary.pincus at yale.edu
>>>>> wrote:
>>>>>> Current behavior:
>>>>>>>>> from scipy import ndimage
>>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1,2])
>>>>>> [1.0, 4.0]
>>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=[1])
>>>>>> 1.0
>>>>>>>>> ndimage.maximum([[1,2], [3,4]], [[1,0],[0,2]], index=1)
>>>>>> 1.0
>>>>>>
>>>>>> I think the second result should be [1.0].  We're using the  
>>>>>> ndimage
>>>>>> code for image processing, and have to wrap the measurement
>>>>>> functions
>>>>>> to make the code general for the case where there is only one
>>>>>> object
>>>>>> in the image.
>>>>>
>>>>> I've run into this too, and had the same thought. It's such a
>>>>> corner-
>>>>> case that it doesn't seem like gratuitous API-breakage to make  
>>>>> this
>>>>> fix...
>>>>>
>>>>> Zach
>>>>> _______________________________________________
>>>>> Scipy-dev mailing list
>>>>> Scipy-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>>>
>>>>
>>> <0002-special-case-for-
>>> extrema.patch>_______________________________________________
>>> 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 thouis at broad.mit.edu  Sun Apr 19 10:31:13 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Sun, 19 Apr 2009 10:31:13 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com> 
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com> 
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com> 
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com> 
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
Message-ID: <6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>

On Sun, Apr 19, 2009 at 09:55, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> I don't believe so. ?I considered that, but there have to be some
>> changes made to the C code to handle empty lists and better error
>> checking, so figured I'd keep most of the changes in the same file.
>
> I figured the wrapper could could just not even bother calling into C
> in the case of an empty list? But in any case, additional error
> checking is good.


I'll take a deeper look at the whole thing, and write up a new patch.
You can probably hold off reviewing the old one, Zach.  I will
probably move the index/result agreement to python, as long as I'm
making significant changes.

I don't think the label & index arguments need to handle arbitrary
types (so no complex, object, or string arrays).  However, the code
could be written to do so.  Opinions?

Ray Jones


From josef.pktd at gmail.com  Sun Apr 19 12:24:14 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 19 Apr 2009 12:24:14 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>
Message-ID: <1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>

On Sun, Apr 19, 2009 at 10:31 AM, Thouis (Ray) Jones <thouis at broad.mit.edu>
wrote:
> On Sun, Apr 19, 2009 at 09:55, Zachary Pincus <zachary.pincus at yale.edu>
wrote:
>>> I don't believe so.  I considered that, but there have to be some
>>> changes made to the C code to handle empty lists and better error
>>> checking, so figured I'd keep most of the changes in the same file.
>>
>> I figured the wrapper could could just not even bother calling into C
>> in the case of an empty list? But in any case, additional error
>> checking is good.
>
>
> I'll take a deeper look at the whole thing, and write up a new patch.
> You can probably hold off reviewing the old one, Zach.  I will
> probably move the index/result agreement to python, as long as I'm
> making significant changes.
>
> I don't think the label & index arguments need to handle arbitrary
> types (so no complex, object, or string arrays).  However, the code
> could be written to do so.  Opinions?

The main person that has an opinion about ndimage is Stefan.

The long term intention is to rewrite ndimage in cython, but I don't think
this will happen anytime soon.

Since I'm not used to reading python interface code in c, I never looked at
the details of ticket 412.

My opinion is that it is easy to convert labels and index to integers, so if
ndimage only handles index of type long (and makes a type check) this should
be enough.

However, as ticket 412 indicates, if the generality of types is already in
labels, then index could just match the type restriction of labels. I tried
out some types, see below.  labels can be floating point, but not string or
complex. There was a question recently on the mailing list asking for a
function, where he could have used ndimage.measurements if it supported
floats.

So, if you are able to allow for floating point index, same as for labels,
then this looks to me like a clean solution, that just extends the current
functionality in a consistent way.

Josef


import numpy as np
from scipy import ndimage

input_ =  [0,1,2,3]
labels = [1,1,2,2]
print ndimage.sum(input_, labels, index=[1,2])

# these raises runtime error data type not supported
#print ndimage.sum(np.array(input_).astype(str), labels, index=[1,2])
#print ndimage.sum(input_, np.array(labels).astype(str))
# this works
print ndimage.sum(input_, np.array(labels).astype(float))
# this works
print ndimage.sum(input_, np.array(labels).astype(float),
                 np.array(np.unique(labels)))
print ndimage.sum(input_, np.array(labels).astype('float64'))
# these raises runtime error data type not supported
#print ndimage.sum(input_, np.array(labels).astype('complex64'))

# this segfaults:
#print ndimage.sum(input_, np.array(labels).astype(float),
#                          np.array(np.unique(labels)).astype(float))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090419/0338679c/attachment.html>

From stefan at sun.ac.za  Sun Apr 19 19:40:24 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 20 Apr 2009 01:40:24 +0200
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com> 
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com> 
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com> 
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com> 
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com> 
	<1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>
Message-ID: <9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>

2009/4/19  <josef.pktd at gmail.com>:
> The long term intention is to rewrite ndimage in cython, but I don't think
> this will happen anytime soon.

I wish it could, though -- it would save us so much time, and I think
it is doable in two months by a dedicated student.  Does anyone have
some free time to spare, or some money to pay for a student?

Ndimage is a tremendously useful package; it just needs a bit of love.

> My opinion is that it is easy to convert labels and index to integers, so if
> ndimage only handles index of type long (and makes a type check) this should
> be enough.

That should be fine.

With Cython, a type conversion is trivial to do  Ndimage was based on
Numeric -- but with NumPy many of its operations can be done using
fancy indexing and broadcasting.  A slight decrease in speed for a
massive improvement in readability.

Regards
St?fan


From cournape at gmail.com  Sun Apr 19 21:59:56 2009
From: cournape at gmail.com (David Cournapeau)
Date: Mon, 20 Apr 2009 10:59:56 +0900
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>
	<1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>
	<9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>
Message-ID: <5b8d13220904191859v1282fe80u61abad1d55d0a23b@mail.gmail.com>

2009/4/20 St?fan van der Walt <stefan at sun.ac.za>:

>
> With Cython, a type conversion is trivial to do ?Ndimage was based on
> Numeric -- but with NumPy many of its operations can be done using
> fancy indexing and broadcasting. ?A slight decrease in speed for a
> massive improvement in readability.

Having a fast code which crashes and that nobody can maintain is not
that useful anyway :)

David


From josef.pktd at gmail.com  Mon Apr 20 00:03:22 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 20 Apr 2009 00:03:22 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <5b8d13220904191859v1282fe80u61abad1d55d0a23b@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>
	<1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>
	<9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>
	<5b8d13220904191859v1282fe80u61abad1d55d0a23b@mail.gmail.com>
Message-ID: <1cd32cbb0904192103x14774ebat91cfd6f0bb1d3b90@mail.gmail.com>

On Sun, Apr 19, 2009 at 9:59 PM, David Cournapeau <cournape at gmail.com>wrote:

> 2009/4/20 St?fan van der Walt <stefan at sun.ac.za>:
>
> >
> > With Cython, a type conversion is trivial to do  Ndimage was based on
> > Numeric -- but with NumPy many of its operations can be done using
> > fancy indexing and broadcasting.  A slight decrease in speed for a
> > massive improvement in readability.
>
> Having a fast code which crashes and that nobody can maintain is not
> that useful anyway :)
>

ndimage has a very good test suite, and as long as correct numbers are given
to ndimage, I think it works very well.  I only use measurements and
correlate. Measurement is the fastest we have to get statistics by labels
and looks useful for stats.

ndimage doesn't look very robust to being given wrong types or numbers,
instead of exceptions we get segfaults. 4 out of 7 tickets are on crashes
with incorrect numbers, 1 ticket (824) could be closed. The missing type
checks or type conversions that cause the crash in this example could be
also be handled on the python side. Ticket 295 is missing a check for an
invalid bound (origin) and crashes.
I'm very glad if someone makes some incremental improvement to the existing
(interface) code as discussed in this thread.

There are not many complaints/tickets about the code itself, no wrong
"images", in contrast to other subpackages of scipy.

But of course, I'm not the one chasing platform specific problems in c code.

Josef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090420/ec265e2b/attachment.html>

From david at ar.media.kyoto-u.ac.jp  Mon Apr 20 02:26:56 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 20 Apr 2009 15:26:56 +0900
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
 if index is a list?
In-Reply-To: <1cd32cbb0904192103x14774ebat91cfd6f0bb1d3b90@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>	<1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>	<9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>	<5b8d13220904191859v1282fe80u61abad1d55d0a23b@mail.gmail.com>
	<1cd32cbb0904192103x14774ebat91cfd6f0bb1d3b90@mail.gmail.com>
Message-ID: <49EC15B0.7090907@ar.media.kyoto-u.ac.jp>

Hi Josef,

josef.pktd at gmail.com wrote:
> There are not many complaints/tickets about the code itself, no wrong
> "images", in contrast to other subpackages of scipy.

If there are crashes that nobody can fix, that's a problem in the long
term. If we have code which is slower than the current version, but in
cython and well written, then people can improve it for speed later. If
the code is bad enough so that nobody fixes it, then it will never be
improved. If ndimage has a good testsuite, then it is possible to
replace C code with cython (it can be done gradually). In my experience,
maintainable and reliable C code for python extensions is hard, and not
that many people are capable of doing it, myself included. There is also
the issue of portability to Py3k.

I am afraid that a lot of code in scipy is in that stage that it is
useful but not that maintainable - I like the "paying the technical
debt" metaphor (http://en.wikipedia.org/wiki/Technical_debt), and I
think we are exactly in that period where we have accumulated a lot of
debt, ndimage being such an example.

cheers,

David


From josef.pktd at gmail.com  Mon Apr 20 16:05:43 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 20 Apr 2009 16:05:43 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <49EC15B0.7090907@ar.media.kyoto-u.ac.jp>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>
	<1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>
	<9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>
	<5b8d13220904191859v1282fe80u61abad1d55d0a23b@mail.gmail.com>
	<1cd32cbb0904192103x14774ebat91cfd6f0bb1d3b90@mail.gmail.com>
	<49EC15B0.7090907@ar.media.kyoto-u.ac.jp>
Message-ID: <1cd32cbb0904201305i310d6573u887eff8e3f24c718@mail.gmail.com>

On Mon, Apr 20, 2009 at 2:26 AM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> Hi Josef,
>
> josef.pktd at gmail.com wrote:
> > There are not many complaints/tickets about the code itself, no wrong
> > "images", in contrast to other subpackages of scipy.
>
> If there are crashes that nobody can fix, that's a problem in the long
> term. If we have code which is slower than the current version, but in
> cython and well written, then people can improve it for speed later. If
> the code is bad enough so that nobody fixes it, then it will never be
> improved. If ndimage has a good testsuite, then it is possible to
> replace C code with cython (it can be done gradually). In my experience,
> maintainable and reliable C code for python extensions is hard, and not
> that many people are capable of doing it, myself included. There is also
> the issue of portability to Py3k.
>
> I am afraid that a lot of code in scipy is in that stage that it is
> useful but not that maintainable - I like the "paying the technical
> debt" metaphor (http://en.wikipedia.org/wiki/Technical_debt), and I
> think we are exactly in that period where we have accumulated a lot of
> debt, ndimage being such an example.
>

I looked a bit more on the segfault with correlate, ticket:295

To raise an exception for the case that currently segfaults, we would only
need to change one inequality

filters.py line 489 (def _correlate_or_convolve)
-  if (lenw // 2 + origin < 0) or (lenw // 2 + origin > lenw):
+ if (lenw // 2 + origin < 0) or (lenw // 2 + origin >= lenw):

however, the case that causes the problem is actually a valid case,
correlate1d has no problems with it

python -c "from scipy import ndimage; print
ndimage.correlate1d([0,1,2,3,4,5],[1,1,2,0],origin=2)"
[7 3 1 2 5 9]

changing the inequality would now raise an exception in this case (instead
of crash):

python -c "from scipy import ndimage; print
ndimage.correlate([0,1,2,3,4,5],[1,1,2,0],origin=2)"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File
"C:\Josef\eclipsegworkspace\scipybranch2\dist\Programs\Python25\Lib\site-
packages\scipy\ndimage\filters.py", line 524, in correlate
    origin, False)
  File
"C:\Josef\eclipsegworkspace\scipybranch2\dist\Programs\Python25\Lib\site-
packages\scipy\ndimage\filters.py", line 497, in _correlate_or_convolve
    raise ValueError, 'invalid origin'
ValueError: invalid origin

(note: my line numbers are different because of debug print statements,
tested for 1d and 2d case)

 Since the segfault occurs at a valid case, I tried to check ni_filters.c,
but after staring at it for a while, I don't see where (presumably) the
memory allocation goes wrong, and given that it requires compilation it's
not so easy to just play with it and debug it like python code. I'm just
glad I never had to learn c/c++.

So, I completely agree, if we have to look for bugs in the c code or if
porting to py3 doesn't work automatically, this code is a big technical
debt.

But in the mean time, we could convert these segfaults to exceptions.

Josef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090420/bf707e7c/attachment.html>

From dwf at cs.toronto.edu  Mon Apr 20 20:33:53 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Mon, 20 Apr 2009 20:33:53 -0400
Subject: [SciPy-dev] Should ndimage.measurements.* should return lists
	if index is a list?
In-Reply-To: <9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>
References: <6c17e6f50904171157i2bc822c1q3e666cce860b6992@mail.gmail.com>
	<18239520-DA02-4895-88C9-B5B21B533011@yale.edu>
	<6c17e6f50904181347u7fabd69cja24f7f14e6dce185@mail.gmail.com>
	<6c17e6f50904181628w6a436f73y19ba43fc5c22badd@mail.gmail.com>
	<35AD1AEA-77B3-498D-96EC-B6A017F15BEA@yale.edu>
	<6c17e6f50904181921l1e29b1ccsecb01903b04ecca2@mail.gmail.com>
	<038EAA37-600A-4249-B8FC-25F5A3DB54D2@yale.edu>
	<6c17e6f50904190731l1af4fe8dsd8570cbdbc16c602@mail.gmail.com>
	<1cd32cbb0904190924i57a72727gaa22567125c23c78@mail.gmail.com>
	<9457e7c80904191640rf05528cve0edfd8228a0bdb7@mail.gmail.com>
Message-ID: <EC23362A-B76C-4C4A-9FD4-85728C737C9F@cs.toronto.edu>


On 19-Apr-09, at 7:40 PM, St?fan van der Walt wrote:

> With Cython, a type conversion is trivial to do  Ndimage was based on
> Numeric -- but with NumPy many of its operations can be done using
> fancy indexing and broadcasting.  A slight decrease in speed for a
> massive improvement in readability.


Slight correction (if it matters): ndimage is from numarray, not  
Numeric. Otherwise, +1.

David

From aahz at pythoncraft.com  Mon Apr 20 20:39:14 2009
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 20 Apr 2009 17:39:14 -0700
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <20090418091406.GA16064@phare.normalesup.org>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com> <20090418005352.GC4950@panix.com>
	<20090418091406.GA16064@phare.normalesup.org>
Message-ID: <20090421003914.GA634@panix.com>

On Sat, Apr 18, 2009, Gael Varoquaux wrote:
>> 
>> Looks likes it's a competition!  ;-)  I would also like edit rights for
>> the same reason, my username is "Aahz" (surprise, surprise).
> 
> I have given both of you edit rights.

Could someone tell me what I've done wrong (if anything) on
numpy.core.defchararray.chararray.endswith?  The Parameters section is
malformatted, and it looks correct to me in reST, so I'm not sure whether
the auto-build is the problem.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair


From andrei.avk at gmail.com  Mon Apr 20 20:46:31 2009
From: andrei.avk at gmail.com (AK)
Date: Mon, 20 Apr 2009 20:46:31 -0400
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <20090421003914.GA634@panix.com>
References: <49E8F8FF.4020508@gmail.com>	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>	<49E8FC2A.8040806@gmail.com>
	<20090418005352.GC4950@panix.com>	<20090418091406.GA16064@phare.normalesup.org>
	<20090421003914.GA634@panix.com>
Message-ID: <49ED1767.9020000@gmail.com>

Aahz wrote:
> On Sat, Apr 18, 2009, Gael Varoquaux wrote:
>   
>>> Looks likes it's a competition!  ;-)  I would also like edit rights for
>>> the same reason, my username is "Aahz" (surprise, surprise).
>>>       
>> I have given both of you edit rights.
>>     
>
> Could someone tell me what I've done wrong (if anything) on
> numpy.core.defchararray.chararray.endswith?  The Parameters section is
> malformatted, and it looks correct to me in reST, so I'm not sure whether
> the auto-build is the problem.
>   
You need empty lines between parameters, I believe.. -andrei (aka RainyDay)


From aahz at pythoncraft.com  Mon Apr 20 20:57:43 2009
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 20 Apr 2009 17:57:43 -0700
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <49ED1767.9020000@gmail.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com> <20090418005352.GC4950@panix.com>
	<20090418091406.GA16064@phare.normalesup.org>
	<20090421003914.GA634@panix.com> <49ED1767.9020000@gmail.com>
Message-ID: <20090421005743.GA931@panix.com>

On Mon, Apr 20, 2009, AK wrote:
> Aahz wrote:
>>
>> Could someone tell me what I've done wrong (if anything) on
>> numpy.core.defchararray.chararray.endswith?  The Parameters section is
>> malformatted, and it looks correct to me in reST, so I'm not sure whether
>> the auto-build is the problem.
>   
> You need empty lines between parameters, I believe.. -andrei (aka RainyDay)

That was my first guess, but numpy.core.multiarray.arange doesn't.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair


From andrei.avk at gmail.com  Mon Apr 20 21:05:52 2009
From: andrei.avk at gmail.com (AK)
Date: Mon, 20 Apr 2009 21:05:52 -0400
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <20090421005743.GA931@panix.com>
References: <49E8F8FF.4020508@gmail.com>	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>	<49E8FC2A.8040806@gmail.com>
	<20090418005352.GC4950@panix.com>	<20090418091406.GA16064@phare.normalesup.org>	<20090421003914.GA634@panix.com>
	<49ED1767.9020000@gmail.com> <20090421005743.GA931@panix.com>
Message-ID: <49ED1BF0.2030109@gmail.com>

Aahz wrote:
> On Mon, Apr 20, 2009, AK wrote:
>   
>> Aahz wrote:
>>     
>>> Could someone tell me what I've done wrong (if anything) on
>>> numpy.core.defchararray.chararray.endswith?  The Parameters section is
>>> malformatted, and it looks correct to me in reST, so I'm not sure whether
>>> the auto-build is the problem.
>>>       
>>   
>> You need empty lines between parameters, I believe.. -andrei (aka RainyDay)
>>     
>
> That was my first guess, but numpy.core.multiarray.arange doesn't.
>   
Ahh, should have tested.. The problem is that all the text is indented. 
Except for descriptions, the lines should have indent of 0.. -andrei


From aahz at pythoncraft.com  Mon Apr 20 21:16:27 2009
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 20 Apr 2009 18:16:27 -0700
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <49ED1BF0.2030109@gmail.com>
References: <49E8F8FF.4020508@gmail.com>
	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>
	<49E8FC2A.8040806@gmail.com> <20090418005352.GC4950@panix.com>
	<20090418091406.GA16064@phare.normalesup.org>
	<20090421003914.GA634@panix.com> <49ED1767.9020000@gmail.com>
	<20090421005743.GA931@panix.com> <49ED1BF0.2030109@gmail.com>
Message-ID: <20090421011627.GA29560@panix.com>

On Mon, Apr 20, 2009, AK wrote:
> Aahz wrote:
>> On Mon, Apr 20, 2009, AK wrote:
>>> Aahz wrote:
>>>     
>>>> Could someone tell me what I've done wrong (if anything) on
>>>> numpy.core.defchararray.chararray.endswith?  The Parameters section is
>>>> malformatted, and it looks correct to me in reST, so I'm not sure whether
>>>> the auto-build is the problem.
>>>   
>>> You need empty lines between parameters, I believe.. -andrei (aka RainyDay)
>>
>> That was my first guess, but numpy.core.multiarray.arange doesn't.
>   
> Ahh, should have tested.. The problem is that all the text is indented. 
> Except for descriptions, the lines should have indent of 0.. -andrei

Thanks!  I started doing it as a regular docstring and didn't realize
that the online editor needed dedenting -- everything else was working.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair


From andrei.avk at gmail.com  Mon Apr 20 21:22:41 2009
From: andrei.avk at gmail.com (AK)
Date: Mon, 20 Apr 2009 21:22:41 -0400
Subject: [SciPy-dev] Request of edit rights
In-Reply-To: <20090421011627.GA29560@panix.com>
References: <49E8F8FF.4020508@gmail.com>	<3d375d730904171451o5451143bs6769af340784597a@mail.gmail.com>	<49E8FC2A.8040806@gmail.com>
	<20090418005352.GC4950@panix.com>	<20090418091406.GA16064@phare.normalesup.org>	<20090421003914.GA634@panix.com>
	<49ED1767.9020000@gmail.com>	<20090421005743.GA931@panix.com>
	<49ED1BF0.2030109@gmail.com> <20090421011627.GA29560@panix.com>
Message-ID: <49ED1FE1.9070101@gmail.com>

Aahz wrote:
> On Mon, Apr 20, 2009, AK wrote:
>   
>> Aahz wrote:
>>     
>>> On Mon, Apr 20, 2009, AK wrote:
>>>       
>>>> Aahz wrote:
>>>>     
>>>>         
>>>>> Could someone tell me what I've done wrong (if anything) on
>>>>> numpy.core.defchararray.chararray.endswith?  The Parameters section is
>>>>> malformatted, and it looks correct to me in reST, so I'm not sure whether
>>>>> the auto-build is the problem.
>>>>>           
>>>>   
>>>> You need empty lines between parameters, I believe.. -andrei (aka RainyDay)
>>>>         
>>> That was my first guess, but numpy.core.multiarray.arange doesn't.
>>>       
>>   
>> Ahh, should have tested.. The problem is that all the text is indented. 
>> Except for descriptions, the lines should have indent of 0.. -andrei
>>     
>
> Thanks!  I started doing it as a regular docstring and didn't realize
> that the online editor needed dedenting -- everything else was working.
>   
No problem! -andrei


From stefan at sun.ac.za  Fri Apr 24 01:00:52 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Apr 2009 07:00:52 +0200
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
Message-ID: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>

Hi all,

Michael Berry has kindly agreed to relicense SVDPACK or SVDPACKC for
use in SciPy.

>From http://www.netlib.org/svdpack/:

"""
SVDPACK comprises four numerical (iterative) methods for computing the
singular value decomposition (SVD) of large sparse matrices using
double precision ANSI Fortran-77. A compatible ANSI-C version
(SVDPACKC) is also available. This software package implements Lanczos
and subspace iteration-based methods for determining several of the
largest singular triplets (singular values and corresponding left- and
right-singular vectors) for large sparse matrices.
"""

He asked that we let him know whether we'd like to use the Fortran or
the C version.  Which would best suit SciPy?  I have a tendency to
prefer SVDPACKC, since we can reach it easily via Cython.

I'd appreciate your feedback.

Regards
St?fan


From ellisonbg.net at gmail.com  Fri Apr 24 01:31:01 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 23 Apr 2009 22:31:01 -0700
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
In-Reply-To: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>
References: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>
Message-ID: <6ce0ac130904232231l2d557743r7fc26410882da40e@mail.gmail.com>

Stefan,

This is fantastic!  I definitely vote for the C version and a cython wrapper.

Brian

2009/4/23 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> Michael Berry has kindly agreed to relicense SVDPACK or SVDPACKC for
> use in SciPy.
>
> >From http://www.netlib.org/svdpack/:
>
> """
> SVDPACK comprises four numerical (iterative) methods for computing the
> singular value decomposition (SVD) of large sparse matrices using
> double precision ANSI Fortran-77. A compatible ANSI-C version
> (SVDPACKC) is also available. This software package implements Lanczos
> and subspace iteration-based methods for determining several of the
> largest singular triplets (singular values and corresponding left- and
> right-singular vectors) for large sparse matrices.
> """
>
> He asked that we let him know whether we'd like to use the Fortran or
> the C version. ?Which would best suit SciPy? ?I have a tendency to
> prefer SVDPACKC, since we can reach it easily via Cython.
>
> I'd appreciate your feedback.
>
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From mellerf at netvision.net.il  Fri Apr 24 02:13:24 2009
From: mellerf at netvision.net.il (Yosef Meller)
Date: Fri, 24 Apr 2009 09:13:24 +0300
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
In-Reply-To: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>
References: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>
Message-ID: <49F15884.4010804@netvision.net.il>

> """
> SVDPACK comprises four numerical (iterative) methods for computing the
> singular value decomposition (SVD) of large sparse matrices using
> double precision ANSI Fortran-77. A compatible ANSI-C version
> (SVDPACKC) is also available. This software package implements Lanczos
> and subspace iteration-based methods for determining several of the
> largest singular triplets (singular values and corresponding left- and
> right-singular vectors) for large sparse matrices.
> """
> 
> He asked that we let him know whether we'd like to use the Fortran or
> the C version.  Which would best suit SciPy?  I have a tendency to
> prefer SVDPACKC, since we can reach it easily via Cython.

Is there a speed difference between the two? If it's significantly 
faster using Fortran, some would prefer it.


From stefan at sun.ac.za  Fri Apr 24 02:44:04 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Apr 2009 08:44:04 +0200
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
In-Reply-To: <49F15884.4010804@netvision.net.il>
References: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com> 
	<49F15884.4010804@netvision.net.il>
Message-ID: <9457e7c80904232344j1e68bceer5e12ff46de793e3d@mail.gmail.com>

2009/4/24 Yosef Meller <mellerf at netvision.net.il>:
> Is there a speed difference between the two? If it's significantly
> faster using Fortran, some would prefer it.

I don't think the Fortran version would be significantly faster, but I
do not have proof.

The benchmarks for SVDPACKC (algorithms) are available in their
technical report:

http://www.netlib.org/tennessee/ut-cs-93-194.ps

Regards
St?fan


From rjsm at umich.edu  Fri Apr 24 03:23:29 2009
From: rjsm at umich.edu (ross smith)
Date: Fri, 24 Apr 2009 03:23:29 -0400
Subject: [SciPy-dev] Gsoc summer student
Message-ID: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>

Hello everyone,
I've been accepted by Google summer of code this year.   I'm a junior at
University of Michigan  Ann arbor studying physics.  I've been 'programming'
since high school.  I began with some short programs in quickbasic.  after
coming to college I've picked up python and been working with it for a
couple years.

I've helped maintain a python codebase for a research lab here and was one
of two students that worked on porting it to Py3k.   My other programming
projects have mostly involved additions to the codebase for labs I've worked
for and an odd bugfix or patch for programs I use frequently.

I'm going to be spending the first part of the summer, getting familiar with
the codebase for SciPy.Signal and doing some cleanup and bug hunting.   The
second part will be focused on improving SciPy.signal and filling some of
the gaps in functionality between SciPy.signal and matlab's signal
processing toolbox.

I usually idle on freenode as gaurdro and aim as gaurdro1 if anyone wants to
talk.


best,

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090424/e6976681/attachment.html>

From stefan at sun.ac.za  Fri Apr 24 03:28:25 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Apr 2009 09:28:25 +0200
Subject: [SciPy-dev] Gsoc summer student
In-Reply-To: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>
References: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>
Message-ID: <9457e7c80904240028o33cc44f7pf0dc2883d233ded8@mail.gmail.com>

Hi Ross

2009/4/24 ross smith <rjsm at umich.edu>:
> I'm going to be spending the first part of the summer, getting familiar with
> the codebase for SciPy.Signal and doing some cleanup and bug hunting.?? The
> second part will be focused on improving SciPy.signal and filling some of
> the gaps in functionality between SciPy.signal and matlab's signal
> processing toolbox.

Welcome!  We are glad to have you, and look forward to a productive
summer of code!

Regards
St?fan


From dwf at cs.toronto.edu  Fri Apr 24 04:34:07 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Fri, 24 Apr 2009 04:34:07 -0400
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
In-Reply-To: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>
References: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com>
Message-ID: <D66EED2A-023B-44D6-B86B-17C5B4B72151@cs.toronto.edu>

On 24-Apr-09, at 1:00 AM, St?fan van der Walt wrote:

> Hi all,
>
> Michael Berry has kindly agreed to relicense SVDPACK or SVDPACKC for
> use in SciPy.

Hmm, I thought that sparse SVD was provided by ARPACK, already  
included in SciPy, and it was just a matter of writing the wrappers.  
Is that still the case, or is SVDPACK for some reason a substantially  
easier route/is SVDPACK better or more featureful?

That said: I think you're right about preferring SVDPACKC, Stefan.  
WIth all of the annoying issues surrounding Fortran compilers and  
ABIs, it seems to me that the less new Fortran code gets added to  
SciPy, the better.

David

From jsseabold at gmail.com  Fri Apr 24 10:41:39 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Fri, 24 Apr 2009 10:41:39 -0400
Subject: [SciPy-dev] Gsoc summer student
In-Reply-To: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>
References: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>
Message-ID: <c048da1c0904240741m7a1d2532oe7b323f7d8ee5ae9@mail.gmail.com>

On Fri, Apr 24, 2009 at 3:23 AM, ross smith <rjsm at umich.edu> wrote:
> Hello everyone,
> I've been accepted by Google summer of code this year. ? I'm a junior at
> University of Michigan ?Ann arbor studying physics. ?I've been 'programming'
> since high school. ?I began with some short programs in quickbasic. ?after
> coming to college I've picked up python and been working with it for a
> couple years.
> I've helped maintain a python codebase for a research lab here and was one
> of two students that worked on porting it to Py3k.?? My other programming
> projects have mostly involved additions to the codebase for labs I've worked
> for and an odd bugfix or patch for programs I use frequently.
>
> I'm going to be spending the first part of the summer, getting familiar with
> the codebase for SciPy.Signal and doing some cleanup and bug hunting.?? The
> second part will be focused on improving SciPy.signal and filling some of
> the gaps in functionality between SciPy.signal and matlab's signal
> processing toolbox.
>
> I usually idle on freenode as gaurdro and aim as gaurdro1 if anyone wants to
> talk.
>
>
> best,
>
> Ross
>

Hello Ross and All,

I was also accepted into GSoC for this year to work on SciPy, and I
thought I'd continue this as an introductions thread.  My name is
Skipper Seabold, and I'm a PhD student in economics at American
University in DC.

I will be working on providing a consistent user interface and
development framework for statistical models in SciPy.  At the request
of GSoC I will be maintaining a blog about the project, you can learn
more and follow the progress of my work at
<http://scipystats.blogspot.com>.

I also idle on freenode as jseabold.

Looking forward to the summer and beyond!

Best,

Skipper


From stefan at sun.ac.za  Fri Apr 24 10:54:38 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Apr 2009 16:54:38 +0200
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
In-Reply-To: <D66EED2A-023B-44D6-B86B-17C5B4B72151@cs.toronto.edu>
References: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com> 
	<D66EED2A-023B-44D6-B86B-17C5B4B72151@cs.toronto.edu>
Message-ID: <9457e7c80904240754m4cdb0d8dg1e7e3d4c2ac6074d@mail.gmail.com>

2009/4/24 David Warde-Farley <dwf at cs.toronto.edu>:
> Hmm, I thought that sparse SVD was provided by ARPACK, already
> included in SciPy, and it was just a matter of writing the wrappers.
> Is that still the case, or is SVDPACK for some reason a substantially
> easier route/is SVDPACK better or more featureful?

I guess there are trade-offs between the algorithms, but I can't give
you any details yet.

When I mailed Michael Berry, the author of SVDPACKC, a while ago, he wrote:

"""
We used Lanczos, Subspace Iteration, and Trace Minimization algorithms
for developing svdpack and svdpackc.  The Lanczos routines (las1 and
las2) are fairly robust for computing extremal s-triplets - not the
entire spectrum.  You can also evaluate ARPACK which is also in NETLIB
and is based on Arnoldi methods (similar to Lanczos).
"""

What I do know is that the ARPACK in SciPy currently does not contain
code for the SVD.  The code can be found in

http://www.caam.rice.edu/software/ARPACK/SRC/arpack96.tar.gz

as ARPACK/EXAMPLES/SVD/ssvd.f.

Regards
St?fan


From stefan at sun.ac.za  Fri Apr 24 11:07:53 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Apr 2009 17:07:53 +0200
Subject: [SciPy-dev] Gsoc summer student
In-Reply-To: <c048da1c0904240741m7a1d2532oe7b323f7d8ee5ae9@mail.gmail.com>
References: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com> 
	<c048da1c0904240741m7a1d2532oe7b323f7d8ee5ae9@mail.gmail.com>
Message-ID: <9457e7c80904240807g54ac7c5vfe556088dbc9183a@mail.gmail.com>

2009/4/24 Skipper Seabold <jsseabold at gmail.com>:
> I will be working on providing a consistent user interface and
> development framework for statistical models in SciPy. ?At the request
> of GSoC I will be maintaining a blog about the project, you can learn
> more and follow the progress of my work at
> <http://scipystats.blogspot.com>.

That's great -- I hope to see Jonathan's package make its return!
Please ask Jarrod to add you to planets.scipy.org, the SciPy blog
aggregator.

Cheers
St?fan


From stefan at sun.ac.za  Fri Apr 24 14:54:18 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Apr 2009 20:54:18 +0200
Subject: [SciPy-dev] Sparse SVD in SciPy -- SVDPACK[C] made available
In-Reply-To: <9457e7c80904240754m4cdb0d8dg1e7e3d4c2ac6074d@mail.gmail.com>
References: <9457e7c80904232200g4e9d72ecn673e1a302d6c51ae@mail.gmail.com> 
	<D66EED2A-023B-44D6-B86B-17C5B4B72151@cs.toronto.edu>
	<9457e7c80904240754m4cdb0d8dg1e7e3d4c2ac6074d@mail.gmail.com>
Message-ID: <9457e7c80904241154v328021fbm33410904c6f17efc@mail.gmail.com>

2009/4/24 St?fan van der Walt <stefan at sun.ac.za>:
> 2009/4/24 David Warde-Farley <dwf at cs.toronto.edu>:
>> Hmm, I thought that sparse SVD was provided by ARPACK, already
>> included in SciPy, and it was just a matter of writing the wrappers.
>> Is that still the case, or is SVDPACK for some reason a substantially
>> easier route/is SVDPACK better or more featureful?

Michael Berry also wrote:

"""
Our codes are engineered to compute extremal singular values and
singular vectors.  If ARPACK can approximate the entire spectrum,
you might want to go with those routines.
"""

St?fan


From nwagner at iam.uni-stuttgart.de  Mon Apr 27 03:02:33 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 27 Apr 2009 09:02:33 +0200
Subject: [SciPy-dev] SVD
Message-ID: <web-119463085@uni-stuttgart.de>

Hi all,

FWIW, you can find
a collection of numerically singular matrices that arise 
in real applications or that have characteristic features 
of problems from practice at

http://www.math.sjsu.edu/singular/matrices/
  
Nils


From david.huard at gmail.com  Mon Apr 27 09:42:00 2009
From: david.huard at gmail.com (David Huard)
Date: Mon, 27 Apr 2009 09:42:00 -0400
Subject: [SciPy-dev] Gsoc summer student
In-Reply-To: <9457e7c80904240807g54ac7c5vfe556088dbc9183a@mail.gmail.com>
References: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>
	<c048da1c0904240741m7a1d2532oe7b323f7d8ee5ae9@mail.gmail.com>
	<9457e7c80904240807g54ac7c5vfe556088dbc9183a@mail.gmail.com>
Message-ID: <91cf711d0904270642g76fc3d31g9e621b5ddbbc7576@mail.gmail.com>

Congratulations to you both,

Having GSoC participants work full time on SciPy is really motivating for
occasional contributors such as myself.

Have a great time,

David

2009/4/24 St?fan van der Walt <stefan at sun.ac.za>

> 2009/4/24 Skipper Seabold <jsseabold at gmail.com>:
> > I will be working on providing a consistent user interface and
> > development framework for statistical models in SciPy.  At the request
> > of GSoC I will be maintaining a blog about the project, you can learn
> > more and follow the progress of my work at
> > <http://scipystats.blogspot.com>.
>
> That's great -- I hope to see Jonathan's package make its return!
> Please ask Jarrod to add you to planets.scipy.org, the SciPy blog
> aggregator.
>
> Cheers
> St?fan
> _______________________________________________
> 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/20090427/a64881cc/attachment.html>

From martyfuhry at gmail.com  Mon Apr 27 13:54:56 2009
From: martyfuhry at gmail.com (Marty Fuhry)
Date: Mon, 27 Apr 2009 13:54:56 -0400
Subject: [SciPy-dev] Gsoc summer student
In-Reply-To: <91cf711d0904270642g76fc3d31g9e621b5ddbbc7576@mail.gmail.com>
References: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com> 
	<c048da1c0904240741m7a1d2532oe7b323f7d8ee5ae9@mail.gmail.com> 
	<9457e7c80904240807g54ac7c5vfe556088dbc9183a@mail.gmail.com> 
	<91cf711d0904270642g76fc3d31g9e621b5ddbbc7576@mail.gmail.com>
Message-ID: <b4c768ae0904271054h23f69d44q3261f91b720852f0@mail.gmail.com>

Thought I'd drop my name here, too. I'm Marty Fuhry and I was also
accepted to work on NumPy for the Google Summer of Code. I'm a
sophomore studying Mathematics and Computer Science at Kent State
University in Ohio.

My project to implement a Date / Time type for NumPy. There will be
two temporal types for both relative and absolute dates. I'll be
looking into the Date class from the
scikits.timeseries package to plug into my project.

I'll also be keeping a blog of my progress at
www.fuhrysoc.blogspot.com. Looking forward to an exciting summer!


On Mon, Apr 27, 2009 at 9:42 AM, David Huard <david.huard at gmail.com> wrote:
> Congratulations to you both,
>
> Having GSoC participants work full time on SciPy is really motivating for
> occasional contributors such as myself.
>
> Have a great time,
>
> David
>
> 2009/4/24 St?fan van der Walt <stefan at sun.ac.za>
>>
>> 2009/4/24 Skipper Seabold <jsseabold at gmail.com>:
>> > I will be working on providing a consistent user interface and
>> > development framework for statistical models in SciPy. ?At the request
>> > of GSoC I will be maintaining a blog about the project, you can learn
>> > more and follow the progress of my work at
>> > <http://scipystats.blogspot.com>.
>>
>> That's great -- I hope to see Jonathan's package make its return!
>> Please ask Jarrod to add you to planets.scipy.org, the SciPy blog
>> aggregator.
>>
>> Cheers
>> St?fan
>> _______________________________________________
>> 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 pgmdevlist at gmail.com  Mon Apr 27 14:13:00 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 27 Apr 2009 14:13:00 -0400
Subject: [SciPy-dev] Gsoc summer student
In-Reply-To: <b4c768ae0904271054h23f69d44q3261f91b720852f0@mail.gmail.com>
References: <73531abb0904240023x4ccd314v57a99643306f49e4@mail.gmail.com>
	<c048da1c0904240741m7a1d2532oe7b323f7d8ee5ae9@mail.gmail.com>
	<9457e7c80904240807g54ac7c5vfe556088dbc9183a@mail.gmail.com>
	<91cf711d0904270642g76fc3d31g9e621b5ddbbc7576@mail.gmail.com>
	<b4c768ae0904271054h23f69d44q3261f91b720852f0@mail.gmail.com>
Message-ID: <8C0EC900-817A-4B76-902A-58EFDAE426EA@gmail.com>

Ciao Marty,
Welcome on board ! Thanks for the link to your blog, I was about to  
ask you about it. Make sure you post the link to the GSOC mailing list  
as well.
As usual, don't hesitate to contact me on or off-list if you need  
anything.
Cheers
P.


On Apr 27, 2009, at 1:54 PM, Marty Fuhry wrote:

> Thought I'd drop my name here, too. I'm Marty Fuhry and I was also
> accepted to work on NumPy for the Google Summer of Code. I'm a
> sophomore studying Mathematics and Computer Science at Kent State
> University in Ohio.
>
> My project to implement a Date / Time type for NumPy. There will be
> two temporal types for both relative and absolute dates. I'll be
> looking into the Date class from the
> scikits.timeseries package to plug into my project.
>
> I'll also be keeping a blog of my progress at
> www.fuhrysoc.blogspot.com. Looking forward to an exciting summer!
>
>
> On Mon, Apr 27, 2009 at 9:42 AM, David Huard <david.huard at gmail.com>  
> wrote:
>> Congratulations to you both,
>>
>> Having GSoC participants work full time on SciPy is really  
>> motivating for
>> occasional contributors such as myself.
>>
>> Have a great time,
>>
>> David
>>
>> 2009/4/24 St?fan van der Walt <stefan at sun.ac.za>
>>>
>>> 2009/4/24 Skipper Seabold <jsseabold at gmail.com>:
>>>> I will be working on providing a consistent user interface and
>>>> development framework for statistical models in SciPy.  At the  
>>>> request
>>>> of GSoC I will be maintaining a blog about the project, you can  
>>>> learn
>>>> more and follow the progress of my work at
>>>> <http://scipystats.blogspot.com>.
>>>
>>> That's great -- I hope to see Jonathan's package make its return!
>>> Please ask Jarrod to add you to planets.scipy.org, the SciPy blog
>>> aggregator.
>>>
>>> Cheers
>>> St?fan
>>> _______________________________________________
>>> 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 david at ar.media.kyoto-u.ac.jp  Wed Apr 29 05:35:49 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 29 Apr 2009 18:35:49 +0900
Subject: [SciPy-dev] How to handle code contribution with GSoC students ?
Message-ID: <49F81F75.5040102@ar.media.kyoto-u.ac.jp>

Hi,

    I was wondering about the best way to handle code by students for
the upcoming GSoC. The year I participated, I already had write access,
so the question did not come up. I think I would prefer starting with
code reviews, before giving them svn write access later. Do people have
better suggestions ?

cheers,

David


From nwagner at iam.uni-stuttgart.de  Wed Apr 29 09:06:15 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 29 Apr 2009 15:06:15 +0200
Subject: [SciPy-dev] scikits odes example planarpendulum_ida.py
Message-ID: <web-119575377@uni-stuttgart.de>

Hi Benny,
  
I just run the new example planarpendulum_ida.py

Can you reproduce the AttributeErrors (see below) ?


python docs/src/examples/planarpendulum_ida.py
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py:371: 
UserWarning: matplotlibrc text.usetex can not be used with 
*Agg backend unless dvipng-1.5 or later is installed on 
your system
   warnings.warn( 'matplotlibrc text.usetex can not be 
used with *Agg '
started from z0 =  [ 0.86575984 -0.50045969  0. 
         0.          0.1       ]
initial condition calculated, [z,zprime] = [ 
[0.86575983949234436, -0.50045968900820581, 0.0, 0.0, 
0.50045968901834781] [-2.9416572526260959e-07, 
1.700449485844178e-07, -0.43327790003400429, 
-0.74954009965926327, -1.0] ]
last sol [-0.06675332 -0.99777846  0.99507358 -0.06657502 
 1.99234658] [ 0.99507565 -0.06657258  0.13298731 
 0.98792826  0.19969072]
has residual:  [ -2.06966270e-06  -2.43986652e-06 
  8.42570737e-06  -7.77048074e-06
   -2.55736431e-08]
Exception exceptions.AttributeError: "'NoneType' object 
has no attribute 'c_void_p'" in <bound method 
IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at 
0x2a9c8b6f90>> ignored
Exception exceptions.AttributeError: "'NoneType' object 
has no attribute 'c_void_p'" in <bound method 
IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at 
0x2a9c8b6e90>> ignored
Exception exceptions.AttributeError: "'NoneType' object 
has no attribute 'c_void_p'" in <bound method 
IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at 
0x2a9c8b65d0>> ignored
Exception exceptions.AttributeError: "'NoneType' object 
has no attribute 'c_void_p'" in <bound method 
IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at 
0x2a9c8b62d0>> ignored

Nils


From benny.malengier at gmail.com  Wed Apr 29 09:18:36 2009
From: benny.malengier at gmail.com (Benny Malengier)
Date: Wed, 29 Apr 2009 15:18:36 +0200
Subject: [SciPy-dev] scikits odes example planarpendulum_ida.py
In-Reply-To: <web-119575377@uni-stuttgart.de>
References: <web-119575377@uni-stuttgart.de>
Message-ID: <bcafe8290904290618vaa8c89as381fc69310c22612@mail.gmail.com>

Beware Experimental code :-)

I have them too. Have too look into it. It is part of unallocating memory in
(py)sundials

Benny

2009/4/29 Nils Wagner <nwagner at iam.uni-stuttgart.de>

> Hi Benny,
>
> I just run the new example planarpendulum_ida.py
>
> Can you reproduce the AttributeErrors (see below) ?
>
>
> python docs/src/examples/planarpendulum_ida.py
>
> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py:371:
> UserWarning: matplotlibrc text.usetex can not be used with
> *Agg backend unless dvipng-1.5 or later is installed on
> your system
>   warnings.warn( 'matplotlibrc text.usetex can not be
> used with *Agg '
> started from z0 =  [ 0.86575984 -0.50045969  0.
>         0.          0.1       ]
> initial condition calculated, [z,zprime] = [
> [0.86575983949234436, -0.50045968900820581, 0.0, 0.0,
> 0.50045968901834781] [-2.9416572526260959e-07,
> 1.700449485844178e-07, -0.43327790003400429,
> -0.74954009965926327, -1.0] ]
> last sol [-0.06675332 -0.99777846  0.99507358 -0.06657502
>  1.99234658] [ 0.99507565 -0.06657258  0.13298731
>  0.98792826  0.19969072]
> has residual:  [ -2.06966270e-06  -2.43986652e-06
>  8.42570737e-06  -7.77048074e-06
>   -2.55736431e-08]
> Exception exceptions.AttributeError: "'NoneType' object
> has no attribute 'c_void_p'" in <bound method
> IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at
> 0x2a9c8b6f90>> ignored
> Exception exceptions.AttributeError: "'NoneType' object
> has no attribute 'c_void_p'" in <bound method
> IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at
> 0x2a9c8b6e90>> ignored
> Exception exceptions.AttributeError: "'NoneType' object
> has no attribute 'c_void_p'" in <bound method
> IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at
> 0x2a9c8b65d0>> ignored
> Exception exceptions.AttributeError: "'NoneType' object
> has no attribute 'c_void_p'" in <bound method
> IdaMemObj.__del__ of <pysundials.ida.IdaMemObj object at
> 0x2a9c8b62d0>> ignored
>
> Nils
> _______________________________________________
> 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/20090429/bdb8f230/attachment.html>

From benny.malengier at gmail.com  Wed Apr 29 09:46:59 2009
From: benny.malengier at gmail.com (Benny Malengier)
Date: Wed, 29 Apr 2009 15:46:59 +0200
Subject: [SciPy-dev] scikits odes example planarpendulum_ida.py
In-Reply-To: <bcafe8290904290618vaa8c89as381fc69310c22612@mail.gmail.com>
References: <web-119575377@uni-stuttgart.de>
	<bcafe8290904290618vaa8c89as381fc69310c22612@mail.gmail.com>
Message-ID: <bcafe8290904290646o485ef976i1e38e12aa7fbd454@mail.gmail.com>

Nils,

As you appear to be interested. You think it would be usefull to add cvode
as an ode integrator as is done here for ida? That is the present version of
the old fortran vode used in odepack of scipy (
https://computation.llnl.gov/casc/sundials/main.html).

This is all possible thanks to the great work of the people of pysundials.
Working with pysundials directly however means you need to understand the
sundials method clearly. Wrapping this wrapper as done in the odesIDA solver
makes calling it from the known numpy syntax really easy.

For all those interested, I only add features of the solvers as I need them
myself in my research, so no Krylov solvers or sensitivity and such. It
would be easy to add though, should people want to collaborate in extending
the possibilities, just let me know.

Benny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090429/052e33d6/attachment.html>

From stefan at sun.ac.za  Wed Apr 29 10:44:08 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 29 Apr 2009 16:44:08 +0200
Subject: [SciPy-dev] How to handle code contribution with GSoC students ?
In-Reply-To: <49F81F75.5040102@ar.media.kyoto-u.ac.jp>
References: <49F81F75.5040102@ar.media.kyoto-u.ac.jp>
Message-ID: <9457e7c80904290744y1bbb3750scaa1e53bf8d4cf28@mail.gmail.com>

2009/4/29 David Cournapeau <david at ar.media.kyoto-u.ac.jp>:
> ? ?I was wondering about the best way to handle code by students for
> the upcoming GSoC. The year I participated, I already had write access,
> so the question did not come up. I think I would prefer starting with
> code reviews, before giving them svn write access later. Do people have
> better suggestions ?

It's a good time to learn about distributed revision control :)  So
yes, let's have review branches.

Cheers
St?fan


From hazelnusse at gmail.com  Thu Apr 30 00:07:21 2009
From: hazelnusse at gmail.com (Luke)
Date: Wed, 29 Apr 2009 21:07:21 -0700
Subject: [SciPy-dev] Matlab Control System Toolbox for Python / SciPy
Message-ID: <99214b470904292107u7702cceagcb9b1274ba8a1a45@mail.gmail.com>

Does anybody know of any projects that aim to implement much of the
functionality of the control system toolbox in Matlab?  There is a
control system toolbox for Octave, with what looks like a large amount
of similar tools, but I haven't really found anything for Python.

Is anybody out there interested in using and/or developing such a set of tools?

~Luke


From ilanschnell at gmail.com  Thu Apr 30 15:59:27 2009
From: ilanschnell at gmail.com (Ilan Schnell)
Date: Thu, 30 Apr 2009 14:59:27 -0500
Subject: [SciPy-dev] EPD 4.2.30201 released
Message-ID: <2fbe16300904301259h6c6e3126g96587268e3f52a69@mail.gmail.com>

Hello,

I am pleased to announce that EPD (Enthought Python Distribution) version
4.2.30201 has been released.  You may find more information about EPD, as
well as download a 30 day free trial here:

        http://www.enthought.com/products/epd.php

You can check out the release notes here:

        https://svn.enthought.com/epd/wiki/Py25/4.2.30201/RelNotes


About EPD
---------
The Enthought Python Distribution (EPD) is a "kitchen-sink-included"
distribution of the Python Programming Language, including over 80
additional tools and libraries. The EPD bundle includes NumPy, SciPy,
IPython, 2D and 3D visualization, database adapters, and a lot of
other tools right out of the box.

        http://www.enthought.com/products/epdlibraries.php

It is currently available as a single-click installer for Windows XP (x86),
Mac OS X (a universal binary for OS X 10.4 and above),
RedHat 3, 4 and 5 (x86 and amd64), as well as Solaris 10 (x86).

EPD is free for academic use.  An annual subscription including installation
support is available for individual and commercial use.  Additional
support options, including customization, bug fixes and training classes
are also available:

        http://www.enthought.com/products/support_level_table.php


- Ilan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090430/b6e1b373/attachment.html>

From gael.varoquaux at normalesup.org  Thu Apr 30 16:02:48 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 30 Apr 2009 22:02:48 +0200
Subject: [SciPy-dev] [Enthought-dev] EPD 4.2.30201 released
In-Reply-To: <49FA0239.5030709@enthought.com>
References: <49FA0239.5030709@enthought.com>
Message-ID: <20090430200248.GA18291@phare.normalesup.org>

On Thu, Apr 30, 2009 at 02:55:37PM -0500, Ilan Schnell wrote:
> Hello,

> I am pleased to announce that EPD (Enthought Python Distribution) version
> 4.2.30201 has been released.  You may find more information about EPD, as
> well as download a 30 day free trial here:

Congratulations to all the team!

Ga?l