From Fernando.Perez at colorado.edu  Tue Feb  1 01:35:06 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 31 Jan 2005 23:35:06 -0700
Subject: [SciPy-dev] distutils sprint at pycon
Message-ID: <41FF231A.10306@colorado.edu>

Hi all,

I just saw this:

http://www.mechanicalcat.net/richard/log/Python/Distutils_sprinting_at_PyCon

I won't be going to pycon, but if anyone with distutils experience here is 
going it might be worth mentioning scipy's trials and tribulations in this 
area.  Most of us here who have distributed packages have our list of things 
to hate about distutils, but scipy probably has the longest.  It would be 
great if some of the (major) improvements which scipy has made to distutils 
were folded into the core.

Even if the scipy/distutils gurus aren't going to PyCon, it might be worth 
getting in touch with the sprint people.

Just a thought.

Regards,

f



From jdhunter at ace.bsd.uchicago.edu  Tue Feb  1 17:27:18 2005
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Tue, 01 Feb 2005 16:27:18 -0600
Subject: [SciPy-dev] Python (Enthought Edition) for Windows test release
In-Reply-To: <41EDF500.5070302@enthought.com> (Joe Cooper's message of "Tue,
	18 Jan 2005 23:49:52 -0600")
References: <41EDF500.5070302@enthought.com>
Message-ID: <m3651buda1.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Joe" == Joe Cooper <joe at enthought.com> writes:

    Joe> Hi all, The much anticipated new release of the Enthought
    Joe> Edition of Python (a.k.a. Enthon) is just about ready for
    Joe> release into the real world. I'd like for some of you brave
    Joe> developer-type folks to give it a go before I announce it
    Joe> more widely and link it from the Enthon home page.

Sorry to bring this up so late in the game, but it appears numarray is
not in this test release.  Is this correct?  If so, it seems like a
glaring omission for a scientific computing python rollup.  Since
numarray offers functionality not found elsewhere, it would be nice to
have.

Or have I got my local win32 system screwed up with 4 (count em 4!)
python installs?

JDH



From nwagner at mecha.uni-stuttgart.de  Wed Feb  2 05:32:58 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 02 Feb 2005 11:32:58 +0100
Subject: [SciPy-dev] Strange behaviour of x axis tic marks in xplt
Message-ID: <4200AC5A.8050105@mecha.uni-stuttgart.de>

Hi all,

I have attached a short test program illustrating the strange behaviour of
x axis tic marks within xplt.

Any pointer or suggestion how to fix this problem would be appreciated.

Thanks in advance.

       Nils

 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bsp5.py
Type: text/x-python
Size: 665 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20050202/73c3bb52/attachment.py>

From prabhu_r at users.sf.net  Wed Feb  2 14:42:52 2005
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Thu, 3 Feb 2005 01:12:52 +0530
Subject: [SciPy-dev] Python (Enthought Edition) for Windows test release
In-Reply-To: <41FA9DFB.9090806@enthought.com>
References: <41EDF500.5070302@enthought.com>
	<16890.25530.853993.485960@monster.linux.in>
	<41FA7098.4020105@enthought.com>
	<16890.36483.868846.59318@monster.linux.in>
	<41FA9DFB.9090806@enthought.com>
Message-ID: <16897.11580.746352.396265@monster.linux.in>

>>>>> "JC" == Joe Cooper <joe at enthought.com> writes:

    JC> Prabhu Ramachandran wrote:
    >>>>>>> "JC" == Joe Cooper <joe at enthought.com> writes:

    >> OK, I'll push its priority up and try to get a 1.4 release done
    >> ASAP.

    JC> I do appreciate it.  Don't work yourself too hard to do
    JC> it...My ideal world won't be happening with this release,
    JC> regardless of whether your release occurs.  But I'm trying to
    JC> establish some guidelines that make it easy for developers to
    JC> get their software into Enthon in a form that works well,
    JC> making both me and the developer look good to the end user.
    JC> ;-)

OK, it is done.  1.4 is now officially released. :)

cheers,
prabhu



From stephen.walton at csun.edu  Wed Feb  2 19:06:26 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Wed, 02 Feb 2005 16:06:26 -0800
Subject: [SciPy-dev] Absoft & Scipy
Message-ID: <42016B02.9090309@csun.edu>

Serendipity:  I thought Nils's bsp5.py would make a nice little test of 
my Scipy installation, built with Fernando's tools.  I immediately found 
that I'd built LAPACK with Absoft Fortran but Scipy with g77.  In 
attempting to fix that, I found that the Absoft compiler support is 
slightly broken, and also that INSTALL.txt is incorrect. I know I should 
do a formal diff, but the changes are so slight:

INSTALL.txt:  the information under COMPILER NOTES is out of date and 
should be replaced with the corresponding information on the 
installation Web page.

absoftcompiler.py:  line 66 should change to "opt.extend(['g2c', 
'f90math', 'fio', 'f77math'])"

spblas.f.src: line 379 needs a declaration of 'ra' as integer, as it is 
used as an array index.  g77 will let you get away with the code as is, 
but Absoft won't.

I also found, unfortunately, that bdist_rpm doesn't respect the compiler 
setting.  The following command

python setup.py config_fc --fcompiler=absoft bdist_rpm --release=P4SSE2 
--binary-only

fails to use the Absoft compiler;  it still uses g77.  Replacing the 
"bdist_rpm..." with "build" works fine.

Finally, even after a successful scipy build against Absoft, I'm still 
getting an error and would appreciate a clue where to look in tracking 
it down:

In [1]: linalg.eigvals(rand(5,5))
exceptions.ImportError: 
/usr/lib/python2.3/site-packages/scipy/linalg/_flinalg.so: undefined 
symbol: ddet_c_
Out[1]: NumPy array, format: long
[ 2.90519028+0.j         -0.42248621+0.j         -0.01764924+0.50381647j
      -0.01764924-0.50381647j  0.40434219+0.j        ]








From stephen.walton at csun.edu  Wed Feb  2 19:31:48 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Wed, 02 Feb 2005 16:31:48 -0800
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <42016B02.9090309@csun.edu>
References: <42016B02.9090309@csun.edu>
Message-ID: <420170F4.1010301@csun.edu>

Stephen Walton wrote:

> In [1]: linalg.eigvals(rand(5,5))
> exceptions.ImportError: 
> /usr/lib/python2.3/site-packages/scipy/linalg/_flinalg.so: undefined 
> symbol: ddet_c_

Found a clue, but not the cause:  when specifying the Absoft compiler, 
f2py is building _flinalgmodule.c in such a way that the external symbol 
ends in only one underscore (ddet_c_ instead of ddet_c__).  The history 
here is that, in a dumb design decision, g77 puts *two* underscores at 
the end of external names which have an embedded underscore, and recent 
versions of Absoft, with the appropriate compiler switch, emulate this 
behavior;  older versions did not.  I have F2PY version 2.45.241_1926 
installed if that's important.





From arnd.baecker at web.de  Thu Feb  3 04:03:16 2005
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 3 Feb 2005 10:03:16 +0100 (CET)
Subject: [SciPy-dev] install problems, SUSE, check_heev
Message-ID: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>

Hi,

I am going through my yearly torture to install an up-to-date
scipy&Co on SUSE for our computational physics course:

Installation of scipy works fine, but
  import scipy ; scipy.test(1,verbosity=10)
gives
  check_heev  (scipy.lib.lapack.test_lapack.test_flapack_complex)
  Speicherzugriffsfehler = "memory error"

I am not quite sure if this is related to the long thread ending with
  http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-December/002742.html

So before I really start digging through all the suggestions
there I would like to hear your advice!

System details:
- machine: athlon i386
- SUSE 9.2
- Python 2.3.4 (#1, Feb  2 2005, 14:30:47)
- scipy from CVS (yesterday):
    In [1]: import scipy
    numerix Numeric 23.7
    In [2]: scipy.__version__
    Out[2]: '0.3.3_302.4564'
-   F2PY-2.45.241_1926
- atlas3.6.0_Linux_ATHLONSSE1.tgz
  (from http://www.scipy.org/download/atlasbinaries/linux/)
- gcc version 3.3.4 (pre 3.3.5 20040809)

Any comments/suggestions are very much appreciated, many thanks,

Arnd


P.S.: The origin of the pain on my side is that I normally
use debian (and everything works so nicely there ;-) ...



From pearu at scipy.org  Thu Feb  3 04:25:07 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 03:25:07 -0600 (CST)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.61.0502030314530.6813@scipy.org>



On Thu, 3 Feb 2005, Arnd Baecker wrote:

> Hi,
>
> I am going through my yearly torture to install an up-to-date
> scipy&Co on SUSE for our computational physics course:
>
> Installation of scipy works fine, but
>  import scipy ; scipy.test(1,verbosity=10)
> gives
>  check_heev  (scipy.lib.lapack.test_lapack.test_flapack_complex)
>  Speicherzugriffsfehler = "memory error"
>
> I am not quite sure if this is related to the long thread ending with
>  http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-December/002742.html
>
> So before I really start digging through all the suggestions
> there I would like to hear your advice!

Relinking ATLAS libraries with a Fortran LAPACK compiled with -O2 is a
(probable) way to fix this segfault.

Also (I could not find the corresponding thread at the moment)
watch out -fno-f2c flag in LAPACK/make.inc file
when compiling LAPACK libraries: someone reported that choosing this
flag properly fixed the segfault. Though in my debian sid box -fno-f2c 
works fine, then see

   http://math-atlas.sourceforge.net/errata.html#nof2c

that advices not to use -fno-f2c flag with g77.

If the combination "use -O2" and "remove -fno-f2c" fixes the issue, then 
I am curious if also "use -O3" and "remove -fno-f2c" works.

Pearu



From arnd.baecker at web.de  Thu Feb  3 06:55:37 2005
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 3 Feb 2005 12:55:37 +0100 (CET)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.61.0502030314530.6813@scipy.org>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
Message-ID: <Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>

Hi,

On Thu, 3 Feb 2005, Pearu Peterson wrote:

> On Thu, 3 Feb 2005, Arnd Baecker wrote:
>
> > Hi,
> >
> > I am going through my yearly torture to install an up-to-date
> > scipy&Co on SUSE for our computational physics course:
> >
> > Installation of scipy works fine, but
> >  import scipy ; scipy.test(1,verbosity=10)
> > gives
> >  check_heev  (scipy.lib.lapack.test_lapack.test_flapack_complex)
> >  Speicherzugriffsfehler = "memory error"
> >
> > I am not quite sure if this is related to the long thread ending with
> >  http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-December/002742.html
> >
> > So before I really start digging through all the suggestions
> > there I would like to hear your advice!
>
> Relinking ATLAS libraries with a Fortran LAPACK compiled with -O2 is a
> (probable) way to fix this segfault.
>
> Also (I could not find the corresponding thread at the moment)
> watch out -fno-f2c flag in LAPACK/make.inc file
> when compiling LAPACK libraries: someone reported that choosing this
> flag properly fixed the segfault. Though in my debian sid box -fno-f2c
> works fine, then see
>
>    http://math-atlas.sourceforge.net/errata.html#nof2c
>
> that advices not to use -fno-f2c flag with g77.
>
> If the combination "use -O2" and "remove -fno-f2c" fixes the issue, then
> I am curious if also "use -O3" and "remove -fno-f2c" works.

Thank you very much for the information - I will try
this out later.
For the moment I followed Nils Wagner's
suggestion (which he send off-list) to use


   export BLAS_SRC=~/INSTALL_PYTHON_05/CompileDir/blas
   export LAPACK_SRC=~/INSTALL_PYTHON_05/CompileDir/LAPACK
   mkdir $BLAS_SRC
   cd $BLAS_SRC
   wget http://www.netlib.org/blas/blas.tgz
   tar xzf blas.tgz

   mkdir $LAPACK_SRC/
   cd $LAPACK_SRC/..
   wget http://www.netlib.org/lapack/lapack.tgz
   tar xzf lapack.tgz

   export BLAS=None
   export LAPACK=None
   export ATLAS=None


Compilation of scipy works fine, and
I get much further for scipy.test(1,verbosity=10),
namely until FAILED (failures=25, errors=2).

The two errors are:

======================================================================
ERROR: check_defective1 (scipy.linalg.matfuncs.test_matfuncs.test_signm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/opt/python/lib/python2.3/site-packages/scipy/linalg/tests/test_matfuncs.py",
line 48, in check_defective1
    r = signm(a)
  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/matfuncs.py",
line 267, in signm
    iS0 = inv(S0)
  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/basic.py",
line 176, in inv
    a1 = asarray_chkfinite(a)
  File
"/opt/python/lib/python2.3/site-packages/scipy_base/function_base.py",
line 27, in asarray_chkfinite
    raise ValueError, "Array must not contain infs or nans."
ValueError: Array must not contain infs or nans.

======================================================================
ERROR: check_defective3 (scipy.linalg.matfuncs.test_matfuncs.test_signm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/opt/python/lib/python2.3/site-packages/scipy/linalg/tests/test_matfuncs.py",
line 69, in check_defective3
    r = signm(a)
  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/matfuncs.py",
line 267, in signm
    iS0 = inv(S0)
  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/basic.py",
line 176, in inv
    a1 = asarray_chkfinite(a)
  File
"/opt/python/lib/python2.3/site-packages/scipy_base/function_base.py",
line 27, in asarray_chkfinite
    raise ValueError, "Array must not contain infs or nans."
ValueError: Array must not contain infs or nans.




And the failures are all of the type of the first one:

======================================================================
FAIL: check_heevr_complex
(scipy.lib.lapack.test_lapack.test_flapack_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/opt/python/lib/python2.3/site-packages/scipy/lib/lapack/tests/esv_tests.py",
line 53, in check_heevr_complex
    assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
  File "/opt/python/lib/python2.3/site-packages/scipy_test/testing.py",
line 740, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 33.3333333333%):
        Array 1: [ 3.3270837 +5.8356678e+00j  2.2669436 +1.9275274e+00j
       8.8565315 +1.4901161e-08j]
        Array 2: [ 3.3270836+5.8356678j  2.2669436+1.9275274j
8.8565297+0.j       ]


So it is again (still) heevr
(though the memory error came with
check_heevr and not check_heevr_complex if
this is of any relevance or difference).

All failures are from
- scipy.lib.lapack.test_lapack.test_flapack_complex (check_heevr_XXX)
- scipy.lib.lapack.test_lapack.test_flapack_double (check_syevr_XXX)
- scipy.lib.lapack.test_lapack.test_flapack_double_complex
  (check_heevr_XXX)
-  scipy.lib.lapack.test_lapack.test_flapack_float (check_syevr_XXX)


Is any of the above expected when not using the full atlas/lapack
combo and just blas/lapack?

Best,

Arnd



From pearu at scipy.org  Thu Feb  3 07:01:10 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 06:01:10 -0600 (CST)
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <420170F4.1010301@csun.edu>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
Message-ID: <Pine.LNX.4.61.0502030551160.10319@scipy.org>



On Wed, 2 Feb 2005, Stephen Walton wrote:

> Stephen Walton wrote:
>
>> In [1]: linalg.eigvals(rand(5,5))
>> exceptions.ImportError: 
>> /usr/lib/python2.3/site-packages/scipy/linalg/_flinalg.so: undefined 
>> symbol: ddet_c_
>
> Found a clue, but not the cause:  when specifying the Absoft compiler, f2py 
> is building _flinalgmodule.c in such a way that the external symbol ends in 
> only one underscore (ddet_c_ instead of ddet_c__).  The history here is that, 
> in a dumb design decision, g77 puts *two* underscores at the end of external 
> names which have an embedded underscore, and recent versions of Absoft, with 
> the appropriate compiler switch, emulate this behavior;  older versions did 
> not.  I have F2PY version 2.45.241_1926 installed if that's important.

f2py assumes that all fortran symbols have exactly one underscore at the 
end of external names. Therefore, scipy_distutils envokes gcc with
-fno-second-underscore option. Compilers of other vendors have similar
options and they are used by scipy_distutils. So, check Absoft compiler
manual if it provides options that forces external names to be appended 
with exactly *one* underscore, and try to modify 
scipy_distutils/absoftfcompiler.py accordingly.

If Absoft compiler does not have nor will in future such a switch then
another solution would be to introduce -DSECOND_UNDERSCORE_FORTRAN
support to f2py so that such compilers as Absoft could be fully supported.
But try first method first.

Pearu



From nwagner at mecha.uni-stuttgart.de  Thu Feb  3 07:05:00 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 03 Feb 2005 13:05:00 +0100
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
Message-ID: <4202136C.6080104@mecha.uni-stuttgart.de>

Arnd Baecker wrote:

>Hi,
>
>On Thu, 3 Feb 2005, Pearu Peterson wrote:
>
>  
>
>>On Thu, 3 Feb 2005, Arnd Baecker wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I am going through my yearly torture to install an up-to-date
>>>scipy&Co on SUSE for our computational physics course:
>>>
>>>Installation of scipy works fine, but
>>> import scipy ; scipy.test(1,verbosity=10)
>>>gives
>>> check_heev  (scipy.lib.lapack.test_lapack.test_flapack_complex)
>>> Speicherzugriffsfehler = "memory error"
>>>
>>>I am not quite sure if this is related to the long thread ending with
>>> http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-December/002742.html
>>>
>>>So before I really start digging through all the suggestions
>>>there I would like to hear your advice!
>>>      
>>>
>>Relinking ATLAS libraries with a Fortran LAPACK compiled with -O2 is a
>>(probable) way to fix this segfault.
>>
>>Also (I could not find the corresponding thread at the moment)
>>watch out -fno-f2c flag in LAPACK/make.inc file
>>when compiling LAPACK libraries: someone reported that choosing this
>>flag properly fixed the segfault. Though in my debian sid box -fno-f2c
>>works fine, then see
>>
>>   http://math-atlas.sourceforge.net/errata.html#nof2c
>>
>>that advices not to use -fno-f2c flag with g77.
>>
>>If the combination "use -O2" and "remove -fno-f2c" fixes the issue, then
>>I am curious if also "use -O3" and "remove -fno-f2c" works.
>>    
>>
>
>Thank you very much for the information - I will try
>this out later.
>For the moment I followed Nils Wagner's
>suggestion (which he send off-list) to use
>
>
>   export BLAS_SRC=~/INSTALL_PYTHON_05/CompileDir/blas
>   export LAPACK_SRC=~/INSTALL_PYTHON_05/CompileDir/LAPACK
>   mkdir $BLAS_SRC
>   cd $BLAS_SRC
>   wget http://www.netlib.org/blas/blas.tgz
>   tar xzf blas.tgz
>
>   mkdir $LAPACK_SRC/
>   cd $LAPACK_SRC/..
>   wget http://www.netlib.org/lapack/lapack.tgz
>   tar xzf lapack.tgz
>
>   export BLAS=None
>   export LAPACK=None
>   export ATLAS=None
>
>
>Compilation of scipy works fine, and
>I get much further for scipy.test(1,verbosity=10),
>namely until FAILED (failures=25, errors=2).
>
>The two errors are:
>
>======================================================================
>ERROR: check_defective1 (scipy.linalg.matfuncs.test_matfuncs.test_signm)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File
>"/opt/python/lib/python2.3/site-packages/scipy/linalg/tests/test_matfuncs.py",
>line 48, in check_defective1
>    r = signm(a)
>  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/matfuncs.py",
>line 267, in signm
>    iS0 = inv(S0)
>  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/basic.py",
>line 176, in inv
>    a1 = asarray_chkfinite(a)
>  File
>"/opt/python/lib/python2.3/site-packages/scipy_base/function_base.py",
>line 27, in asarray_chkfinite
>    raise ValueError, "Array must not contain infs or nans."
>ValueError: Array must not contain infs or nans.
>
>======================================================================
>ERROR: check_defective3 (scipy.linalg.matfuncs.test_matfuncs.test_signm)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File
>"/opt/python/lib/python2.3/site-packages/scipy/linalg/tests/test_matfuncs.py",
>line 69, in check_defective3
>    r = signm(a)
>  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/matfuncs.py",
>line 267, in signm
>    iS0 = inv(S0)
>  File "/opt/python/lib/python2.3/site-packages/scipy/linalg/basic.py",
>line 176, in inv
>    a1 = asarray_chkfinite(a)
>  File
>"/opt/python/lib/python2.3/site-packages/scipy_base/function_base.py",
>line 27, in asarray_chkfinite
>    raise ValueError, "Array must not contain infs or nans."
>ValueError: Array must not contain infs or nans.
>
>
>
>
>And the failures are all of the type of the first one:
>
>======================================================================
>FAIL: check_heevr_complex
>(scipy.lib.lapack.test_lapack.test_flapack_complex)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File
>"/opt/python/lib/python2.3/site-packages/scipy/lib/lapack/tests/esv_tests.py",
>line 53, in check_heevr_complex
>    assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
>  File "/opt/python/lib/python2.3/site-packages/scipy_test/testing.py",
>line 740, in assert_array_almost_equal
>    assert cond,\
>AssertionError:
>Arrays are not almost equal (mismatch 33.3333333333%):
>        Array 1: [ 3.3270837 +5.8356678e+00j  2.2669436 +1.9275274e+00j
>       8.8565315 +1.4901161e-08j]
>        Array 2: [ 3.3270836+5.8356678j  2.2669436+1.9275274j
>8.8565297+0.j       ]
>
>
>So it is again (still) heevr
>(though the memory error came with
>check_heevr and not check_heevr_complex if
>this is of any relevance or difference).
>
>All failures are from
>- scipy.lib.lapack.test_lapack.test_flapack_complex (check_heevr_XXX)
>- scipy.lib.lapack.test_lapack.test_flapack_double (check_syevr_XXX)
>- scipy.lib.lapack.test_lapack.test_flapack_double_complex
>  (check_heevr_XXX)
>-  scipy.lib.lapack.test_lapack.test_flapack_float (check_syevr_XXX)
>
>
>Is any of the above expected when not using the full atlas/lapack
>combo and just blas/lapack?
>
>Best,
>
>Arnd
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>


 Hi Arnd,

I cannot reproduce your errors
check_nils (scipy.linalg.matfuncs.test_matfuncs.test_logm)Result may be inaccurate, approximate err = 4.39192767776e-09
 ... ok
check_defective1 (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
check_defective2 (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
check_defective3 (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
check_nils (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok


>>> scipy.__version__
'0.3.3_302.4564'

>>> Numeric.__version__
'23.7'

f2py -v
2.45.241_1926

Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


Cheers,

            Nils





From arnd.baecker at web.de  Thu Feb  3 08:07:02 2005
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 3 Feb 2005 14:07:02 +0100 (CET)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <4202136C.6080104@mecha.uni-stuttgart.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<4202136C.6080104@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>

On Thu, 3 Feb 2005, Nils Wagner wrote:

> [...]

>  Hi Arnd,
>
> I cannot reproduce your errors
> check_nils (scipy.linalg.matfuncs.test_matfuncs.test_logm)Result may be inaccurate, approximate err = 4.39192767776e-09
>  ... ok
> check_defective1 (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
> check_defective2 (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
> check_defective3 (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
> check_nils (scipy.linalg.matfuncs.test_matfuncs.test_signm) ... ok
>
>
> >>> scipy.__version__
> '0.3.3_302.4564'
>
> >>> Numeric.__version__
> '23.7'
>
> f2py -v
> 2.45.241_1926
>
> Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
> [GCC 3.3.3 (SuSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.

Very interesting, I have the same version, apart from
- python 2.3.4
- gcc version 3.3.4 (pre 3.3.5 20040809)
The machine is an  AMD Athlon(TM) XP 2200+

Is it the right thinking that I need to solve this problem
first before proceeding to the full ATLAS?

BTW (Pearu), I did not change LAPACK/make.inc
in this case (because I used the source code variant) - is it right
that scipy takes care of the flags in this case?

((Or should I better compile LAPACK directly,
as described in scipy's INSTALL.txt
       cd /path/to/src/LAPACK
       make lapacklib    # On 400MHz PII it takes about 15min.
and play around with the flags as you described
in your previous mail?
))

Many thanks,

Arnd



From pearu at scipy.org  Thu Feb  3 08:33:41 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 07:33:41 -0600 (CST)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.61.0502030712280.10319@scipy.org>



On Thu, 3 Feb 2005, Arnd Baecker wrote:

> BTW (Pearu), I did not change LAPACK/make.inc
> in this case (because I used the source code variant) - is it right
> that scipy takes care of the flags in this case?

Yes. Scipy does not make any use of LAPACK/make.inc, it just compiles .f 
files to liblapack_src.a and uses it when linking an extension module.

> ((Or should I better compile LAPACK directly,
> as described in scipy's INSTALL.txt
>       cd /path/to/src/LAPACK
>       make lapacklib    # On 400MHz PII it takes about 15min.
> and play around with the flags as you described
> in your previous mail?

Yes, I'd choose this approach. So, replace the line

   OPTS     = -funroll-all-loops -fno-f2c -O3

in make.inc with

   OPTS     = -funroll-all-loops -O2

and proceed with

   make lapacklib
   mv lapack_LINUX.a libflapack.a
   export LAPACK=/path/to/libflapack.a
   ...

Also, don't read INSTALL.txt :), read

   http://www.scipy.org/documentation/buildscipy.txt

instead. Detailed instructions for building ATLAS for Scipy can be 
found here:

   http://www.scipy.org/documentation/buildatlas4scipy.txt

HTH,
Pearu



From arnd.baecker at web.de  Thu Feb  3 12:20:22 2005
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 3 Feb 2005 18:20:22 +0100 (CET)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.61.0502030712280.10319@scipy.org>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
Message-ID: <Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>

Hi Pearu,

many thanks for your reply - things are fine now, see below.

On Thu, 3 Feb 2005, Pearu Peterson wrote:

> On Thu, 3 Feb 2005, Arnd Baecker wrote:
>
> > BTW (Pearu), I did not change LAPACK/make.inc
> > in this case (because I used the source code variant) - is it right
> > that scipy takes care of the flags in this case?
>
> Yes. Scipy does not make any use of LAPACK/make.inc, it just compiles .f
> files to liblapack_src.a and uses it when linking an extension module.
>
> > ((Or should I better compile LAPACK directly,
> > as described in scipy's INSTALL.txt
> >       cd /path/to/src/LAPACK
> >       make lapacklib    # On 400MHz PII it takes about 15min.
> > and play around with the flags as you described
> > in your previous mail?
>
> Yes, I'd choose this approach. So, replace the line
>
>    OPTS     = -funroll-all-loops -fno-f2c -O3
>
> in make.inc with
>
>    OPTS     = -funroll-all-loops -O2
>
> and proceed with
>
>    make lapacklib
>    mv lapack_LINUX.a libflapack.a
>    export LAPACK=/path/to/libflapack.a
>    ...

I did this and there are no erros for scipy.test(10)!

> Also, don't read INSTALL.txt :), read
>
>    http://www.scipy.org/documentation/buildscipy.txt

humpf, you even wrote that at the beginning of INSTALL.txt
(I completely overlooked that ;-)

> instead. Detailed instructions for building ATLAS for Scipy can be
> found here:
>
>    http://www.scipy.org/documentation/buildatlas4scipy.txt

There are indeed very detailed - I will try that part tomorrow.

BTW, would a  "use -O3" (just for the lapack part)
be of interest to you?

Many thanks for your help,

Arnd



From pearu at scipy.org  Thu Feb  3 12:33:20 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 11:33:20 -0600 (CST)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.61.0502031123320.10319@scipy.org>



On Thu, 3 Feb 2005, Arnd Baecker wrote:

> BTW, would a  "use -O3" (just for the lapack part)
> be of interest to you?

Yes. That would answer the question, was it compiler optimization bug or 
-fno-f2c bug, and scipy_distutils may be needing the corresponding patch.

Pearu



From stephen.walton at csun.edu  Thu Feb  3 13:15:04 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 03 Feb 2005 10:15:04 -0800
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.61.0502031123320.10319@scipy.org>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>
Message-ID: <42026A28.8040205@csun.edu>

Pearu Peterson wrote:

> On Thu, 3 Feb 2005, Arnd Baecker wrote:
>
>> BTW, would a  "use -O3" (just for the lapack part)
>> be of interest to you?
>
>
> Yes. That would answer the question, was it compiler optimization bug 
> or -fno-f2c bug,

Just for my datum, I found -O3 works fine at gcc 3.3 or later, and it 
was definitely -fno-f2c which broke my install.  According to a comment 
I saw somewhere out there, -O3 only breaks LAPACK at gcc 3.2 or earlier.



From Fernando.Perez at colorado.edu  Thu Feb  3 13:28:24 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 03 Feb 2005 11:28:24 -0700
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <42026A28.8040205@csun.edu>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>
	<42026A28.8040205@csun.edu>
Message-ID: <42026D48.7020101@colorado.edu>

Stephen Walton wrote:
> Pearu Peterson wrote:
> 
> 
>>On Thu, 3 Feb 2005, Arnd Baecker wrote:
>>
>>
>>>BTW, would a  "use -O3" (just for the lapack part)
>>>be of interest to you?
>>
>>
>>Yes. That would answer the question, was it compiler optimization bug 
>>or -fno-f2c bug,
> 
> 
> Just for my datum, I found -O3 works fine at gcc 3.3 or later, and it 
> was definitely -fno-f2c which broke my install.  According to a comment 
> I saw somewhere out there, -O3 only breaks LAPACK at gcc 3.2 or earlier.

I'm sorry that I can't offer to do detailed testing with compiler flags right 
now.  But if anyone can put up a set of P4SSE2 ATLAS packages compiled with 
-O3, and NO -fno-f2c, I can certainly rebuild all of CVS scipy quickly and 
confirm whether the segfaults on heev are gone or not.

That's the advantage of the new, improved scipy build process: a full rebuild 
takes exactly one line of typing (with the automatic RPM builder for ATLAS 
binary tarballs).

Cheers,

f



From stephen.walton at csun.edu  Thu Feb  3 13:35:32 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 03 Feb 2005 10:35:32 -0800
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <Pine.LNX.4.61.0502030551160.10319@scipy.org>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>
Message-ID: <42026EF4.3030806@csun.edu>

Pearu Peterson wrote:

> Check Absoft compiler
> manual if it provides options that forces external names to be 
> appended with exactly *one* underscore, and try to modify 
> scipy_distutils/absoftfcompiler.py accordingly.

Sigh.  I found the problem but am not sure of a workaround.  I've 
created an /opt/absoft/default.opt file locally which forces Absoft to 
use the '-g77' switch on all compiles for maximum compatibility with 
binaries from that compiler.   This means that it does the double 
underscore append.  Without -g77 and with -YEXT_SFX=_ on the Absoft 
command line, one gets a single underscore as desired.  With both, one 
gets three underscores!

 From my point of view, the simplest solution would be for f2py to 
respect g77's defaults rather than override them, even though in this 
case I agree g77's default is stupid.  But there's a better reason than 
personal preference:  If I install fftw from the Fedora RPMs, they were 
compiled with g77 and therefore have the double underscores on external 
names with embedded underscores.  I need to minimize the time I spend 
doing admin tasks (see my recent conversation with Fernando) and would 
rather not have to add fftw to the list of things I have to compile 
myself with special switches to keep scipy working.



From stephen.walton at csun.edu  Thu Feb  3 13:44:42 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 03 Feb 2005 10:44:42 -0800
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <42026EF4.3030806@csun.edu>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>
	<42026EF4.3030806@csun.edu>
Message-ID: <4202711A.2090400@csun.edu>

Stephen Walton wrote:

> I need to minimize the time I spend doing admin tasks (see my recent 
> conversation with Fernando) and would rather not have to add fftw to 
> the list of things I have to compile myself with special switches to 
> keep scipy working.

I should clarify this.  What I really meant was that I put the -g77 
switch in /opt/absoft/default.opt so my users can compile Fortran 
against the Fedora-provided fftw libraries without having to do anything 
special.  I realize that Scipy goes through the C interface to fftw and 
therefore will work with the Fedora RPM's without difficulty.



From pearu at scipy.org  Thu Feb  3 14:58:57 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 13:58:57 -0600 (CST)
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <42026EF4.3030806@csun.edu>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>
	<42026EF4.3030806@csun.edu>
Message-ID: <Pine.LNX.4.61.0502031337070.10319@scipy.org>



On Thu, 3 Feb 2005, Stephen Walton wrote:

> Pearu Peterson wrote:
>
>> Check Absoft compiler
>> manual if it provides options that forces external names to be appended 
>> with exactly *one* underscore, and try to modify 
>> scipy_distutils/absoftfcompiler.py accordingly.
>
> Sigh.  I found the problem but am not sure of a workaround.  I've created an 
> /opt/absoft/default.opt file locally which forces Absoft to use the '-g77' 
> switch on all compiles for maximum compatibility with binaries from that 
> compiler.   This means that it does the double underscore append.  Without 
> -g77 and with -YEXT_SFX=_ on the Absoft command line, one gets a single 
> underscore as desired.  With both, one gets three underscores!
>
> From my point of view, the simplest solution would be for f2py to respect 
> g77's defaults rather than override them, even though in this case I agree 
> g77's default is stupid.  But there's a better reason than personal 
> preference:  If I install fftw from the Fedora RPMs, they were compiled with 
> g77 and therefore have the double underscores on external names with embedded 
> underscores.  I need to minimize the time I spend doing admin tasks (see my 
> recent conversation with Fernando) and would rather not have to add fftw to 
> the list of things I have to compile myself with special switches to keep 
> scipy working.

Right now I don't have a solution to this chicken&egg problem: using 
'-g77' in /opt/absoft/default.opt is upto a sysadmin or whoever maintains
absoft compiler installation while f2py has used for a long time 
the exactly-single underscore convention in order to support also other 
compilers than g77. And if '-g77' would not be used in 
/opt/absoft/default.opt, scipy should build fine with this convention.
I am not sure which party of absoft compiler users is larger, those who 
use -g77 or those who do not.

Anyway, recent f2py from CVS supports now -DUNDERSCORE_G77 that will cause 
extra underscore appended to those names that contain an underscore.
So, to build scipy with the absoft fortran compiler that uses -g77 by 
default, get f2py from CVS, install it, and use the following command

   python setup.py build_ext -DUNDERSCORE_G77 build

Note that if any of the fortran libraries used by scipy is not compiled
with -g77, you have the same problem but inversed. Then one should not
use -DUNDERSCORE_G77. Right now scipy_distutils/system_info.py cannot
test this automatically.

Pearu



From pearu at scipy.org  Thu Feb  3 16:19:15 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 15:19:15 -0600 (CST)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <42026D48.7020101@colorado.edu>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>
	<42026A28.8040205@csun.edu> <42026D48.7020101@colorado.edu>
Message-ID: <Pine.LNX.4.61.0502031515480.10319@scipy.org>



On Thu, 3 Feb 2005, Fernando Perez wrote:

> I'm sorry that I can't offer to do detailed testing with compiler flags right 
> now.  But if anyone can put up a set of P4SSE2 ATLAS packages compiled with 
> -O3, and NO -fno-f2c, I can certainly rebuild all of CVS scipy quickly and 
> confirm whether the segfaults on heev are gone or not.

I have uploaded  atlas3.6.0_Linux_P4SSE2.tgz and 
atlas3.6.0_Linux_P4SSE2_2HT.tgz to 
http://www.scipy.org/download/atlasbinaries/linux/ that contain
LAPACK libraries compiled with gcc 3.4.4 and -O3, and without -fno-f2c.
Old files (the ones with -fno-f2c in LAPACK compilation) are in
http://www.scipy.org/download/atlasbinaries/linux/old/.

Pearu



From stephen.walton at csun.edu  Thu Feb  3 16:32:01 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 03 Feb 2005 13:32:01 -0800
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <Pine.LNX.4.61.0502031337070.10319@scipy.org>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>	<42026EF4.3030806@csun.edu>
	<Pine.LNX.4.61.0502031337070.10319@scipy.org>
Message-ID: <42029851.9020608@csun.edu>

Pearu Peterson wrote:

>   python setup.py build_ext -DUNDERSCORE_G77 build

I tried this with F2PY 2.45.241_1936 and scipy 0.3.3_302.4564 and got:

running build_ext
Traceback (most recent call last):
  File "setup.py", line 124, in ?
    setup_package(ignore_packages)
  File "setup.py", line 112, in setup_package
    url = "http://www.scipy.org",
  File "scipy_core/scipy_distutils/core.py", line 73, in setup
    return old_setup(**new_attr)
  File 
"/usr/src/build/475206-i386/install/usr/lib/python2.3/distutils/core.py", 
line 149, in setup
  File 
"/usr/src/build/475206-i386/install/usr/lib/python2.3/distutils/dist.py", 
line 907, in run_commands
  File 
"/usr/src/build/475206-i386/install/usr/lib/python2.3/distutils/dist.py", 
line 927, in run_command
  File "scipy_core/scipy_distutils/command/build_ext.py", line 47, in run
    raise TypeError,'Extension "%s" sources contains unresolved'\
TypeError: Extension "scipy.linalg.fblas" sources contains unresolved 
items (call build_src before build_ext).



From pearu at scipy.org  Thu Feb  3 16:35:21 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 15:35:21 -0600 (CST)
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <42029851.9020608@csun.edu>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>
	<42026EF4.3030806@csun.edu>
	<Pine.LNX.4.61.0502031337070.10319@scipy.org>
	<42029851.9020608@csun.edu>
Message-ID: <Pine.LNX.4.61.0502031534050.10319@scipy.org>



On Thu, 3 Feb 2005, Stephen Walton wrote:

> Pearu Peterson wrote:
>
>>   python setup.py build_ext -DUNDERSCORE_G77 build
>
> I tried this with F2PY 2.45.241_1936 and scipy 0.3.3_302.4564 and got:
>
> running build_ext
...
> TypeError: Extension "scipy.linalg.fblas" sources contains unresolved items 
> (call build_src before build_ext).
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - hint!

So, try

   python setup.py build_src build_ext -DUNDERSCORE_G77 build

Pearu



From Fernando.Perez at colorado.edu  Thu Feb  3 17:04:11 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 03 Feb 2005 15:04:11 -0700
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.61.0502031515480.10319@scipy.org>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>	<42026A28.8040205@csun.edu>
	<42026D48.7020101@colorado.edu>
	<Pine.LNX.4.61.0502031515480.10319@scipy.org>
Message-ID: <42029FDB.2000407@colorado.edu>

Pearu Peterson wrote:
> 
> On Thu, 3 Feb 2005, Fernando Perez wrote:
> 
> 
>>I'm sorry that I can't offer to do detailed testing with compiler flags right 
>>now.  But if anyone can put up a set of P4SSE2 ATLAS packages compiled with 
>>-O3, and NO -fno-f2c, I can certainly rebuild all of CVS scipy quickly and 
>>confirm whether the segfaults on heev are gone or not.
> 
> 
> I have uploaded  atlas3.6.0_Linux_P4SSE2.tgz and 
> atlas3.6.0_Linux_P4SSE2_2HT.tgz to 
> http://www.scipy.org/download/atlasbinaries/linux/ that contain
> LAPACK libraries compiled with gcc 3.4.4 and -O3, and without -fno-f2c.
> Old files (the ones with -fno-f2c in LAPACK compilation) are in
> http://www.scipy.org/download/atlasbinaries/linux/old/.

Good news!  I rebuilt my Numeric 23.7 RPM as well just to be safe (though I'm 
not sure it would have mattered):

In [3]: scipy.test(10)

[...]

.Testing weibull_min
.....
----------------------------------------------------------------------
Ran 1314 tests in 76.035s

OK
Out[3]: <unittest.TextTestRunner object at 0x44cd5d2c>


And there was much rejoicing!

This is great, I'll update all our boxes now.  If at any point you have time 
to make PIIISSE1 binaries, that would be awesome (our laptops are all P3s). 
But no hurries at all.

Your binaries are really a huge time/work saver for many of us.  Can't thank 
you enough :)

Regards,

f



From stephen.walton at csun.edu  Thu Feb  3 17:13:45 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 03 Feb 2005 14:13:45 -0800
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <Pine.LNX.4.61.0502031534050.10319@scipy.org>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>	<42026EF4.3030806@csun.edu>
	<Pine.LNX.4.61.0502031337070.10319@scipy.org>	<42029851.9020608@csun.edu>
	<Pine.LNX.4.61.0502031534050.10319@scipy.org>
Message-ID: <4202A219.5080800@csun.edu>

Pearu Peterson wrote:

>   python setup.py build_src build_ext -DUNDERSCORE_G77 build

/usr/bin/g77 -shared 
build/temp.linux-i686-2.3/build/src/Lib/fftpack/_fftpackmodule.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/zfft.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/drfft.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/zrfft.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/zfftnd.o 
build/temp.linux-i686-2.3/build/src/fortranobject.o -L/usr/lib 
-Lbuild/temp.linux-i686-2.3 -ldfftpack -lrfftw -lfftw -lg2c -o 
build/lib.linux-i686-2.3/scipy/fftpack/_fftpack.so
/usr/bin/ld: cannot find -ldfftpack
collect2: ld returned 1 exit status
/usr/bin/ld: cannot find -ldfftpack
collect2: ld returned 1 exit status
error: Command "/usr/bin/g77 -shared 
build/temp.linux-i686-2.3/build/src/Lib/fftpack/_fftpackmodule.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/zfft.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/drfft.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/zrfft.o 
build/temp.linux-i686-2.3/Lib/fftpack/src/zfftnd.o 
build/temp.linux-i686-2.3/build/src/fortranobject.o -L/usr/lib 
-Lbuild/temp.linux-i686-2.3 -ldfftpack -lrfftw -lfftw -lg2c -o 
build/lib.linux-i686-2.3/scipy/fftpack/_fftpack.so" failed with exit 
status 1

Grep'ping the output file from the builds reveals that, indeed, dfftpack 
never gets compiled when using the "build_src build_ext" form of the 
command.

Yah know, maybe this isn't worth it.  I can get everything working if I 
use g77-compiled LAPACK, ATLAS, and scipy such as you're providing on 
the Web site or I build myself.  Since LAPACK and ATLAS contain no 
routines with embedded underscores, g77 compiled versions link against 
Absoft compiled callers just fine.  I wonder how much performance I 
really gain by insisting on compiling with Absoft.  Off to run some 
benchmarks...



From pearu at scipy.org  Thu Feb  3 17:23:55 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 3 Feb 2005 16:23:55 -0600 (CST)
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <4202A219.5080800@csun.edu>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>
	<42026EF4.3030806@csun.edu>
	<Pine.LNX.4.61.0502031337070.10319@scipy.org>
	<42029851.9020608@csun.edu>
	<Pine.LNX.4.61.0502031534050.10319@scipy.org>
	<4202A219.5080800@csun.edu>
Message-ID: <Pine.LNX.4.61.0502031617440.10319@scipy.org>



On Thu, 3 Feb 2005, Stephen Walton wrote:

> Pearu Peterson wrote:
>
>>   python setup.py build_src build_ext -DUNDERSCORE_G77 build
>
> build/lib.linux-i686-2.3/scipy/fftpack/_fftpack.so" failed with exit status 1
>
> Grep'ping the output file from the builds reveals that, indeed, dfftpack 
> never gets compiled when using the "build_src build_ext" form of the command.

Ok, sorry, the complete setup.py command should be

   python setup.py build_src build_clib build_ext -DUNDERSCORE_G77 build

(this time I tested and it works)

> Yah know, maybe this isn't worth it.  I can get everything working if I use 
> g77-compiled LAPACK, ATLAS, and scipy such as you're providing on the Web 
> site or I build myself.  Since LAPACK and ATLAS contain no routines with 
> embedded underscores, g77 compiled versions link against Absoft compiled 
> callers just fine.  I wonder how much performance I really gain by insisting 
> on compiling with Absoft.  Off to run some benchmarks...

I wonder why people think that gnu compiler is slow...

Pearu



From nwagner at mecha.uni-stuttgart.de  Fri Feb  4 04:12:49 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 04 Feb 2005 10:12:49 +0100
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <Pine.LNX.4.61.0502031123320.10319@scipy.org>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>
Message-ID: <42033C91.1070602@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Thu, 3 Feb 2005, Arnd Baecker wrote:
>
>> BTW, would a  "use -O3" (just for the lapack part)
>> be of interest to you?
>
>
> Yes. That would answer the question, was it compiler optimization bug 
> or -fno-f2c bug, and scipy_distutils may be needing the corresponding 
> patch.
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev


How can I enforce it not to use the standard libraries liblapack.a and 
libblas.a living in /usr/lib ?

Nils





From nwagner at mecha.uni-stuttgart.de  Fri Feb  4 05:22:47 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 04 Feb 2005 11:22:47 +0100
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <42033C91.1070602@mecha.uni-stuttgart.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>
	<42033C91.1070602@mecha.uni-stuttgart.de>
Message-ID: <42034CF7.9090103@mecha.uni-stuttgart.de>

Nils Wagner wrote:

> Pearu Peterson wrote:
>
>>
>>
>> On Thu, 3 Feb 2005, Arnd Baecker wrote:
>>
>>> BTW, would a  "use -O3" (just for the lapack part)
>>> be of interest to you?
>>
>>
>>
>> Yes. That would answer the question, was it compiler optimization bug 
>> or -fno-f2c bug, and scipy_distutils may be needing the corresponding 
>> patch.
>>
>> Pearu
>>
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.net
>> http://www.scipy.net/mailman/listinfo/scipy-dev
>
>
>
> How can I enforce it not to use the standard libraries liblapack.a and 
> libblas.a living in /usr/lib ?
>
> Nils
>
If  I deinstall SuSE's lapack.rpm everything works fine, that is I can 
use -O3 without any segfault.

Nils

>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



 




From arnd.baecker at web.de  Fri Feb  4 06:56:18 2005
From: arnd.baecker at web.de (Arnd Baecker)
Date: Fri, 4 Feb 2005 12:56:18 +0100 (CET)
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <42034CF7.9090103@mecha.uni-stuttgart.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<42033C91.1070602@mecha.uni-stuttgart.de>
	<42034CF7.9090103@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.51.0502041240370.3596@ptpcp8.phy.tu-dresden.de>

Hi,

On Fri, 4 Feb 2005, Nils Wagner wrote:

> Nils Wagner wrote:
>
> > Pearu Peterson wrote:
> >>
> >> On Thu, 3 Feb 2005, Arnd Baecker wrote:
> >>
> >>> BTW, would a  "use -O3" (just for the lapack part)
> >>> be of interest to you?
> >>
> >>
> >>
> >> Yes. That would answer the question, was it compiler optimization bug
> >> or -fno-f2c bug, and scipy_distutils may be needing the corresponding
> >> patch.

So from the other e-mails the answer is that it is
a compiler optimization bug.
And for my setup (Suse 9.2, gcc version 3.3.4 (pre 3.3.5 20040809)
the same is true, i.e. only "-fno-f2c" has to be omitted
in the OPTS in the make.inc (from INSTALL/make.inc.LINUX)
for LAPACK.

Great - many thanks for all the help!

And to Nils question:

> > How can I enforce it not to use the standard libraries liblapack.a and
> > libblas.a living in /usr/lib ?

In my case it seems to be enough to do
  export LAPACK=/opt/python/lib/libflapack.a
and the corresponding one for BLAS
before compiling scipy.

Best,

Arnd



From stephen.walton at csun.edu  Fri Feb  4 13:32:21 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Fri, 04 Feb 2005 10:32:21 -0800
Subject: [SciPy-dev] install problems, SUSE, check_heev
In-Reply-To: <42034CF7.9090103@mecha.uni-stuttgart.de>
References: <Pine.LNX.4.51.0502030933330.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030314530.6813@scipy.org>
	<Pine.LNX.4.51.0502031239510.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0502031353430.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502030712280.10319@scipy.org>
	<Pine.LNX.4.51.0502031812370.27641@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0502031123320.10319@scipy.org>
	<42033C91.1070602@mecha.uni-stuttgart.de>
	<42034CF7.9090103@mecha.uni-stuttgart.de>
Message-ID: <4203BFB5.7070003@csun.edu>

Nils Wagner wrote:

> If  I deinstall SuSE's lapack.rpm everything works fine, that is I can 
> use -O3 without any segfault.

That's the usual recommendation for RedHat and Fedora too.  Be aware 
though that the binary RPM for Octave is built against the lapack RPM on 
those systems, so if you want Octave you probably will wind up building 
it from source and linking it against ATLAS.



From stephen.walton at csun.edu  Fri Feb  4 13:51:40 2005
From: stephen.walton at csun.edu (Stephen Walton)
Date: Fri, 04 Feb 2005 10:51:40 -0800
Subject: [SciPy-dev] Absoft & Scipy
In-Reply-To: <4202A219.5080800@csun.edu>
References: <42016B02.9090309@csun.edu> <420170F4.1010301@csun.edu>
	<Pine.LNX.4.61.0502030551160.10319@scipy.org>	<42026EF4.3030806@csun.edu>
	<Pine.LNX.4.61.0502031337070.10319@scipy.org>	<42029851.9020608@csun.edu>
	<Pine.LNX.4.61.0502031534050.10319@scipy.org>
	<4202A219.5080800@csun.edu>
Message-ID: <4203C43C.9070706@csun.edu>

Stephen Walton wrote:

> I wonder how much performance I really gain by insisting on compiling 
> with Absoft.  Off to run some benchmarks...

Well, I have some answers.  I ran "make blaslib" followed by "make 
timing" in the LAPACK source directory.  Note that this means I'm using 
the reference Fortran BLAS and not the tuned ATLAS one.

Almost all the results of "make timing" show that g77/gcc is faster than 
Absoft on most of the benchmarks, often substantially.  For example 
(this is random), a 40 by 40 array fed to SGEBRD hits 458 MFlops on 
Absoft and 629 with g77.  This is with -O3 on both compilers on a P4SSE2 
2.2GHz system.  The only exceptions are some of the double complex 
computations, where Absoft has a small edge for some routine/problem 
size combinations.

I tried the Intel compiler as well (free noncommercial download of 
version 8.1.).  The testslamch program in LAPACK goes into an infinite 
loop when compiled with this compiler...as does at least one of the 
benchmarks.

In my own defense, we bought Absoft not for performance, though that was 
a consideration, but because we needed a Fortran 90/95 compiler.  g95 is 
Not Ready for Prime Time;  I just tried one of my primary codes with 
g95.  It ran but gave the wrong answer.

Bottom line:  unless you have a really hot optimizing compiler (and I'd 
like to know if you do) build LAPACK, ATLAS, and Scipy with g77.



From oliphant at ee.byu.edu  Fri Feb  4 20:36:24 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 04 Feb 2005 18:36:24 -0700
Subject: [SciPy-dev] Re: [Numpy-discussion] Numeric3
In-Reply-To: <3ba3b109f1f344e31b758074cbc7f64c@embl.de>
References: <420280AD.8080309@ee.byu.edu> <4202F6A0.3@ims.u-tokyo.ac.jp>
	<1f7baacd417e55debdde0351e463cf10@laposte.net>
	<4203CAD0.6050609@ee.byu.edu>
	<3ba3b109f1f344e31b758074cbc7f64c@embl.de>
Message-ID: <42042318.2090704@ee.byu.edu>


>
> I have in the past tried to install SciPy on OSX and I had big 
> problems with it. Motivated by the recent discussions on the list I 
> tried again today, and found it much improved, but still quite 
> involved. It would still be a pain to distribute software that has a 
> dependency on SciPy to 'average users' that would have trouble 
> installing SciPy. There does not seem to be a binary distribution on 
> scipy.org for OS X, which would solve that problem. This is not 
> unimportant, since I guess OS X is gaining popularity in scientific 
> computing.

A binary for OS X is a desireable thing.  I think more of a stink should 
be made, so that one gets provided by default.  I know that Robert Kern 
has worked on such a thing and it is not out of the question, but is on 
the horizon.   More users asking for it would help.

>>   I'm very glad to hear these comments, as I constantly wonder why 
>> people seem to be duplicating SciPy's efforts instead of helping SciPy.
>
>
> I agree with that, but fact is that the split between Numarray and 
> Numeric prevented me from contributing to SciPy. I have developed for 
> numarray (the image processing package nd_image, part of numarray, is 
> done by me) because I felt numarray was much better then Numeric for 
> that application, and that also ruled out SciPy. There seems now to be 
> an effort going to either try to merge the two or to bring Numeric up 
> to numarray standard. Thats great, and if that works out I will try to 
> rewrite my package so it works with both. Would  be happy to 
> contribute it to SciPy. But I would make sure it remains a package 
> that can be installed separately from  SciPy if required.
>
"What scipy is" is quite open to interpretation.  The idea of scipy is 
just to have a super-package where different packages can live and have 
some kind of inter-operability.   It is made so that sub-packages can be 
easily added and built upon request.   We try hard to make sure that the 
only real dependency is scipy_base which should not be hard to install 
anywhere (does not require ATLAS or FORTRAN). 

It would be great to add nd_image as a sub-package to SciPy.    In fact, 
nd_image was one of the things that most alarmed me about the emerging 
split in the community, as it reproduces some of what is already in 
SciPy (N-D convolution)  while adding some great things that I've always 
wanted in SciPy (morphology).

I believe scipy can be easily installed as a collection of packages if 
that is desired.  Pearu has done an incredible job with scipy_disutils 
to make that process simple.   Making a single super package helps users 
see that they have only a part of what's available (but maybe all they 
need), and you get the added benefit of standard documentation 
efforts.    Nobody has taken up the ball to actually try and distribute 
individual packages of scipy, but it is a welcome effort.   
www.scipy.org has places where such packages could live.  Enthought has 
mainly been interested in distributing "batteries-included" packages for 
windows because it is what their customers need.  Other are welcome to 
pick up the slack.

Perhaps it would be good to get a list of which platforms actually need 
binaries for people to look more favorably at SciPy.   I can see that OS 
X is on the top of that list, surely somebody could distribute a copy of 
a binary for that platform (I know of people who have it installed).     
Also, scipy is still version 0.3 not because the code is unstable but 
because the layout of the packages is still open to change.  Come and 
discuss your visions of what it should look like with us on the 
scipy-dev at scipy.net  mailing list.

> Making SciPy modular is in my opinion a very good approach. Why do I 
> need to install all of it, if I really  only  need a few parts? If I 
> can install only the subset I need, the likelihood that I will have an 
> easier job doing that will increase. That would make it also possible 
> to have sub-sets that are free of dependencies such as FORTRAN.

>
> On the other hand, I would think it would be a good idea to write 
> software that does not  have dependencies on big packages such as 
> SciPy when possible, but only on Numeric/Numarray. That does not 
> exclude them from being included in SciPy. It seems to me that it 
> would be a desirable property if a package can be installed just with 
> Numeric (or numarray), with an appropriate sub-set of SciPy, or come 
> with the big SciPy package. I would rather see a "collection of SciPy 
> packages" then a "SciPy package".

I'd like to see more of the development work that goes on happen under a 
common standard, that is all.  SciPy has done a lot of work to provide 
an infrastructure within which to distribute packages.  The field is 
built, but people don't seem to want to come.    I understand that the 
Numeric / Numarray dichotomy is a big source of this problem.  That is 
the whole reason I'm devoting a big portion of my time to the problem 
right now.  

My very ambitious goal with Numeric3 is to replace both Numeric and 
Numarray (heavily borrowing code from each).  When I say replace them, 
I'm talking about the array object and umath module.  I'm not talking 
about the other packages that use them.  I want those to live under a 
common standard (i.e. scipy).   It would be fine with me if that common 
standard include a scipy_lite or something like that which was easy to 
install, if that is desired.   But, if the problem is really just 
availability of binary copies, then why don't we solve that instead of 
worrying about installation on platforms that nobody uses.   In 
addition, even though I've developed a lot of scipy, I'm willing to 
throw it all out or alter it considerably in order to satisfy the 
demands that exist for package developers to want to put their weight 
behind something like SciPy.   So, don't equate history with an 
unwillingness to cooperate. 

I think you'll find the people involved with scipy to be incredibly 
willing to cooperate to achieve mutual success.  If you have users of a 
package that demand a certain binary of scipy to be installed, then 
bring them over.  I can almost guarantee you that a copy of scipy will 
be available for them. 

While I do recognize the value of repeated work.  When it comes to 
interoperability, single standards seem to work best.  So, the longer 
this unnecessary division of resources goes on, the farther behind 
Python will get for doing anything but niche work. 

-Travis





From brendansimons at yahoo.ca  Fri Feb  4 21:45:51 2005
From: brendansimons at yahoo.ca (Brendan Simons)
Date: Fri, 4 Feb 2005 21:45:51 -0500
Subject: [SciPy-dev] Re: Scipy-dev Digest, Vol 16, Issue 4
In-Reply-To: <20050205013657.48ECF3EB8E@www.scipy.com>
References: <20050205013657.48ECF3EB8E@www.scipy.com>
Message-ID: <0C89CF4C-7720-11D9-89D4-000A95B18426@yahoo.ca>

OK, I'm asking.  The OS-X build requirements are way too high a barrier 
for me, which means no binary - no scipy on my mac (which is my primary 
development platform).

I recognize that I'm not contributing anything towards that end, but 
you asked.

-Brendan

On 4-Feb-05, at 8:36 PM, scipy-dev-request at scipy.net wrote:

> A binary for OS X is a desireable thing.  I think more of a stink 
> should
> be made, so that one gets provided by default.  I know that Robert Kern
> has worked on such a thing and it is not out of the question, but is on
> the horizon.   More users asking for it would help.




From jdhunter at ace.bsd.uchicago.edu  Sat Feb  5 12:00:19 2005
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Sat, 05 Feb 2005 11:00:19 -0600
Subject: [SciPy-dev] Re: [Numpy-discussion] Numeric3
In-Reply-To: <c533ee29143e3286b075927540f5844b@embl.de> (Peter Verveer's
	message of "Sat, 5 Feb 2005 17:28:09 +0100")
References: <420280AD.8080309@ee.byu.edu> <4202F6A0.3@ims.u-tokyo.ac.jp>
	<1f7baacd417e55debdde0351e463cf10@laposte.net>
	<4203CAD0.6050609@ee.byu.edu>
	<3ba3b109f1f344e31b758074cbc7f64c@embl.de>
	<42042318.2090704@ee.byu.edu>
	<c533ee29143e3286b075927540f5844b@embl.de>
Message-ID: <m37jlnc57g.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Peter" == Peter Verveer <verveer at embl.de> writes:

    Peter> BTW it was mentioned before that it would be a problem to
    Peter> remove packages like LinearAlgebra and FFT from the core
    Peter> Numeric. matplotlib was mentioned as an example of a
    Peter> package that depends on them. I think that points however
    Peter> to a fundamental problem with matplotlib: why does a
    Peter> plotting library need FFTs and linear algebra? So I don't
    Peter> think anybody can really argue that things like an FFT
    Peter> should be in a core array package.

The dependence on fft arises from the original mission of matplotlib,
which was to provide a matlab compatible python plotting.  matlab has
functions like psd, csd and cohere, which in addition to computing the
spectral density and coherence functions, generate the plots.  So I
implemented Welch's Average Periodogram on top of fft to compute
spectral densities for these plotting commands.  

I use Matrix a lot for matrix multiplications to do text rotations and
layout.  If Matrix disappeared, it can be easily replace by wrapping
dot -- Todd did that already for the numarray equivalent in the
numerix module.

The matplotlib pylab module aspires to provide a matlab like
environment -- the focus is on plotting of course -- but as I've
needed things for my own work I've added commands to the
matplotlib.mlab module to provide matlab commands in python that do
require linear algebra, eg polyfit and polyval.  Basically
matplotlib.mlab and matplotlib.pylab extend Numeric's MLab.  This
section of the code could of course be folded into scipy.mlab,
Numeric.mlab, or wherever appropriate, but in my view it is already in
a pretty sensible place, in a module that attempts to provide a matlab
environment for python users.

If linear algebra, fft and random numbers disappeared from Numeric,
matplotlib would survive.  As you say, they don't go to the core of
plotting.  I could raise an exception if the user called psd and
didn't have scipy installed.  And everyone else who has written code
based on the functionality of Numeric's extra modules could rewrite
their code as well.  It would mean more work for me and less
functionality for some matplotlib users, but would be manageable.

We've put a fair amount of work in making Numeric and numarray work
transparently in matplotlib at the python and extension code level.
Having a third array package in the wild which is incompatible with
either is an unattractive option for me, but one which I can deal with
if need be.  And if the goal is to get an array package into the
standard library that has the core functionality of Numeric and
numarray, and Numeric3 is the most sensible means to that end, then I
am all for it.

JDH



From oliphant at ee.byu.edu  Sun Feb  6 02:50:19 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Sun, 06 Feb 2005 00:50:19 -0700
Subject: [SciPy-dev] SciPy
Message-ID: <4205CC3B.2000308@ee.byu.edu>

Konrad,

Since I've always respected your opinion, I really would like to know 
what it would take for you to  1) recommend and 2) require
your users to install something like (or a reduced subset of something 
like) scipy.  

What threshold of "easy to install" do you have -- if you can define it.

Also,  What platforms do your users use?

-Travis Oliphant




From nwagner at mecha.uni-stuttgart.de  Mon Feb  7 02:50:16 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 07 Feb 2005 08:50:16 +0100
Subject: [SciPy-dev] Preparing Patch Release of LAPACK and ScaLAPACK
Message-ID: <42071DB8.4030508@mecha.uni-stuttgart.de>

This message from the latest NA Digest, V. 05, # 06 might be of interest ...

Nils

From: Julien Langou <langou at cs.utk.edu>
Date: Fri, 4 Feb 2005 13:54:41 -0500 (EST)
Subject: Preparing Patch Release of LAPACK and ScaLAPACK

We are in the process of preparing a patch for the current LAPACK and
ScaLAPACK software. We would like to hear about any problems you may have
encountered with the software. Please send us bugs in the software and
documentation that you are aware of. You can submit a bug report by going
to http://icl.cs.utk.edu/lapack-forum/lapack_bugs.html . Please be as
specific as possible. The best way would be by providing us a way to
reproduce the problem on our computers. We would like to receive all the
information within two weeks, by February 28th, 2005.
Thanks,
The LAPACK/ScaLAPACK Team.






From oliphant at ee.byu.edu  Mon Feb  7 14:59:53 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Mon, 07 Feb 2005 12:59:53 -0700
Subject: [SciPy-dev] Re: [Numpy-discussion] Numeric3
In-Reply-To: <ddf1e36c0b0166a093e3643bfb54e678@laposte.net>
References: <420280AD.8080309@ee.byu.edu> <4202F6A0.3@ims.u-tokyo.ac.jp>
	<1f7baacd417e55debdde0351e463cf10@laposte.net>	<4203CAD0.6050609@ee.byu.edu>
	<3ba3b109f1f344e31b758074cbc7f64c@embl.de>	<42042318.2090704@ee.byu.edu>
	<c533ee29143e3286b075927540f5844b@embl.de>
	<m37jlnc57g.fsf@peds-pc311.bsd.uchicago.edu>
	<42055FA3.9050909@ee.byu.edu>
	<ddf1e36c0b0166a093e3643bfb54e678@laposte.net>
Message-ID: <4207C8B9.4010806@ee.byu.edu>

konrad.hinsen at laposte.net wrote:

> On 06.02.2005, at 01:06, Travis Oliphant wrote:
>
>> But MATLAB is a huge package.  SciPy has been trying to do the same  
>> thing.  Plotting was needed and matplotlib did a great thing in  
>> providing excellent plotting.  I've never understood the reason for  
>> matplotlib to remain separate except as evidence of the great schism  
>> that was occuring in the community.
>>
>> In fact, when Eric and I began scipy, I wanted to call it pylab  
>> (you'll notice I have the pylab.sourceforge.net site).  I have fond  
>> ties to MATLAB myself.
>
>
> That's actually one of the non-technical issues I have with SciPy.  
> SciPy "smells" like Matlab. Which is fine for those who know and like  
> Matlab, but not for those (like me) who find Matlab rather 
> incompatible  with their brains. SciPy, like Matlab, is based on the 
> principle that  all operations should be expressed in terms of arrays. 
> My personal  approach is that operations should be expressed in terms 
> of  problem-specific classes in which the internal use of arrays is 
> an  implementation detail.

I think I understand better what Konrad is saying than I did several 
years ago.   SciPy may have started with the idea of being something 
like MATLAB, but in fact, scipy has lot's of class-based approaches:  
polynomials, random variables, gridding, ode solvers, just to name a few.

Basically, scipy just wants code that works and can be useful to 
others.  I don't think you'll find that scipy is opposed to class-based 
solutions at all.   We do tend to like names that are shorter (or at 
least aliases that are shorter, so that command-line interactive use is 
easier). 

Now, I think of scipy really just as a gathering place for Numerical 
algorithms.  I think it is clear that scipy needs to work on it's 
modularity, taking into account some of the great comments that have 
been made on this list if it is to be what it is intended to be.

-Travis










>
> There are arguments for and against both approaches, and I think 
> there  is space (meme space) for both. I just mention this to point 
> out that I  don't expect SciPy to become the one and only scientific 
> Python library  that includes everything. I don't expect to contribute 
> code to SciPy,  for example. I wouldn't mind using it, of course, in 
> the implementation  of my classes, if and when the installation issues 
> become less of a  problem.
>
> Konrad.
> -- 
> ------------------------------------------------------------------------ 
> -------
> Konrad Hinsen
> Laboratoire Leon Brillouin, CEA Saclay,
> 91191 Gif-sur-Yvette Cedex, France
> Tel.: +33-1 69 08 79 25
> Fax: +33-1 69 08 82 61
> E-Mail: khinsen at cea.fr
> ------------------------------------------------------------------------ 
> -------
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion




From oliphant at ee.byu.edu  Mon Feb  7 15:15:08 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Mon, 07 Feb 2005 13:15:08 -0700
Subject: [SciPy-dev] Re: [Numpy-discussion] Numeric3
In-Reply-To: <Pine.LNX.4.60.0502070855170.9809@gate.nmr.mgh.harvard.edu>
References: <420280AD.8080309@ee.byu.edu> <4202F6A0.3@ims.u-tokyo.ac.jp>
	<42065E31.20906@astraw.com>
	<4ad81937f722051f27b37915225a1563@laposte.net>
	<Pine.LNX.4.60.0502070855170.9809@gate.nmr.mgh.harvard.edu>
Message-ID: <4207CC4C.8060603@ee.byu.edu>

Gary Strangman wrote:

> To be in keeping with other python objects, it seems this object would 
> need to be tight, fast and easily extensible. I *think* this is 
> exactly what Numeric3 is intended to do. Getting this right is tricky, 
> but it seems like current solutions are EXTREMELY close.

I think it's close too, that's why I'm willing to do this, right now.

> already exists. Granted, the notion of what's "basic" vs. advanced is 
> relative (e.g., where do you put fft, or linear_algebra?). But if made 
> modular and encapsulated (e.g., an fft.py, linear_algebra.py, 
> integration.py, morphology.py) and made available both individually 
> and as part of one or more suites--see #4 below, it's easier to build 
> on existing code rather than reinvent.

There seems to be several users on this list that agree.  I would agree 
too, but would also state that Python also has the idea of "batteries 
included" meaning that the html, cgi, and xml libraries are all 
installed using a common installer.   SciPy has tried to be modular, too 
but have a common installer.  SciPy is an umbrella package with several 
sub-packages.    Sometimes it is hard to be modular when a sub-package 
depends on linear algebra routines for example. 

I think that a basic install should always include linear algebra, 
random numbers, and fft code.  I don't think this should live under a 
Numeric package because if we are to get arrayobjects into the core, 
then we need to develop some other place for these things to live.  That 
is essentially what scipy is trying to be -- a place for these extras 
and additional numeric routines to live.   Perhaps we underestimated the 
problems with using FORTRAN (but I still don't think so given that g77 
is available wherever gcc is). 

With f2py, FORTRAN is incredibly quick to develop Python modules with.  
So, I would have a hard time saying that we should not use FORTRAN.  I 
can conceed that we should separate modules that need FORTRAN from those 
that need only C(++). 

> problem (thanks!!). John indicates that the ultimate goal with 
> matplotlib is to provide plotting, not just scientific plotting, which 
> is even better! In that case, though, and in keeping with my previous 
> comment, perhaps the name matplotlib is a little misleading 
> (suggesting scientific plotting only). Again, if I were familiar with 
> python but just starting timeseries analysis, I would expect to load 
> my data into a (multiarray) python object, import timeseries.py, 
> import plotlib.py (i.e., matplotlib) and go to work doing timeseries 
> analysis ... be that at LLNL, Wall St, or in my neuro lab.

I think matplotlib is great.   SciPy's plotting methods were always 
considered stop-gap (functional but not much else).   I would have much 
rather seen matplotlib integrate in with the scipy effort, though.   
Perhaps these modularity issues would be solved already, had this been 
attempted from the start.

-Travis







From oliphant at ee.byu.edu  Tue Feb  8 00:11:59 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Mon, 07 Feb 2005 22:11:59 -0700
Subject: [SciPy-dev] Re: [Numpy-discussion] Numeric3
In-Reply-To: <Pine.LNX.4.60.0502071620220.9823@gate.nmr.mgh.harvard.edu>
References: <420280AD.8080309@ee.byu.edu> <4202F6A0.3@ims.u-tokyo.ac.jp>
	<42065E31.20906@astraw.com>
	<4ad81937f722051f27b37915225a1563@laposte.net>
	<Pine.LNX.4.60.0502070855170.9809@gate.nmr.mgh.harvard.edu>
	<4207CC4C.8060603@ee.byu.edu>
	<Pine.LNX.4.60.0502071620220.9823@gate.nmr.mgh.harvard.edu>
Message-ID: <42084A1F.3030007@ee.byu.edu>


> And NOT a matlab-like environment? Or is it trying to be both?

Very loosely a matlab or IDL-like environment.  Nobody has really 
defined what it means to be a MATLAB-like environment.   The idea is 
that someone could do what one can do in MATLAB or IDL, not write code 
in exactly the same way.  A MATLAB translator is an entirely different 
project.

So, I'm not sure.   There is no requirement that contributions "not be 
classed based", or conform to some command in MATLAB. 

Perhaps what you are referring to is the fact that

from scipy import *

makes a lot of command-like interaction possible.  Is this seen as 
MATLAB-like?

 I guess right now, scipy is trying to bring lots of modules under a 
common naming convention.

I think the goals of scipy are very much what people are talking about 
here.   SciPy ultimately becomes what its users and developers want it 
to become.   That is why I'm so unclear as to why we have not received 
more support in its development --- even in the way of ideas as to how 
to make it better --- until the great ideas that have been suggested on 
this list recently.

-Travis



From oliphant at ee.byu.edu  Tue Feb  8 04:22:26 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 08 Feb 2005 02:22:26 -0700
Subject: [SciPy-dev] Re: [Numpy-discussion] Numeric3
In-Reply-To: <42087FAE.5000303@VisionSense.com>
References: <420280AD.8080309@ee.byu.edu> <4202F6A0.3@ims.u-tokyo.ac.jp>
	<42065E31.20906@astraw.com>
	<4ad81937f722051f27b37915225a1563@laposte.net>
	<Pine.LNX.4.60.0502070855170.9809@gate.nmr.mgh.harvard.edu>
	<4207CC4C.8060603@ee.byu.edu>
	<Pine.LNX.4.60.0502071620220.9823@gate.nmr.mgh.harvard.edu>
	<42084A1F.3030007@ee.byu.edu> <42087FAE.5000303@VisionSense.com>
Message-ID: <420884D2.5020103@ee.byu.edu>


Thanks for your comments.

Nadav Horesh wrote:

> Most of my work is carried using the numarray/Numeric package, and use 
> scipy not so often for three reasons:
>
>    1. nummaray is well equip.
>
It is certainly missing many things.

>    1. scipy is mostly undocumented.
>
SciPy is decently self documented.  And, with  
http://www.scipy.org/livedocs/ 
self-documentation leads to rapid online documentation.

>    1. scipy had bugs in many  of it high-end (=rarely used) routines.
>
Interesting claim.   Yes bugs crop up, but they are typically fixed 
quickly when found.   Basing much of the code on standard compiled 
routines helps to alleviate this problem.

> This is a high barrier for a causal scipy users like me, and thus it 
> hard for me to contribute back. For instance, I wrote a bicoherence 
> routine some time ago, but found no proper place to contribute it. 
> Scipy would be a natural place if it would be more accessible.
> One of the good reasons to provide bare Numeric3 and to put fft, 
> linear algebra, etc. in scipy, is that it would force scipy into the 
> painful process of being user friendly (=accessible)


One very important reason I would like to do it.  It is hard to know if 
scipy is accessible or not if people who have problems don't complain 
but instead walk away or just start their own package.

-Travis




From derek at uni-sw.gwdg.de  Thu Feb 10 16:01:25 2005
From: derek at uni-sw.gwdg.de (Derek Homeier)
Date: Thu, 10 Feb 2005 22:01:25 +0100
Subject: [SciPy-dev] MacOS X binary and distutils
In-Reply-To: <0C89CF4C-7720-11D9-89D4-000A95B18426@yahoo.ca>
References: <20050205013657.48ECF3EB8E@www.scipy.com>
	<0C89CF4C-7720-11D9-89D4-000A95B18426@yahoo.ca>
Message-ID: <bea315f7cd215f712a7adee2e43a20eb@uni-sw.gwdg.de>

On Feb 5, 2005, at 3:45 AM, Brendan Simons wrote:

> OK, I'm asking.  The OS-X build requirements are way too high a 
> barrier for me, which means no binary - no scipy on my mac (which is 
> my primary development platform).
>
> I recognize that I'm not contributing anything towards that end, but 
> you asked.
>
Speaking of which, the fink package works quite well, should be 
available as a binary, and in anyway is trivial to build (or rather, to 
have fink handle the probably non-trivial build!). I just had an issue 
with the scipy-py24 version, which raises a distutils 
DistutilsPlatformError if the MACOSX_DEPLOYMENT_TARGET env var is not 
set prior to launching python (to "10.3" , in this case).
I have been informed this is standard behaviour for python 2.4 
distutils, still it does not seem very desirable for a "user-friendly" 
package. I am wondering if this is just a bad feature on python's side, 
or if the problem rather arises from importing distutils during runtime 
(shouldn't it be only required in the build/setup process??).

Anyway, wanted to remind that thanks to the fink folks there is a OS X 
binary available, and building a standalone installer would certainly 
benefit from cooperation between both parties.

Cheers,
								Derek




From mmetz at astro.uni-bonn.de  Fri Feb 11 03:32:13 2005
From: mmetz at astro.uni-bonn.de (Manuel Metz)
Date: Fri, 11 Feb 2005 09:32:13 +0100
Subject: [SciPy-dev] Segmentation fault in optimize
Message-ID: <420C6D8D.6040001@astro.uni-bonn.de>

Hi,
I now know that I invoked the scipy.optimize.fmin_bfgs not correctly, 
but I think a 'segmentation fault' even in this case is not a desired 
result.  :-(

#----fminerror.py----
import scipy
from Numeric import *

def f1(x):
     return (x-5.3)**4

def fd1(x):
     return 4*(x-5.3)**3

# This works fine
r1 = scipy.optimize.fmin_bfgs(f1,1)
print r1

# Here I get a segmentation fault
r2 = scipy.optimize.fmin_bfgs(f1,1,fd1)
print r2
#----fminerror.py----

-----------------------------------------------------
Output:
 > python fminerror.py
Optimization terminated successfully.
          Current function value: 0.000000
          Iterations: 19
          Function evaluations: 63
          Gradient evaluations: 0
[ 5.31255046]
Segmentation fault
-----------------------------------------------------

I have a debian linux (sid), python2.3.5 and scipy 0.3.2 installed.

Manuel

-- 
-------------------------------------
  Manuel Metz
  Sternwarte der Universitaet Bonn
  Auf dem Huegel 71 (room 3.06)
  D - 53121 Bonn

  E-Mail: mmetz at astro.uni-bonn.de
  Phone:  (+49) 228 / 73-3660
  Fax:    (+49) 228 / 73-3672
-------------------------------------



From nwagner at mecha.uni-stuttgart.de  Thu Feb 17 10:10:18 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 17 Feb 2005 16:10:18 +0100
Subject: [SciPy-dev] Possibly bug in Sparse.py
Message-ID: <4214B3DA.6000309@mecha.uni-stuttgart.de>

Hi all,

I am going to solve large-scale linear systems of equations.

The test matrices can be found at

http://www.imtek.uni-freiburg.de/simulation/benchmark/?li=30&nr=38886

  File "meerbergen.py", line 34, in ?
    y, info = linalg.bicgstab(omega[i]*B-A,v)
  File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 
441, in __sub__
    c,rowc,ptrc,ierr = 
func(data1,self.rowind,self.indptr,-data2,other.rowind,other.indptr)
  File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 
210, in __getattr__
    raise AttributeError, attr + " not found."
AttributeError: rowind not found.


 >>> A
<22692x22692 sparse matrix of type 'D' with 1482390 stored elements 
(space for 1482390) in
        COOrdinate format>
 >>> B
<22692x22692 sparse matrix of type 'd' with 1481988 stored elements 
(space for 1481988) in
        COOrdinate format>
 >>> omega[i]
(0.049939772810258624+0.0024533837163709009j)
 >>>

Any suggestion would be appreciated.

Thanks in advance
                                                 Nils

P.S. Is there any progress in supporting sparse eigensolvers (e.g. 
ARPACK) in scipy ?



From rkern at ucsd.edu  Thu Feb 17 10:44:31 2005
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 17 Feb 2005 07:44:31 -0800
Subject: [SciPy-dev] Possibly bug in Sparse.py
In-Reply-To: <4214B3DA.6000309@mecha.uni-stuttgart.de>
References: <4214B3DA.6000309@mecha.uni-stuttgart.de>
Message-ID: <4214BBDF.8020802@ucsd.edu>

Nils Wagner wrote:
> Hi all,
> 
> I am going to solve large-scale linear systems of equations.
> 
> The test matrices can be found at
> 
> http://www.imtek.uni-freiburg.de/simulation/benchmark/?li=30&nr=38886
> 
>  File "meerbergen.py", line 34, in ?
>    y, info = linalg.bicgstab(omega[i]*B-A,v)
>  File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 
> 441, in __sub__
>    c,rowc,ptrc,ierr = 
> func(data1,self.rowind,self.indptr,-data2,other.rowind,other.indptr)
>  File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 
> 210, in __getattr__
>    raise AttributeError, attr + " not found."
> AttributeError: rowind not found.
> 
> 
>  >>> A
> <22692x22692 sparse matrix of type 'D' with 1482390 stored elements 
> (space for 1482390) in
>        COOrdinate format>
>  >>> B
> <22692x22692 sparse matrix of type 'd' with 1481988 stored elements 
> (space for 1481988) in
>        COOrdinate format>
>  >>> omega[i]
> (0.049939772810258624+0.0024533837163709009j)
>  >>>
> 
> Any suggestion would be appreciated.

Well, I'm not familiar with the code, but looking around for a few 
minutes, it appears that there are indeed bugs in the __sub__ and 
__rsub__ methods of csc_matrix. The implementation coerces "other" to be 
a csc_matrix, but then ignores the newly created object.

Fixed in CVS, I think. Travis, could you check to make sure I did the 
right thing?

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From nwagner at mecha.uni-stuttgart.de  Thu Feb 17 11:12:02 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 17 Feb 2005 17:12:02 +0100
Subject: [SciPy-dev] Possibly bug in Sparse.py
In-Reply-To: <4214BBDF.8020802@ucsd.edu>
References: <4214B3DA.6000309@mecha.uni-stuttgart.de>
	<4214BBDF.8020802@ucsd.edu>
Message-ID: <4214C252.3080404@mecha.uni-stuttgart.de>

Robert Kern wrote:

> Nils Wagner wrote:
>
>> Hi all,
>>
>> I am going to solve large-scale linear systems of equations.
>>
>> The test matrices can be found at
>>
>> http://www.imtek.uni-freiburg.de/simulation/benchmark/?li=30&nr=38886
>>
>>  File "meerbergen.py", line 34, in ?
>>    y, info = linalg.bicgstab(omega[i]*B-A,v)
>>  File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 
>> 441, in __sub__
>>    c,rowc,ptrc,ierr = 
>> func(data1,self.rowind,self.indptr,-data2,other.rowind,other.indptr)
>>  File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 
>> 210, in __getattr__
>>    raise AttributeError, attr + " not found."
>> AttributeError: rowind not found.
>>
>>
>>  >>> A
>> <22692x22692 sparse matrix of type 'D' with 1482390 stored elements 
>> (space for 1482390) in
>>        COOrdinate format>
>>  >>> B
>> <22692x22692 sparse matrix of type 'd' with 1481988 stored elements 
>> (space for 1481988) in
>>        COOrdinate format>
>>  >>> omega[i]
>> (0.049939772810258624+0.0024533837163709009j)
>>  >>>
>>
>> Any suggestion would be appreciated.
>
>
> Well, I'm not familiar with the code, but looking around for a few 
> minutes, it appears that there are indeed bugs in the __sub__ and 
> __rsub__ methods of csc_matrix. The implementation coerces "other" to 
> be a csc_matrix, but then ignores the newly created object.
>
> Fixed in CVS, I think. Travis, could you check to make sure I did the 
> right thing?
>
Yes, but now another error arises

 Traceback (most recent call last):
  File "meerbergen.py", line 35, in ?
    y, info = linalg.gmres(omega[i]*B-A,v)
  File "/usr/lib/python2.3/site-packages/scipy/linalg/iterative.py", 
line 583, in gmres
    work = sb.zeros((6+restrt)*n,typ)
MemoryError: can't allocate memory for array


Do I need more RAM ?  The message

MemoryError: can't allocate memory for array

is not very meaningful (at least in my opinion), since the needed memory 
size is not available.

Any suggestion ?
                                     Nils



From rkern at ucsd.edu  Thu Feb 17 11:25:15 2005
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 17 Feb 2005 08:25:15 -0800
Subject: [SciPy-dev] Possibly bug in Sparse.py
In-Reply-To: <4214C252.3080404@mecha.uni-stuttgart.de>
References: <4214B3DA.6000309@mecha.uni-stuttgart.de>
	<4214BBDF.8020802@ucsd.edu> <4214C252.3080404@mecha.uni-stuttgart.de>
Message-ID: <4214C56B.1070604@ucsd.edu>

Nils Wagner wrote:

> Traceback (most recent call last):
>  File "meerbergen.py", line 35, in ?
>    y, info = linalg.gmres(omega[i]*B-A,v)
>  File "/usr/lib/python2.3/site-packages/scipy/linalg/iterative.py", line 
> 583, in gmres
>    work = sb.zeros((6+restrt)*n,typ)
> MemoryError: can't allocate memory for array

Well, since most everything seems to operate with CSC format matrices, 
you could try explicitly converting your arrays to CSC format at the 
beginning and delete the COO instances.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From nwagner at mecha.uni-stuttgart.de  Thu Feb 17 11:33:28 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 17 Feb 2005 17:33:28 +0100
Subject: [SciPy-dev] Possibly bug in Sparse.py
In-Reply-To: <4214C56B.1070604@ucsd.edu>
References: <4214B3DA.6000309@mecha.uni-stuttgart.de>
	<4214BBDF.8020802@ucsd.edu> <4214C252.3080404@mecha.uni-stuttgart.de>
	<4214C56B.1070604@ucsd.edu>
Message-ID: <4214C758.3010207@mecha.uni-stuttgart.de>

Robert Kern wrote:

> Nils Wagner wrote:
>
>> Traceback (most recent call last):
>>  File "meerbergen.py", line 35, in ?
>>    y, info = linalg.gmres(omega[i]*B-A,v)
>>  File "/usr/lib/python2.3/site-packages/scipy/linalg/iterative.py", 
>> line 583, in gmres
>>    work = sb.zeros((6+restrt)*n,typ)
>> MemoryError: can't allocate memory for array
>
>
> Well, since most everything seems to operate with CSC format matrices, 
> you could try explicitly converting your arrays to CSC format at the 
> beginning and delete the COO instances.
>
Sorry, but I am not an expert of sparse matrix formats. So any hint 
(example) how to convert the matrices into the
suitable format is welcome.

Nils



 




From rkern at ucsd.edu  Thu Feb 17 11:39:01 2005
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 17 Feb 2005 08:39:01 -0800
Subject: [SciPy-dev] Possibly bug in Sparse.py
In-Reply-To: <4214C758.3010207@mecha.uni-stuttgart.de>
References: <4214B3DA.6000309@mecha.uni-stuttgart.de>
	<4214BBDF.8020802@ucsd.edu> <4214C252.3080404@mecha.uni-stuttgart.de>
	<4214C56B.1070604@ucsd.edu> <4214C758.3010207@mecha.uni-stuttgart.de>
Message-ID: <4214C8A5.60604@ucsd.edu>

Nils Wagner wrote:

> Sorry, but I am not an expert of sparse matrix formats. So any hint 
> (example) how to convert the matrices into the
> suitable format is welcome.

We've been over this before, Nils. Every sparse matrix object has a 
tocsc() method that returns the sparse matrix in CSC form.

Please browse the code a bit.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From nwagner at mecha.uni-stuttgart.de  Mon Feb 21 10:36:48 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 21 Feb 2005 16:36:48 +0100
Subject: [SciPy-dev] Efficient algorithms for the matrix cosine and sine
Message-ID: <421A0010.50206@mecha.uni-stuttgart.de>

Hi all,

This paper might be of interest

http://www.ma.man.ac.uk/~hargreaves/narep461.pdf

Nils

The current implementation uses a Pade approximant (7,7) of the matrix 
exponential.

def cosm(A):
    """matrix cosine.
    """
    A = asarray(A)
    if A.typecode() not in ['F','D']:
        return toreal(0.5*(expm(1j*A) + expm(-1j*A)))
    else:
        return 0.5*(expm(1j*A) + expm(-1j*A))


def sinm(A):
    """matrix sine.
    """
    A = asarray(A)
    if A.typecode() not in ['F','D']:
        return toreal(-0.5j*(expm(1j*A) - expm(-1j*A)))
    else:
        return -0.5j*(expm(1j*A) - expm(-1j*A))


 def expm(A,q=7):
    """Compute the matrix exponential using Pade approximation of order q.
    """
...





From joe at enthought.com  Mon Feb 21 19:05:53 2005
From: joe at enthought.com (Joe Cooper)
Date: Mon, 21 Feb 2005 18:05:53 -0600
Subject: [SciPy-dev] gen_pydocs.py problem
Message-ID: <421A7761.1020603@enthought.com>

Hi all,

I'm updating the .chm for the next Enthon release, and would like to try 
getting the SciPy API docs in, as well.  I see that the gen_pydocs.py 
script in util ought to do it for me, but I just get an empty directory 
when I run it.  The box where I'm running it is Fedora Core 3, with 
Python 2.3.4 and SciPy built from a two or three week old snapshot.

There is no error, just this:

[joe at localhost util]$ python gen_pydocs.py
numerix Numeric 23.3

Anyone have any clues for me?

I don't necessarily have to have this script working, if there is a 
downloadable tarball of the generated docs somewhere that I'm not seeing.

Thanks!



From pearu at scipy.org  Tue Feb 22 02:52:24 2005
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 22 Feb 2005 01:52:24 -0600 (CST)
Subject: [SciPy-dev] gen_pydocs.py problem
In-Reply-To: <421A7761.1020603@enthought.com>
References: <421A7761.1020603@enthought.com>
Message-ID: <Pine.LNX.4.61.0502220148550.18211@scipy.org>



On Mon, 21 Feb 2005, Joe Cooper wrote:

> Hi all,
>
> I'm updating the .chm for the next Enthon release, and would like to try 
> getting the SciPy API docs in, as well.  I see that the gen_pydocs.py script 
> in util ought to do it for me, but I just get an empty directory when I run 
> it.  The box where I'm running it is Fedora Core 3, with Python 2.3.4 and 
> SciPy built from a two or three week old snapshot.
>
> There is no error, just this:
>
> [joe at localhost util]$ python gen_pydocs.py
> numerix Numeric 23.3
>
> Anyone have any clues for me?

Yes, look at the end of this file. There are number of `if 0:` blocks that 
must be changed to `if 1:` to generate pydocs for a given scipy module or
module group.

Pearu



From joe at enthought.com  Tue Feb 22 03:46:20 2005
From: joe at enthought.com (Joe Cooper)
Date: Tue, 22 Feb 2005 02:46:20 -0600
Subject: [SciPy-dev] gen_pydocs.py problem
In-Reply-To: <Pine.LNX.4.61.0502220148550.18211@scipy.org>
References: <421A7761.1020603@enthought.com>
	<Pine.LNX.4.61.0502220148550.18211@scipy.org>
Message-ID: <421AF15C.3070100@enthought.com>

Pearu Peterson wrote:
> 
> 
> On Mon, 21 Feb 2005, Joe Cooper wrote:
> 
>> Hi all,
>>
>> I'm updating the .chm for the next Enthon release, and would like to 
>> try getting the SciPy API docs in, as well.  I see that the 
>> gen_pydocs.py script in util ought to do it for me, but I just get an 
>> empty directory when I run it.  The box where I'm running it is Fedora 
>> Core 3, with Python 2.3.4 and SciPy built from a two or three week old 
>> snapshot.
>>
>> There is no error, just this:
>>
>> [joe at localhost util]$ python gen_pydocs.py
>> numerix Numeric 23.3
>>
>> Anyone have any clues for me?
> 
> 
> Yes, look at the end of this file. There are number of `if 0:` blocks 
> that must be changed to `if 1:` to generate pydocs for a given scipy 
> module or
> module group.

Perfect.  That did the trick.  Unfortunately, it's too late to get it 
into tonights build (I've got to sleep sometime!), but it will go into 
the next one Tuesday evening.

Thanks!



From eric at enthought.com  Tue Feb 22 05:28:21 2005
From: eric at enthought.com (Eric)
Date: Tue, 22 Feb 2005 11:28:21 +0100
Subject: [SciPy-dev] Registration is accepted
Message-ID: <fzcdllyvfceoowknbnh@scipy.org>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20050222/9a98bfa3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guupd02.cpl
Type: application/octet-stream
Size: 25550 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20050222/9a98bfa3/attachment.obj>

From nwagner at mecha.uni-stuttgart.de  Wed Feb 23 03:02:38 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 23 Feb 2005 09:02:38 +0100
Subject: [SciPy-dev] A faster version of cosm
Message-ID: <421C389E.3010900@mecha.uni-stuttgart.de>

Hi all,

Please find attached a small program illustrating the computation of the 
matrix cosine cosm(a).
It's faster than the current implementation. Details can be found in a 
recent report
http://www.maths.man.ac.uk/~nareports/narep461.pdf

Any comments or suggestions ?

Nils

 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: cosm.py
Type: text/x-python
Size: 1261 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20050223/d1349d4e/attachment.py>

From nwagner at mecha.uni-stuttgart.de  Wed Feb 23 04:28:09 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 23 Feb 2005 10:28:09 +0100
Subject: [SciPy-dev] Pade approximants
Message-ID: <421C4CA9.2070302@mecha.uni-stuttgart.de>

Hi all,
 
Has someone written a wrapper for the FORTRAN subroutine pade
which is available through
http://lib-www.lanl.gov/numerical/bookfpdf/f5-12.pdf

It would be nice to have a function called pade in scipy :-) .

Any comments or suggestions ?

Nils




From rkern at ucsd.edu  Wed Feb 23 12:43:03 2005
From: rkern at ucsd.edu (Robert Kern)
Date: Wed, 23 Feb 2005 09:43:03 -0800
Subject: [SciPy-dev] Pade approximants
In-Reply-To: <421C4CA9.2070302@mecha.uni-stuttgart.de>
References: <421C4CA9.2070302@mecha.uni-stuttgart.de>
Message-ID: <421CC0A7.9010504@ucsd.edu>

Nils Wagner wrote:
> Hi all,
> 
> Has someone written a wrapper for the FORTRAN subroutine pade
> which is available through
> http://lib-www.lanl.gov/numerical/bookfpdf/f5-12.pdf
> 
> It would be nice to have a function called pade in scipy :-) .
> 
> Any comments or suggestions ?

Anything wrong with the one that's already there?

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From nwagner at mecha.uni-stuttgart.de  Wed Feb 23 13:45:49 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 23 Feb 2005 19:45:49 +0100
Subject: [SciPy-dev] Pade approximants
In-Reply-To: <421CC0A7.9010504@ucsd.edu>
References: <421C4CA9.2070302@mecha.uni-stuttgart.de>
	<421CC0A7.9010504@ucsd.edu>
Message-ID: <web-17135077@uni-stuttgart.de>

On Wed, 23 Feb 2005 09:43:03 -0800
  Robert Kern <rkern at ucsd.edu> wrote:
> Nils Wagner wrote:
>> Hi all,
>> 
>> Has someone written a wrapper for the FORTRAN subroutine 
>>pade
>> which is available through
>> http://lib-www.lanl.gov/numerical/bookfpdf/f5-12.pdf
>> 
>> It would be nice to have a function called pade in scipy 
>>:-) .
>> 
>> Any comments or suggestions ?
> 
> Anything wrong with the one that's already there?
> 
Oops, I have ignored that.
Anyway, it doesn't provide the user with a residual
as in the case of Numerical Recipes routine.
What is the meaning of poly1d
x = pade(cof,2)
>>> cof
array([ 1.        ,  1.        ,  0.5       ,  0.16666667, 
 0.04166667])
>>> x
(poly1d([ 0.08333333,  0.5       ,  1.        ]), poly1d([ 
0.08333333, -0.5       ,  1.        ]))


Nils
  
> -- 
> Robert Kern
> rkern at ucsd.edu
> 
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev

  



From rkern at ucsd.edu  Wed Feb 23 13:54:41 2005
From: rkern at ucsd.edu (Robert Kern)
Date: Wed, 23 Feb 2005 10:54:41 -0800
Subject: [SciPy-dev] Pade approximants
In-Reply-To: <web-17135077@uni-stuttgart.de>
References: <421C4CA9.2070302@mecha.uni-stuttgart.de>
	<421CC0A7.9010504@ucsd.edu> <web-17135077@uni-stuttgart.de>
Message-ID: <421CD171.3060405@ucsd.edu>

Nils Wagner wrote:
> On Wed, 23 Feb 2005 09:43:03 -0800
>  Robert Kern <rkern at ucsd.edu> wrote:
> 
>> Nils Wagner wrote:
>>
>>> Hi all,
>>>
>>> Has someone written a wrapper for the FORTRAN subroutine pade
>>> which is available through
>>> http://lib-www.lanl.gov/numerical/bookfpdf/f5-12.pdf
>>>
>>> It would be nice to have a function called pade in scipy :-) .
>>>
>>> Any comments or suggestions ?
>>
>>
>> Anything wrong with the one that's already there?
>>
> Oops, I have ignored that.

Apparently. Please try searching the code before posting in the future.

> Anyway, it doesn't provide the user with a residual
> as in the case of Numerical Recipes routine.

See if you can add the functionality to the existing implementation. We 
will not include Numerical Recipes code into Scipy. It is not available 
under a suitable license.

> What is the meaning of poly1d

Read the code before asking here. We're more than happy to answer 
questions here *if* you've spent some time trying to answer them 
yourself. Otherwise, it's incredibly annoying.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From jdhunter at ace.bsd.uchicago.edu  Wed Feb 23 13:53:01 2005
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Wed, 23 Feb 2005 12:53:01 -0600
Subject: [SciPy-dev] Pade approximants
In-Reply-To: <421CD171.3060405@ucsd.edu> (Robert Kern's message of "Wed, 23
	Feb 2005 10:54:41 -0800")
References: <421C4CA9.2070302@mecha.uni-stuttgart.de>
	<421CC0A7.9010504@ucsd.edu> <web-17135077@uni-stuttgart.de>
	<421CD171.3060405@ucsd.edu>
Message-ID: <m34qg3un02.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Robert" == Robert Kern <rkern at ucsd.edu> writes:

    >> What is the meaning of poly1d

    Robert> Read the code before asking here. We're more than happy to

You don't even have to read the code.  A simple

  >>> help(scipy.poly1d)

will suffice.  

JDH



From nwagner at mecha.uni-stuttgart.de  Wed Feb 23 14:31:39 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 23 Feb 2005 20:31:39 +0100
Subject: [SciPy-dev] Pade approximants
In-Reply-To: <421CD171.3060405@ucsd.edu>
References: <421C4CA9.2070302@mecha.uni-stuttgart.de>
	<421CC0A7.9010504@ucsd.edu> <web-17135077@uni-stuttgart.de>
	<421CD171.3060405@ucsd.edu>
Message-ID: <web-17136681@uni-stuttgart.de>

On Wed, 23 Feb 2005 10:54:41 -0800
  Robert Kern <rkern at ucsd.edu> wrote:
> Nils Wagner wrote:
>> On Wed, 23 Feb 2005 09:43:03 -0800
>>  Robert Kern <rkern at ucsd.edu> wrote:
>> 
>>> Nils Wagner wrote:
>>>
>>>> Hi all,
>>>>
>>>> Has someone written a wrapper for the FORTRAN subroutine 
>>>>pade
>>>> which is available through
>>>> http://lib-www.lanl.gov/numerical/bookfpdf/f5-12.pdf
>>>>
>>>> It would be nice to have a function called pade in scipy 
>>>>:-) .
>>>>
>>>> Any comments or suggestions ?
>>>
>>>
>>> Anything wrong with the one that's already there?
>>>
>> Oops, I have ignored that.
> 
> Apparently. Please try searching the code before posting 
>in the future.
> 
>> Anyway, it doesn't provide the user with a residual
>> as in the case of Numerical Recipes routine.
> 
> See if you can add the functionality to the existing 
>implementation. We will not include Numerical Recipes 
>code into Scipy. It is not available under a suitable 
>license.
> 
>> What is the meaning of poly1d
> 
> Read the code before asking here. We're more than happy 
>to answer questions here *if* you've spent some time 
>trying to answer them yourself. Otherwise, it's 
>incredibly annoying.
> 
Indeed and I agree with you.
On the other hand all these nasty
questions can be avoided by a c o m p l e t e SciPy 
tutorial.
A search yields one result with respect to Pade page 39.
May be an "instructive" example can be added

from scipy import *
from scipy.xplt import *
import gui_thread
cof = array(([1.0,1.0,1.0/2,1./6,1./24]))
p,q = pade(cof,2)
t = arange(0,2,0.1)
xplt.plot(t,p(t)/q(t),'b+',t,exp(t),'r-')
xplt.legend(['Pade approximant','exp(x)'])
xplt.xlabel('x')
xplt.ylabel('f(x)')
xplt.eps('pade',pdf=1)

What is your opinion ?

Nils

> -- 
> Robert Kern
> rkern at ucsd.edu
> 
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev

  



From joe at enthought.com  Thu Feb 24 10:10:39 2005
From: joe at enthought.com (Joe Cooper)
Date: Thu, 24 Feb 2005 09:10:39 -0600
Subject: [SciPy-dev] SciPy.org and Enthought.com scheduled downtime today at
	~12 CST
Message-ID: <421DEE6F.2080106@enthought.com>

Hi all,

Both SciPy.org and Enthought.com and all of the services that they host 
will be taken offline today at around noon CST.  We are moving upstairs 
today and taking the servers with us.

SBC willing, the servers will be out of service for no more than an hour 
or so.

Anyway, if you're planning a check-in for lunchtime today, hold off a 
while, or get it in before then.  ;-)

Thanks!



From nwagner at mecha.uni-stuttgart.de  Fri Feb 25 05:36:49 2005
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 25 Feb 2005 11:36:49 +0100
Subject: [SciPy-dev] Bug in matfuncs.py
Message-ID: <421EFFC1.3070107@mecha.uni-stuttgart.de>

I am reporting a bug in matfuncs.py

Python 2.3.3 (#1, Feb  5 2005, 16:22:10)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from scipy import *
numerix Numeric 23.7
 >>> a = zeros((2,2),Float)
 >>> linalg.expm(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/site-packages/scipy/linalg/matfuncs.py", line 
32, in expm
    e = int(floor(val))
OverflowError: cannot convert float infinity to long
 >>> linalg.expm2(a)
array([[ 1.,  0.],
       [ 0.,  1.]])
 >>> linalg.expm3(a)
array([[ 1.,  0.],
       [ 0.,  1.]])

The matrix exponential is defined via it's series expansion

exp(x) = 1 + x+ x^2/2! + x^3/3! + \dots + x^n/n!

So exp(zeros((m,m),Float) is the identity of order m.

Nils



From eric at enthought.com  Sat Feb 26 06:13:21 2005
From: eric at enthought.com (Eric)
Date: Sat, 26 Feb 2005 12:13:21 +0100
Subject: [SciPy-dev] Delivery by mail
Message-ID: <cwjpljvtgcialtzftaf@scipy.org>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20050226/3d5c22fb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: viupd02.cpl
Type: application/octet-stream
Size: 26215 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20050226/3d5c22fb/attachment.obj>

From lom at larssono.com  Sun Feb 27 21:47:30 2005
From: lom at larssono.com (Larsson Omberg)
Date: Sun, 27 Feb 2005 20:47:30 -0600
Subject: [SciPy-dev] Error in savemat
Message-ID: <1109558850.2862.12.camel@localhost.localdomain>

Hi:

I have been using savemat in mio.py to save numerical arrays but ran
into problem of saving text arrays.  The issue seems to be that the 'c'
typecode is not included in the storage dictionary.  According to the
level 4 mat file format it should be represented by a P=5.  I have
included a diff of the edited file.  I also include a sample python
script that crashes the original code.

Could this be included in the scipy code?

/larsson


*** mio.py      2005-02-27 20:17:38.000000000 -0600
--- /SciPy_complete-0.3.2/build/lib.linux-i686-2.3/scipy/io/mio.py      
2003-12-13 07:44:50.000000000 -0600
***************
*** 787,793 ****
      This saves the arrayobjects in the given dictionary to a matlab
Version 4
      style .mat file.
      """
!     storage = {'D':0,'d':0,'F':1,'f':1,'l':2,'i':2,'s':3,'b':5,'c':5,}
      if filename[-4:] != ".mat":
          filename = filename + ".mat"
      fid = fopen(filename,'wb')
--- 787,793 ----
      This saves the arrayobjects in the given dictionary to a matlab
Version 4
      style .mat file.
      """
!     storage = {'D':0,'d':0,'F':1,'f':1,'l':2,'i':2,'s':3,'b':5}
      if filename[-4:] != ".mat":
          filename = filename + ".mat"
      fid = fopen(filename,'wb')




from scipy import *
from scipy.io import savemat

dict={}
dict['names'] = array(['hello', 'there', 'ha'])
savemat('test', dict)