From kern at ugcs.caltech.edu  Mon Nov  3 21:08:38 2003
From: kern at ugcs.caltech.edu (Robert Kern)
Date: Mon, 3 Nov 2003 18:08:38 -0800
Subject: [SciPy-dev] Bug in F-distribution
Message-ID: <20031104020838.GA6769@zloty.ugcs.caltech.edu>

In answering a SciPy question on c.l.py, I noticed that there's a bug in the PPF
of the F-distribution.

from scipy.stats.distributions import f
x1 = 4.26
Fx1 = f.cdf(x1, 2, 9)
x2 = f.ppf(Fx1, 2, 9)
x3 = f.ppf(1.0-Fx1, 2, 9)

# x1 is not even close to x2
# but x3 is

-- 
Robert Kern
kern at ugcs.caltech.edu

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


From fperez at colorado.edu  Thu Nov 13 17:19:53 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Thu, 13 Nov 2003 15:19:53 -0700
Subject: [SciPy-dev] Strange import-related bug caused by scipy
Message-ID: <3FB40389.7050209@colorado.edu>

Here's how to reproduce it.

Start with two very simple files:

planck[import]> cat one.py
from weave import inline,converters

planck[import]> cat two.py
import scipy

import one

Here's what happens if you execfile() these:


planck[import]> python
Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> execfile("one.py")
 >>> execfile("two.py")
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "two.py", line 3, in ?
     import one
   File "one.py", line 1, in ?
     from weave import inline,converters
ImportError: cannot import name converters

Now, the funny thing is that if you reverse the order of the imports in two.py 
and put 'import scipy' _last_, then there's no problem.   Somehow, the games 
scipy plays with the import mechanism are breaking something.

For the time being, I've resorted to putting my 'import scipy' statements last 
in my code.

Best,

f.


From pearu at scipy.org  Sat Nov 15 17:19:14 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 15 Nov 2003 16:19:14 -0600 (CST)
Subject: [SciPy-dev] Strange import-related bug caused by scipy
In-Reply-To: <3FB40389.7050209@colorado.edu>
Message-ID: <Pine.LNX.4.44.0311151615050.18772-100000@scipy.org>



On Thu, 13 Nov 2003, Fernando Perez wrote:

> Here's how to reproduce it.
> 
> Start with two very simple files:
> 
> planck[import]> cat one.py
> from weave import inline,converters
> 
> planck[import]> cat two.py
> import scipy
> 
> import one
> 
> Here's what happens if you execfile() these:
> 
> 
> planck[import]> python
> Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
> [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> execfile("one.py")
>  >>> execfile("two.py")
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "two.py", line 3, in ?
>      import one
>    File "one.py", line 1, in ?
>      from weave import inline,converters
> ImportError: cannot import name converters

This bug was related to previous ppimport bug that you reported
some time ago. Then the fix was not general enough as the example above 
demonstrates.  Now the bug should be fixed in CVS, hopefully for good.

Pearu



From arnd.baecker at web.de  Sun Nov 16 04:57:46 2003
From: arnd.baecker at web.de (Arnd Baecker)
Date: Sun, 16 Nov 2003 10:57:46 +0100 (CET)
Subject: [SciPy-dev] band matrices in scipy
Message-ID: <Pine.LNX.4.51.0311161056180.17616@ptpcp2.phy.tu-dresden.de>

Hi,

I am in the progress of wrapping the Lapack dsbev.f routine
(for band-matrices). Thanks to the amazing f2py I got pretty far
(actually in addition the good docs and Fernandos notes helped a lot!).
Once this is finished I would be happy to see this included in scipy ;-).

But before this could happen I have a couple of questions
(sorry, the text below is long,  but I wanted to be explicit ;-):
  - Is the following way of calling dsbev from python alright,
    (eg., I omitted ldab on the python side.)
    Would that parameter be useful to someone so that it is
    better to expose it (the full details of my few pyf lines are at
    the end of this mail)?

    In [7]: MODULENAME.dsbev?
    Type:           fortran
    String Form:    <fortran object at 0x4028ebf0>
    Namespace:      Interactive
    Docstring:
        dsbev - Function signature:
          w,z,info = dsbev(ab,[compute_v,lower])
        Required arguments:
          ab : input rank-2 array('d') with bounds (ldab,*)
        Optional arguments:
          compute_v := 1 input int
          lower := 0 input int
        Return objects:
          w : rank-1 array('d') with bounds (n)
          z : rank-2 array('d') with bounds (ldz,ldz)
          info : int

  - How can one supply better doc-strings to this routine?
    I.e., help(MODULENAME.dsbev) just gives
      "Help on fortran: <fortran object>"
    and scipy.info gives the same as ? from Ipython.

    I would like to add a more detailed description and an example.
    Is this somehow possible to do from within the .pyf wrapper?
        (I know that this is a pure f2py question, so maybe I should
         ask this question as well on the f2py mailing list...)

  - And one more technical aspect (before I forget about it):
    Is the wrapping done such that for _large_ matrices
    no unnecessary copies of arrays are made?

  - One thing which puzzled me a bit (presumably it is
    alright) concerns the return object z which contains the
    eigenvectors if compute_v=1. For compute_v=0
    I changed ldz in the wrapper such that it is of length 1
    (it is never referenced by dsbev.f). So if someone
    is just interested in eigenvalues and not eigenvectors
    a dummy variable for z has to be given.
    Is this alright (for a more "low" level routine like this)?
    In principle one could write a wrapper a la scipy.linalg.eig
    for the band matrices, but for my purposes I don't mind
    about the (sometimes needed) dummy variable.

  - Is the following correct?
    To get this into scipy.linalg.flapack the
    lines from MODULENAME.pyf have to be added to generic_flapack.pyf
    and <tchar=s,d> and <type_in_c>* and <type_in>
    have to be added at the corresponding place. And that's all?

  - Unittests: I think it would be good to have a few unit-tests
    for these routines. Presently I just created a sample
    10x10 band matrix (see below), converted this to upper band storage
    and compared the eigenvalues/eigenvectors  of scipy.linalg.eig
    with those of dsbev.
    In principle one should do this for both upper and lower
    triangle storage and for single and double.

    Would something like that be a reasonable unit-test for inclusion in
scipy
    or is there some better approach
    (better test-matrices etc.)?

  - Further routines I am thinking of wrapping in this context
    a) for symmetric band matrices: dsbevd, dsbevx
    b) for Hermitian band matrices: zhbev, zhbevd, zhbevx
    and their single precision partners.

    Any opinions?

Many thanks,


Arnd

#############################
And here the full example plus test:

MODULENAME.pyf:

# ------ snip here -------------------
!    -*- f90 -*-
python module MODULENAME ! in
    interface  ! in :MODULENAME
        !subroutine dsbev(ab,compute_v,lower) ! in :MODULENAME:dsbev.f
        subroutine dsbev(ab,compute_v,lower,n,ldab,kd,w,z,ldz,work,info) !
in :MODULENAME:dsbev.f


          callstatement
(*f2py_func)((compute_v?"V":"N"),(lower?"L":"U"),&n,&kd,ab,&ldab,w,z,&ldz,work,&info)

          callprotoargument
char*,char*,int*,int*,double*,int*,double*,double*,int*,double*,int*

          double precision dimension(ldab,*) :: ab

          integer optional,intent(in):: compute_v = 1
          check(compute_v==1||compute_v==0) compute_v
          integer optional,intent(in),check(lower==0||lower==1) :: lower =
0

          ! FIXME:  does one really need the ldab as optional argument ?
          !integer optional,check(shape(ab,0)==ldab),depend(ab) ::
ldab=shape(ab,0)
          integer intent(hide),depend(ab) :: ldab=shape(ab,0)
          integer intent(hide),depend(ab) :: n=shape(ab,1)
          integer intent(hide),depend(ab) :: kd=shape(ab,0)-1

          double precision dimension(n),intent(out),depend(n) :: w
          double  precision dimension(ldz,ldz),intent(out),depend(ldz) ::
z

          ! For compute_v=1 z is used and contains the eigenvectors
          integer intent(hide),depend(n) :: ldz=compute_v?n:1
          double precision dimension(ldz,ldz),depend(ldz) :: z

          double precision dimension(MAX(1,3*n-1)),intent(hide),depend(n)
:: work
          integer intent(out)::info
        end subroutine dsbev
    end interface
end python module MODULENAME

! This file was auto-generated with f2py (version:2.37.233-1545).
! See http://cens.ioc.ee/projects/f2py2e/
! and then modified ...
# ------ snip here -------------------


Then  (dsbev.f from lapack is needed for this)
  f2py --debug-capi -c MODULENAME.pyf dsbev.f -llapack
and a small test is
########### snip here ###########
import MODULENAME
from Numeric import *
from scipy import diag,linalg

N=10
fullmat=diag(-1.0*ones(N-1),-1)+diag(-1.0*ones(N-1),1)+diag(1.0*ones(N))

KD=2        # number of diagonals above the diagonal
LDAB=KD+1
mat=zeros( (LDAB,N),typecode=Float)

for i in arange(LDAB):       # Transform to band matrix
    mat[LDAB-i-1,i:N]=diag(fullmat,i)

w,evec,info=MODULENAME.dsbev(mat)
w_lin,evec_lin=linalg.eig(fullmat)

print sort(w)-sort(w_lin.real)

print evec[:,0]
print evec_lin[:,0]
########### snip here ###########



From pearu at scipy.org  Sun Nov 16 16:50:39 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Sun, 16 Nov 2003 15:50:39 -0600 (CST)
Subject: [SciPy-dev] band matrices in scipy
In-Reply-To: <Pine.LNX.4.51.0311161056180.17616@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.44.0311161457260.18772-100000@scipy.org>


Hi,

On Sun, 16 Nov 2003, Arnd Baecker wrote:

> I am in the progress of wrapping the Lapack dsbev.f routine
> (for band-matrices). Thanks to the amazing f2py I got pretty far
> (actually in addition the good docs and Fernandos notes helped a lot!).
> Once this is finished I would be happy to see this included in scipy ;-).

Great!

> But before this could happen I have a couple of questions
> (sorry, the text below is long,  but I wanted to be explicit ;-):
>   - Is the following way of calling dsbev from python alright,
>     (eg., I omitted ldab on the python side.)
>     Would that parameter be useful to someone so that it is
>     better to expose it (the full details of my few pyf lines are at
>     the end of this mail)?
> 
>     In [7]: MODULENAME.dsbev?
>     Type:           fortran
>     String Form:    <fortran object at 0x4028ebf0>
>     Namespace:      Interactive
>     Docstring:
>         dsbev - Function signature:
>           w,z,info = dsbev(ab,[compute_v,lower])
>         Required arguments:
>           ab : input rank-2 array('d') with bounds (ldab,*)
>         Optional arguments:
>           compute_v := 1 input int
>           lower := 0 input int
>         Return objects:
>           w : rank-1 array('d') with bounds (n)
>           z : rank-2 array('d') with bounds (ldz,ldz)
>           info : int

I would set ldab=kd+1 and hide it from Python. Rationale:
(i) wrappers to other lapack functions do the same with
arguments of similar type, so, why should dsbev be different.
(ii) my guess is that users who need ldab exposed would not
call dsbev from Python in the first place.

>   - How can one supply better doc-strings to this routine?
>     I.e., help(MODULENAME.dsbev) just gives
>       "Help on fortran: <fortran object>"
>     and scipy.info gives the same as ? from Ipython.
> 
>     I would like to add a more detailed description and an example.
>     Is this somehow possible to do from within the .pyf wrapper?
>         (I know that this is a pure f2py question, so maybe I should
>          ask this question as well on the f2py mailing list...)

Currently one cannot.. f2py does not support user specified documentation 
strings yet. However, it is certainly in my TODO list and some 
relevant issues has been already resolved (I am referring to f2py 
multi-line blocks that are prerequisites for implementing 
user-docs-in-pyf-file feature).

However, help(MODULENAME.dsbev) could certainly give more
information than just '<fortran object>'. The reason why it
does not may be due to the fact that a <fortran object> does not
have a __doc__ attribute, instead, when one tries to access
<fortran object>.__doc__ then getattr function is called
that generates documentation on fly. This is f2py feature to 
reduce the size of extension modules.

>   - And one more technical aspect (before I forget about it):
>     Is the wrapping done such that for _large_ matrices
>     no unnecessary copies of arrays are made?

Yes. I have explained many times what is the underlying
mechanism for passing Python objects to Fortran and how
one should design .pyf files in order to minimize the number of 
array copies and at the same time simplify the usage of
wrappers.
Btw, with the recent f2py one can define F2PY_REPORT_ON_ARRAY_COPY 
CPP macro in order to get statistics on copies that happen inside
f2py generated wrappers.

>   - One thing which puzzled me a bit (presumably it is
>     alright) concerns the return object z which contains the
>     eigenvectors if compute_v=1. For compute_v=0
>     I changed ldz in the wrapper such that it is of length 1
>     (it is never referenced by dsbev.f). So if someone
>     is just interested in eigenvalues and not eigenvectors
>     a dummy variable for z has to be given.
>     Is this alright (for a more "low" level routine like this)?
>     In principle one could write a wrapper a la scipy.linalg.eig
>     for the band matrices, but for my purposes I don't mind
>     about the (sometimes needed) dummy variable.

Some other pyf-signatures in scipy do the same thing (i.e. set 
ldz=(compute_v?n:1)). So, it is alright for low-level functions
but for high-level functions  one must implement a Python wrapper to get 
rid of z when compute_v=0.

>   - Is the following correct?
>     To get this into scipy.linalg.flapack the
>     lines from MODULENAME.pyf have to be added to generic_flapack.pyf
>     and <tchar=s,d> and <type_in_c>* and <type_in>
>     have to be added at the corresponding place. And that's all?

Yep. But see also setup_linalg.py that provides a possibility to
skip single precision wrappers (resulting 2 times smaller extension 
modules). So, information for new functions should be added there too.

>   - Unittests: I think it would be good to have a few unit-tests
>     for these routines. Presently I just created a sample
>     10x10 band matrix (see below), converted this to upper band storage
>     and compared the eigenvalues/eigenvectors  of scipy.linalg.eig
>     with those of dsbev.
>     In principle one should do this for both upper and lower
>     triangle storage and for single and double.
> 
>     Would something like that be a reasonable unit-test for inclusion in
>     scipy

Yes. It assumes that, say, scipy.linalg.eig gives correct results and 
this is checked (in principle) in the corresponding unit-tests.
See the existing scipy.linalg unittests for examples.

>     or is there some better approach
>     (better test-matrices etc.)?

Regards,
Pearu


From kern at ugcs.caltech.edu  Sun Nov 16 17:45:34 2003
From: kern at ugcs.caltech.edu (Robert Kern)
Date: Sun, 16 Nov 2003 14:45:34 -0800
Subject: [SciPy-dev] band matrices in scipy
In-Reply-To: <Pine.LNX.4.44.0311161457260.18772-100000@scipy.org>
References: <Pine.LNX.4.51.0311161056180.17616@ptpcp2.phy.tu-dresden.de>
	<Pine.LNX.4.44.0311161457260.18772-100000@scipy.org>
Message-ID: <20031116224534.GA11055@taliesen.caltech.edu>

On Sun, Nov 16, 2003 at 03:50:39PM -0600, Pearu Peterson wrote:

[snip]

> However, help(MODULENAME.dsbev) could certainly give more
> information than just '<fortran object>'. The reason why it
> does not may be due to the fact that a <fortran object> does not
> have a __doc__ attribute, instead, when one tries to access
> <fortran object>.__doc__ then getattr function is called
> that generates documentation on fly. This is f2py feature to 
> reduce the size of extension modules.

Looking through pydoc.py (which the builtin help() calls), the problem
is that pydoc.py does not recognize a fortranobject as a function-alike.
For the interested, look at the method Doc.document. It uses the inspect
module, and that only seems to recognize the builtin function-like
types. I'll file a bug report asking for something a little smarter.

In the meantime, SciPy's info() and IPython's ? magic work just fine.

-- 
Robert Kern
kern at ugcs.caltech.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 Nov 17 11:58:37 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 17 Nov 2003 17:58:37 +0100
Subject: [SciPy-dev] From NASTRAN to MATLAB to Scipy  [Fwd: loadop4/saveop4]
Message-ID: <3FB8FE3D.398E0226@mecha.uni-stuttgart.de>

Dear experts,

I was looking for a NASTRAN/MATLAB interface. The result of
my inquiry is enclosed. Maybe Scipy can use this interface as well.

Any comments or suggestions ?


Nils
-------------- next part --------------
An embedded message was scrubbed...
From: al at danial.org
Subject: loadop4/saveop4
Date: Sun, 16 Nov 2003 19:05:05 +0100
Size: 3316
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20031117/a89cbd81/attachment.mht>

From j_r_fonseca at yahoo.co.uk  Mon Nov 17 19:28:10 2003
From: j_r_fonseca at yahoo.co.uk (=?iso-8859-1?Q?Jos=E9?= Fonseca)
Date: Tue, 18 Nov 2003 00:28:10 +0000 (UTC)
Subject: [SciPy-dev] 
	Re: From NASTRAN to MATLAB to Scipy  [Fwd: loadop4/saveop4]
References: <3FB8FE3D.398E0226@mecha.uni-stuttgart.de>
Message-ID: <bpbp2q$2i9$1@sea.gmane.org>

I haven't come around to write a parser for Nastran Output4 files as I
haven't yet needed those. But I've recently writed a parser for Output2
(both binary and neutral) result files, and I even wrote a very simple
NASTRAN OP2 -> VTK which (at the moment only) extracts the mode shapes
of a modal analysis.

See the parsers at
http://mefriss1.swan.ac.uk/cgi-bin/viewcvs.cgi/python/Nastran/ and the
converter at
http://mefriss1.swan.ac.uk/cgi-bin/viewcvs.cgi/python/nas2vtk.py

On Mon, 17 Nov 2003 17:58:37 +0100, Nils Wagner wrote:
> Dies ist eine mehrteilige Nachricht im MIME-Format.
> --------------C36602AAD19189372FC5B129
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Dear experts,
>
> I was looking for a NASTRAN/MATLAB interface. The result of
> my inquiry is enclosed. Maybe Scipy can use this interface as well.
>
> Any comments or suggestions ?
>
>
> Nils

[....]

I may or may not eventually implement those in python, but in any case,
thanks for the links!

Jose Fonseca


From nwagner at mecha.uni-stuttgart.de  Tue Nov 18 04:06:17 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 18 Nov 2003 10:06:17 +0100
Subject: [SciPy-dev] 
	scipy.test() FAILED (failures=6, errors=8) in latest cvs
Message-ID: <3FB9E109.F3664A93@mecha.uni-stuttgart.de>

Just a short report of scipy.test() with latest cvs

Nils

>>> scipy.__version__
'0.2.1_249.4430'
>>> Numeric.__version__
'23.1'
Python 2.1.2 (#1, Feb 25 2002, 18:04:21)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "copyright", "credits" or "license" for more information.

======================================================================
ERROR: check_cdf
(scipy.stats.distributions.test_distributions.test_fatiguelife)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 5, in check_cdf
  File "/usr/local/lib/python2.1/site-packages/scipy/stats/stats.py",
line 1521, in kstest
    vals = sb.sort(rvs(*args,**kwds))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 432, in rvs
    vals = reshape(self._rvs(*args),size)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 1195, in _rvs
    z = norm(size=self._size)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 761, in __call__
    raise ValueError
ValueError
======================================================================
ERROR: check_cdf
(scipy.stats.distributions.test_distributions.test_foldnorm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 5, in check_cdf
  File "/usr/local/lib/python2.1/site-packages/scipy/stats/stats.py",
line 1521, in kstest
    vals = sb.sort(rvs(*args,**kwds))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 432, in rvs
    vals = reshape(self._rvs(*args),size)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 1274, in _rvs
    return abs(norm(mu=c,size=self._size))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 761, in __call__
    raise ValueError
ValueError
======================================================================
ERROR: check_cdf
(scipy.stats.distributions.test_distributions.test_gilbrat)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 5, in check_cdf
  File "/usr/local/lib/python2.1/site-packages/scipy/stats/stats.py",
line 1521, in kstest
    vals = sb.sort(rvs(*args,**kwds))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 432, in rvs
    vals = reshape(self._rvs(*args),size)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 1738, in _rvs
    return lognorm_gen._rvs(self, 1.0)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 1718, in _rvs
    return exp(s * norm(size=self._size))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 761, in __call__
    raise ValueError
ValueError
======================================================================
ERROR: check_cdf
(scipy.stats.distributions.test_distributions.test_halfnorm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 5, in check_cdf
  File "/usr/local/lib/python2.1/site-packages/scipy/stats/stats.py",
line 1521, in kstest
    vals = sb.sort(rvs(*args,**kwds))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 432, in rvs
    vals = reshape(self._rvs(*args),size)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 1540, in _rvs
    return abs(norm(size=self._size))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 761, in __call__
    raise ValueError
ValueError
======================================================================
ERROR: check_cdf
(scipy.stats.distributions.test_distributions.test_lognorm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 5, in check_cdf
  File "/usr/local/lib/python2.1/site-packages/scipy/stats/stats.py",
line 1521, in kstest
    vals = sb.sort(rvs(*args,**kwds))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 432, in rvs
    vals = reshape(self._rvs(*args),size)
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 1718, in _rvs
    return exp(s * norm(size=self._size))
  File
"/usr/local/lib/python2.1/site-packages/scipy/stats/distributions.py",
line 761, in __call__
    raise ValueError
ValueError
======================================================================
ERROR: check_linear_constant
(scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 52, in check_linear_constant
    lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 399, in __init__
    kx,ky,eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
ERROR: check_linear_1d
(scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 72, in check_linear_1d
    lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 356, in __init__
    kx,ky,s=s,eps=eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
ERROR: check_linear_constant
(scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 62, in check_linear_constant
    lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 356, in __init__
    kx,ky,s=s,eps=eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_nct)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 10, in check_cdf
AssertionError: D = 0.62956452799; pval = 2.42827979946e-12; alpha =
0.01
args = (1.0156077768803375, 1.3891921950688992)
======================================================================
FAIL: check_pro_ang1_cv (scipy.special.cephes.test_cephes.test_cephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_cephes.py",
line 355, in check_pro_ang1_cv
    assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0))
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 519, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
DESIRED: (1.0, 0.0)
ACTUAL: (0.99999999999999989, 0.0)
======================================================================
FAIL: check_pro_ang1_cv (scipy.special.basic.test_basic.test_cephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 384, in check_pro_ang1_cv
    assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0))
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 519, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
DESIRED: (1.0, 0.0)
ACTUAL: (0.99999999999999989, 0.0)
======================================================================
FAIL: check_sph_in (scipy.special.basic.test_basic.test_sph_in)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 1939, in check_sph_in
    assert_array_almost_equal(i1n[0],array([1.00668001,0.06693370]),8)
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 592, in assert_array_almost_equal
    assert alltrue(ravel(reduced)),\
AssertionError:
Arrays are not almost equal:

======================================================================
FAIL: check_sph_jn (scipy.special.basic.test_basic.test_sph_jn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 1955, in check_sph_jn
    assert_almost_equal(s1,0.0059615249,8)
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 536, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
DESIRED: 0.0059615249
ACTUAL: 0.0
======================================================================
FAIL: check_sph_kn (scipy.special.basic.test_basic.test_sph_kn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 1972, in check_sph_kn
    assert_array_almost_equal(kn[0],array([      6.43029630, 
38.5817778]),8)
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 592, in assert_array_almost_equal
    assert alltrue(ravel(reduced)),\
AssertionError:
Arrays are not almost equal:

----------------------------------------------------------------------
Ran 959 tests in 3.447s

FAILED (failures=6, errors=8)
<unittest.TextTestRunner instance at 0x8b80ed4>


From wagner.nils at vdi.de  Tue Nov 18 05:11:37 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Tue, 18 Nov 2003 11:11:37 +0100
Subject: [SciPy-dev] scipy.test()FAILED(failures=8, errors=2)
Message-ID: <20031118101141.BDD393EB3E@www.scipy.com>

Hi all, 
 
This is the result of scipy.test() when using 
 
Python 2.3+ (#1, Sep 23 2003, 23:07:16) 
[GCC 3.3.1 (SuSE Linux)] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> scipy.__version__ 
'0.2.1_249.4433' 
 >>> Numeric.__version__ 
'23.1' 
 
====================================================================== 
ERROR: check_data 
(scipy.stats.morestats.test_morestats.test_binom_test) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/stats/tests/
test_morestats.py", line 101, in check_data 
    pval = stats.binom_test(100,250) 
  File "/usr/lib/python2.3/site-packages/scipy/stats/morestats.py", line 
683, in binom_test 
    d = distributions.binom.pdf(x,n,p) 
AttributeError: binom_gen instance has no attribute 'pdf' 
 
====================================================================== 
ERROR: check_pdf 
(scipy.stats.distributions.test_distributions.test_randint) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/stats/tests/
test_distributions.py", line 91, in check_pdf 
    vals = stats.randint.pdf(k,5,30) 
AttributeError: randint_gen instance has no attribute 'pdf' 
 
====================================================================== 
FAIL: check_simple (scipy.linalg.fblas.test_fblas.test_sgemv) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_fblas.py", 
line 315, in check_simple 
    assert(allclose(desired_y,y)) 
AssertionError 
 
====================================================================== 
FAIL: check_random_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 276, in check_random_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_simple_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 250, in check_simple_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_sph_in (scipy.special.basic.test_basic.test_sph_in) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/special/tests/
test_basic.py", line 1939, in check_sph_in 
    assert_array_almost_equal(i1n[0],array([1.00668001,0.06693370]),8) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_sph_jn (scipy.special.basic.test_basic.test_sph_jn) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/special/tests/
test_basic.py", line 1955, in check_sph_jn 
    assert_almost_equal(s1,0.0059615249,8) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 536, in 
assert_almost_equal 
    assert round(abs(desired - actual),decimal) == 0, msg 
AssertionError: 
Items are not equal: 
DESIRED: 0.0059615249 
ACTUAL: 0.0 
 
====================================================================== 
FAIL: check_sph_kn (scipy.special.basic.test_basic.test_sph_kn) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/special/tests/
test_basic.py", line 1972, in check_sph_kn 
    assert_array_almost_equal(kn[0],array([      6.43029630,  
38.5817778]),8) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_foldnorm) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "<string>", line 10, in check_cdf 
AssertionError: D = 0.312293158009; pval = 0.00212607354437; alpha 
= 0.01 
args = (1.3275833471460694,) 
 
====================================================================== 
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_nct) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "<string>", line 10, in check_cdf 
AssertionError: D = 0.434285651463; pval = 5.80078147339e-06; alpha 
= 0.01 
args = (1.7513774539410023, 1.3175489373516882) 
 
---------------------------------------------------------------------- 
Ran 1028 tests in 2.690s 
 
FAILED (failures=8, errors=2) 
<unittest.TextTestRunner object at 0x429c6acc> 
 


From prabhu at aero.iitm.ernet.in  Tue Nov 18 14:01:53 2003
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Wed, 19 Nov 2003 00:31:53 +0530
Subject: [SciPy-dev] ANN: MayaVi-1.3 released
Message-ID: <16314.27809.836219.483395@monster.linux.in>

Hi,

This is to announce the availability of the MayaVi Data Visualizer
version 1.3.

MayaVi is a free, easy to use, scientific data visualizer.  It is
written in Python and uses the Visualization Toolkit (VTK) for the
graphics.  It provides a GUI written using Tkinter.  MayaVi is free
and distributed under a BSD license.  It is also cross platform and
should run on any platform where both Python and VTK are available.

For more information, sources, binaries, screenshots, installation
instructions, documentation etc. visit the MayaVi home page at:

        http://mayavi.sourceforge.net

Also bundled with MayaVi is a VTK pipeline browser written in Python
and a utility module that makes using VTK easier from the Python
interpreter.

New in this release:

    * New Modules:
      - Volume: Volume visualization using either texture or ray cast
        mappers.  A useful GUI color transfer function editor is also
        built-in.
      - Glyph: Generic glyphs for scalars and vectors.
      - BandedSurfaceMap: Display banded contours of input data.
      - Labels: Automatic labeling of data used in other modules.
      - Text: Display 2D text strings.

    * New Filters:
      - ExtractGrid: Select part of a grid or subsample it.
      - StructuredPointsProbe: Probes any input data onto a structured
        points grid so the data can be used for Volume visualization.
      - Delaunay3D/Delaunay2D: Triangulate input point data.
      - UserDefined: Manage any user specified VTK filter.
      - CutPlane: Cut through any input dataset with a plane.

    * Support for VTK's new XML based files and for EnSight case files
      (EnSight6 and EnSightGold formats are supported).

    * Improved VectorCutPlane and VelocityVector so you can use a 3D
      arrow and any of the standard 2D glyphs.

    * The 'imv' module is now part of the mayavi.tools package.  imv
      is a simple MayaVi based module that provides Matlab like one
      liners to view 2D surfaces and arrays from the Python
      interpreter.

    * Support to save rendered scene to vector EPS/PS/PDF or save the
      text to TeX output using GL2PS.  Requires VTK to be built with
      GL2PS support (the MayaVi binaries support this).  Also added
      support for exporting to a Wavefront OBJ file.

    * Support to save the stereo rendering options, the lookup table
      settings and the lighting as defaults.
    
    * Default lookup tables have better contrast.  28 user contributed
      lookup tables are also included in the sources.  Any lookup
      table can be reversed.

    * Improved vtkPipeline modules:
      - ConfigVtkObj: Separated functionality of the ConfigVtkObj
        class into a separate ConfigVtkObjFrame and a driver class.
        More options to generate GUI's automatically.
      - VtkPickler: Can save/load state from a dictionary.      

    * Fixes for Python-2.3 and Tk-8.4 related changes.

    * Fixes for the Mac OS X.

    * Many other fixes and improvements.


Acknowledgements:

 Many thanks to the following folks.
  - Gerard Gorman: initial volume module with GUI CTF editor.
  - Axel Steuwer: initial Delaunay3D filter.
  - Richard Boardman: patch for OBJ export.
  - Fernando Perez and Arnd Baecker: user contributed lookup tables.
  - P. N. Badri Narayanan: Win32 VTK DLL's.
  - Thanks also to others who reported bugs and sent in bug fixes.


Have fun!
prabhu


From nwagner at mecha.uni-stuttgart.de  Thu Nov 20 04:40:01 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 20 Nov 2003 10:40:01 +0100
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
Message-ID: <3FBC8BF1.4F5FAE9B@mecha.uni-stuttgart.de>

Dear experts,

What is the reason for the following errors ?


=====================================================================
ERROR: check_linear_constant
(scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 52, in check_linear_constant
    lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 399, in __init__
    kx,ky,eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
ERROR: check_linear_1d
(scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 72, in check_linear_1d
    lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 356, in __init__
    kx,ky,s=s,eps=eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
ERROR: check_linear_constant
(scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 62, in check_linear_constant
    lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 356, in __init__
    kx,ky,s=s,eps=eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z

Nils


From pearu at scipy.org  Thu Nov 20 03:39:54 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 20 Nov 2003 02:39:54 -0600 (CST)
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
In-Reply-To: <3FBC8BF1.4F5FAE9B@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.44.0311200236570.28447-100000@scipy.org>



On Thu, 20 Nov 2003, Nils Wagner wrote:

> Dear experts,
> 
> What is the reason for the following errors ?
> 
> 
> =====================================================================
> ERROR: check_linear_constant
> (scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
> line 52, in check_linear_constant
>     lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
>   File
> "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
> line 399, in __init__
>     kx,ky,eps,lwrk2=1)
> error: (len(y)==m) failed for 3rd argument z

What is f2py version? You'll need f2py which supports usercode
statement, that is, f2py 2.35.229-1505 or (better) later.

Pearu


From nwagner at mecha.uni-stuttgart.de  Thu Nov 20 05:05:06 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 20 Nov 2003 11:05:06 +0100
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
References: <Pine.LNX.4.44.0311200236570.28447-100000@scipy.org>
Message-ID: <3FBC91D2.FAD744D1@mecha.uni-stuttgart.de>

Pearu Peterson schrieb:
> 
> On Thu, 20 Nov 2003, Nils Wagner wrote:
> 
> > Dear experts,
> >
> > What is the reason for the following errors ?
> >
> >
> > =====================================================================
> > ERROR: check_linear_constant
> > (scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File
> > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
> > line 52, in check_linear_constant
> >     lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
> >   File
> > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
> > line 399, in __init__
> >     kx,ky,eps,lwrk2=1)
> > error: (len(y)==m) failed for 3rd argument z
> 
> What is f2py version? You'll need f2py which supports usercode
> statement, that is, f2py 2.35.229-1505 or (better) later.
> 
> Pearu
> 

wagner at lisa:~> f2py -v
2.35.229-1505

Nils

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


From wagner.nils at vdi.de  Thu Nov 20 04:22:57 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Thu, 20 Nov 2003 10:22:57 +0100
Subject: [SciPy-dev] FAILED(failures=3)inscipy.test()
Message-ID: <20031120092302.92DD23EB34@www.scipy.com>

Hi all, 
 
Thanks for the latest bugfixes.  
Now, scipy.test() results in 3 failures. 
 
Is it possible to fix these failures as well ? 
 
====================================================================== 
FAIL: check_random_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 276, in check_random_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_simple_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 250, in check_simple_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_arcsine) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "<string>", line 10, in check_cdf 
AssertionError: D = 0.299163544178; pval = 0.00353653914938; alpha 
= 0.01 
args = () 
 
 
 


From nwagner at mecha.uni-stuttgart.de  Thu Nov 20 05:42:53 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 20 Nov 2003 11:42:53 +0100
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
References: <Pine.LNX.4.44.0311200236570.28447-100000@scipy.org>
Message-ID: <3FBC9AAD.1E61399A@mecha.uni-stuttgart.de>

Pearu Peterson schrieb:
> 
> On Thu, 20 Nov 2003, Nils Wagner wrote:
> 
> > Dear experts,
> >
> > What is the reason for the following errors ?
> >
> >
> > =====================================================================
> > ERROR: check_linear_constant
> > (scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File
> > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
> > line 52, in check_linear_constant
> >     lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
> >   File
> > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
> > line 399, in __init__
> >     kx,ky,eps,lwrk2=1)
> > error: (len(y)==m) failed for 3rd argument z
> 
> What is f2py version? You'll need f2py which supports usercode
> statement, that is, f2py 2.35.229-1505 or (better) later.
> 
> Pearu
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev

I have upgraded to the latest tarball of f2py.
However, scipy.test() results in the following errors

Is this behaviour connected with the python version or djbfft ?

Nils

======================================================================
ERROR: check_linear_constant
(scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 52, in check_linear_constant
    lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 399, in __init__
    kx,ky,eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
ERROR: check_linear_1d
(scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 72, in check_linear_1d
    lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 356, in __init__
    kx,ky,s=s,eps=eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
ERROR: check_linear_constant
(scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
line 62, in check_linear_constant
    lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1)
  File
"/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
line 356, in __init__
    kx,ky,s=s,eps=eps,lwrk2=1)
error: (len(y)==m) failed for 3rd argument z
======================================================================
FAIL: check_pro_ang1_cv (scipy.special.cephes.test_cephes.test_cephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_cephes.py",
line 355, in check_pro_ang1_cv
    assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0))
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 519, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
DESIRED: (1.0, 0.0)
ACTUAL: (0.99999999999999989, 0.0)
======================================================================
FAIL: check_pro_ang1_cv (scipy.special.basic.test_basic.test_cephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 384, in check_pro_ang1_cv
    assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0))
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 519, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
DESIRED: (1.0, 0.0)
ACTUAL: (0.99999999999999989, 0.0)
======================================================================
FAIL: check_sph_in (scipy.special.basic.test_basic.test_sph_in)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 1941, in check_sph_in
    0.066933714568029540839]),12)
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 592, in assert_array_almost_equal
    assert alltrue(ravel(reduced)),\
AssertionError:
Arrays are not almost equal:

======================================================================
FAIL: check_sph_kn (scipy.special.basic.test_basic.test_sph_kn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py",
line 1979, in check_sph_kn
    585.15696310385559829],12)
  File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py",
line 592, in assert_array_almost_equal
    assert alltrue(ravel(reduced)),\
AssertionError:
Arrays are not almost equal:

----------------------------------------------------------------------
Ran 959 tests in 7.401s

FAILED (failures=4, errors=3)
<unittest.TextTestRunner instance at 0x8b8fbcc>


From pearu at scipy.org  Thu Nov 20 04:35:33 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 20 Nov 2003 03:35:33 -0600 (CST)
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
In-Reply-To: <3FBC9AAD.1E61399A@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.44.0311200334360.29311-100000@scipy.org>



On Thu, 20 Nov 2003, Nils Wagner wrote:

> I have upgraded to the latest tarball of f2py.
> However, scipy.test() results in the following errors
> 
> Is this behaviour connected with the python version or djbfft ?

Indeed, this is Python 2.1 issue. (And has nothing to do with djbfft).

Pearu


From nwagner at mecha.uni-stuttgart.de  Thu Nov 20 06:01:13 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 20 Nov 2003 12:01:13 +0100
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
References: <Pine.LNX.4.44.0311200334360.29311-100000@scipy.org>
Message-ID: <3FBC9EF9.AD90895@mecha.uni-stuttgart.de>

Pearu Peterson schrieb:
> 
> On Thu, 20 Nov 2003, Nils Wagner wrote:
> 
> > I have upgraded to the latest tarball of f2py.
> > However, scipy.test() results in the following errors
> >
> > Is this behaviour connected with the python version or djbfft ?
> 
> Indeed, this is Python 2.1 issue. (And has nothing to do with djbfft).
> 
So, is it planned to hold scipy backward compatible with respect to
python 2.x ?
 
Nils

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


From pearu at scipy.org  Thu Nov 20 05:01:49 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 20 Nov 2003 04:01:49 -0600 (CST)
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
In-Reply-To: <3FBC9EF9.AD90895@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.44.0311200356280.29311-100000@scipy.org>



On Thu, 20 Nov 2003, Nils Wagner wrote:

> So, is it planned to hold scipy backward compatible with respect to
> python 2.x ?

Yes, as much as possible down to Python 2.1. 2.0 support has been dropped
long time ago. I think we should consider dropping also 2.1 support
starting scipy-0.3.x.

Pearu


From nwagner at mecha.uni-stuttgart.de  Thu Nov 20 09:11:52 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 20 Nov 2003 15:11:52 +0100
Subject: [SciPy-dev] FAILED (failures=2) in scipy.test() with Python2.2
Message-ID: <3FBCCBA8.148D6A9E@mecha.uni-stuttgart.de>

Dear experts,

scipy.test() with Python2.2 results in

>>> scipy.__version__
'0.2.1_249.4443'
>>> Numeric.__version__
'23.1'
>>>

======================================================================
FAIL: check_pro_ang1_cv (scipy.special.basic.test_basic.test_cephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.2/site-packages/scipy/special/tests/test_basic.py",
line 384, in check_pro_ang1_cv
    assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0))
  File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line
519, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
DESIRED: (1.0, 0.0)
ACTUAL: (0.99999999999999989, 0.0)

======================================================================
FAIL: check_pro_ang1_cv (scipy.special.cephes.test_cephes.test_cephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.2/site-packages/scipy/special/tests/test_cephes.py",
line 355, in check_pro_ang1_cv
    assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0))
  File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line
519, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
DESIRED: (1.0, 0.0)
ACTUAL: (0.99999999999999989, 0.0)

----------------------------------------------------------------------
Ran 1195 tests in 3.637s

FAILED (failures=2)
<unittest.TextTestRunner instance at 0x88fb05c>
>>>

Nils


From wagner.nils at vdi.de  Thu Nov 20 08:15:33 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Thu, 20 Nov 2003 14:15:33 +0100
Subject: [SciPy-dev] FAILED(failures=2)inscipy.test()with Python 2.3.2
Message-ID: <20031120131534.DE06B3EB34@www.scipy.com>

Dear experts, 
 
In contrast to Python 2.2 scipy.test() with Python2.3.2 results in 
other failures, namely 
 
====================================================================== 
FAIL: check_random_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 276, in check_random_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 
592, in assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_simple_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 250, in check_simple_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 
592, in assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
---------------------------------------------------------------------- 
Ran 1028 tests in 2.334s 
 
FAILED (failures=2) 
<unittest.TextTestRunner object at 0x418e820c> 
>>> 
 
For what reason ? 
 
Nils 
 
 


From wagner.nils at vdi.de  Mon Nov 24 09:58:52 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Mon, 24 Nov 2003 15:58:52 +0100
Subject: [SciPy-dev] Reason for failures inscipy.test() ?
Message-ID: <20031124145902.CEA353EB2D@www.scipy.com>

Dear experts, 
 
Can someone reproduce these failures with latest cvs ? 
 
====================================================================== 
FAIL: check_random_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 276, in check_random_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 
592, in assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_simple_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 250, in check_simple_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 
592, in assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
---------------------------------------------------------------------- 
Ran 1028 tests in 2.302s 
 
FAILED (failures=2) 
<unittest.TextTestRunner object at 0x41977bcc> 
>>> 
 
I guess these failures are related to ATLAS or gcc, since 
I was able to run scipy.test() on another system without 
any failures. They differ in ATLAS and gcc. 
 
Any idea or hint ? 
 
Nils 
 
ATLAS version 3.4.2 built by root on Fre Sep 12 22:56:10 UTC 2003: 
   UNAME    : Linux linux 2.4.20-4GB-athlon #1 Mon Mar 17 17:56:47 
UTC 2003 i686 unknown unknown GNU/Linux 
   INSTFLG  : 
   MMDEF    : /home/nwagner/mysoftware/ATLAS/CONFIG/ARCHS/
ATHLONSSE1/gcc/gemm 
   ARCHDEF  : /home/nwagner/mysoftware/ATLAS/CONFIG/ARCHS/
ATHLONSSE1/gcc/misc 
   F2CDEFS  : -DAdd__ -DStringSunStyle 
   CACHEEDGE: 131072 
   F77      : /usr/bin/g77, version GNU Fortran (GCC) 3.3 20030226 
(prerelease) (SuSE Linux) 
   F77FLAGS : -O 
   CC       : /usr/bin/gcc, version gcc (GCC) 3.3 20030226 (prerelease) 
(SuSE Linux) 
   CC FLAGS : -fomit-frame-pointer -O3 -funroll-all-loops 
   MCC      : /usr/bin/gcc, version gcc (GCC) 3.3 20030226 (prerelease) 
(SuSE Linux) 
   MCCFLAGS : -fomit-frame-pointer -O 
nwagner at jane:~/cvs/scipy/Lib/linalg> 


From pearu at cens.ioc.ee  Thu Nov 20 04:29:44 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 20 Nov 2003 11:29:44 +0200 (EET)
Subject: [SciPy-dev] Problems with test_fitpack.py fitpack2.py
In-Reply-To: <3FBC91D2.FAD744D1@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0311201126530.1777-100000@cens.kybi>


On Thu, 20 Nov 2003, Nils Wagner wrote:

> Pearu Peterson schrieb:
> > 
> > On Thu, 20 Nov 2003, Nils Wagner wrote:
> > > What is the reason for the following errors ?
> > >
> > >
> > > =====================================================================
> > > ERROR: check_linear_constant
> > > (scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline)
> > > ----------------------------------------------------------------------
> > > Traceback (most recent call last):
> > >   File
> > > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py",
> > > line 52, in check_linear_constant
> > >     lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1)
> > >   File
> > > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py",
> > > line 399, in __init__
> > >     kx,ky,eps,lwrk2=1)
> > > error: (len(y)==m) failed for 3rd argument z
> > 
> > What is f2py version? You'll need f2py which supports usercode
> > statement, that is, f2py 2.35.229-1505 or (better) later.
> > 
> > Pearu
> > 
> 
> wagner at lisa:~> f2py -v
> 2.35.229-1505

I just checked, the same error occurs also with the latest f2py
but only with Python <=2.1. I'll see later if I can make a backport
to Python 2.1...

Pearu


From wagner.nils at vdi.de  Tue Nov 25 05:56:19 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Tue, 25 Nov 2003 11:56:19 +0100
Subject: [SciPy-dev] Problems with =?iso-8859-1?q?test=5Ffitpack.py?=
	fitpack2.py
In-Reply-To: <Pine.LNX.4.21.0311201126530.1777-100000@cens.kybi>
Message-ID: <20031125105621.1F9E53EB39@www.scipy.com>

------------------- 
 
On Thu, 20 Nov 2003, Nils Wagner wrote: 
 
> Pearu Peterson schrieb: 
> >  
> > On Thu, 20 Nov 2003, Nils Wagner wrote: 
> > > What is the reason for the following errors ? 
> > > 
> > > 
> > > 
===================================================================== 
> > > ERROR: check_linear_constant 
> > > (scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline) 
> > > ---------------------------------------------------------------------- 
> > > Traceback (most recent call last): 
> > >   File 
> > > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/
test_fitpack.py", 
> > > line 52, in check_linear_constant 
> > >     lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1) 
> > >   File 
> > > "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py", 
> > > line 399, in __init__ 
> > >     kx,ky,eps,lwrk2=1) 
> > > error: (len(y)==m) failed for 3rd argument z 
> >  
> > What is f2py version? You'll need f2py which supports usercode 
> > statement, that is, f2py 2.35.229-1505 or (better) later. 
> >  
> > Pearu 
> >  
>  
> wagner at lisa:~> f2py -v 
> 2.35.229-1505 
 
I just checked, the same error occurs also with the latest f2py 
but only with Python <=2.1. I'll see later if I can make a backport 
to Python 2.1... 
 
Pearu 
 
 
Actually, the problem is connected with  
___________________====================================================================== 
FAIL: check_random_complex (scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/test_decomp.py", 
line 276, in check_random_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_simple_complex (scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/test_decomp.py", 
line 250, in check_simple_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 592, in 
assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
Any idea ? 
 
                  Nils 
 
____________________________ 
 
Scipy-dev mailing list 
Scipy-dev at scipy.net 
http://www.scipy.net/mailman/listinfo/scipy-dev 
 


From pearu at scipy.org  Tue Nov 25 08:02:02 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 25 Nov 2003 07:02:02 -0600 (CST)
Subject: [SciPy-dev] Reason for failures inscipy.test() ?
In-Reply-To: <20031124145902.CEA353EB2D@www.scipy.com>
Message-ID: <Pine.LNX.4.44.0311250647520.27361-100000@scipy.org>



On Mon, 24 Nov 2003, Nils Wagner wrote:

> Dear experts, 
>  
> Can someone reproduce these failures with latest cvs ? 
>  
> ====================================================================== 
> FAIL: check_random_complex 
> (scipy.linalg.decomp.test_decomp.test_cholesky) 
> ---------------------------------------------------------------------- 
> ====================================================================== 
> FAIL: check_simple_complex 
> (scipy.linalg.decomp.test_decomp.test_cholesky) 
> ---------------------------------------------------------------------- 

No, I cannot reproduce these errors under Python 2.1.3, 2.2.3, 2.3.2
when using the recent cvs (only under 2.1 I get few 
fitpack,stats,special related errors that you have already reported).
I am currently using
  atlas2-sse2 3.2.1ln-11 from sid
  Numeric 23.1
  gcc 3.3.2

> I guess these failures are related to ATLAS or gcc, since 
> I was able to run scipy.test() on another system without 
> any failures. They differ in ATLAS and gcc. 

This could be the case. What gcc are you using?

> Any idea or hint ? 
>  
> Nils 
>  
> ATLAS version 3.4.2 built by root on Fre Sep 12 22:56:10 UTC 2003: 
>    UNAME    : Linux linux 2.4.20-4GB-athlon #1 Mon Mar 17 17:56:47 
> UTC 2003 i686 unknown unknown GNU/Linux 
>    INSTFLG  : 
>    MMDEF    : /home/nwagner/mysoftware/ATLAS/CONFIG/ARCHS/
> ATHLONSSE1/gcc/gemm 
>    ARCHDEF  : /home/nwagner/mysoftware/ATLAS/CONFIG/ARCHS/
> ATHLONSSE1/gcc/misc 

I am not sure but using sse1 might cause less accurate results.
Make sure that your are using the current CVS version of scipy_distutils
that disables sse1 flag when sse2 is available (do your machine have sse2
Run `python scipy_distutils/command/cpuinfo.py`).

I'll later try the other versions of atlas as well.

Pearu



From wagner.nils at vdi.de  Tue Nov 25 08:21:41 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Tue, 25 Nov 2003 14:21:41 +0100
Subject: [SciPy-dev] Reason for failures
	=?iso-8859-1?q?inscipy.test=28=29?= =?iso-8859-1?q?_=3F?=
In-Reply-To: <Pine.LNX.4.44.0311250647520.27361-100000@scipy.org>
Message-ID: <20031125132142.F28A43EB39@www.scipy.com>

------------------- 
 
 
On Mon, 24 Nov 2003, Nils Wagner wrote: 
 
> Dear experts,  
>   
> Can someone reproduce these failures with latest cvs ?  
>   
> 
======================================================================  
> FAIL: check_random_complex  
> (scipy.linalg.decomp.test_decomp.test_cholesky)  
> ----------------------------------------------------------------------  
> 
======================================================================  
> FAIL: check_simple_complex  
> (scipy.linalg.decomp.test_decomp.test_cholesky)  
> ----------------------------------------------------------------------  
 
No, I cannot reproduce these errors under Python 2.1.3, 2.2.3, 2.3.2 
when using the recent cvs (only under 2.1 I get few  
fitpack,stats,special related errors that you have already reported). 
I am currently using 
  atlas2-sse2 3.2.1ln-11 from sid 
  Numeric 23.1 
  gcc 3.3.2 
 
> I guess these failures are related to ATLAS or gcc, since  
> I was able to run scipy.test() on another system without  
> any failures. They differ in ATLAS and gcc.  
 
This could be the case. What gcc are you using? 
 
> Any idea or hint ?  
>   
> Nils  
>   
> ATLAS version 3.4.2 built by root on Fre Sep 12 22:56:10 UTC 2003:  
>    UNAME    : Linux linux 2.4.20-4GB-athlon #1 Mon Mar 17 17:56:47  
> UTC 2003 i686 unknown unknown GNU/Linux  
>    INSTFLG  :  
>    MMDEF    : /home/nwagner/mysoftware/ATLAS/CONFIG/ARCHS/ 
> ATHLONSSE1/gcc/gemm  
>    ARCHDEF  : /home/nwagner/mysoftware/ATLAS/CONFIG/ARCHS/ 
> ATHLONSSE1/gcc/misc  
 
I am not sure but using sse1 might cause less accurate results. 
Make sure that your are using the current CVS version of scipy_distutils 
that disables sse1 flag when sse2 is available (do your machine have sse2 
Run `python scipy_distutils/command/cpuinfo.py`). 
 
I'll later try the other versions of atlas as well. 
 
Pearu 
 
What is the meaning of sse2 ? 
 
nwagner at jane:~/cvs/scipy/scipy_core> python scipy_distutils/command/
cpuinfo.py 
 
CPU information: getNCPUs has_3dnow has_3dnowext has_mmx has_sse 
is_AMD is_singleCPU 
 
_________________wagner at jane:~/myoffice> gcc -v 
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.1/specs 
Konfiguriert mit: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man 
--libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking 
--enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux 
Thread model: posix 
gcc-Version 3.3.1 (SuSE Linux) 
nwagner at jane:~/myoffice> 
 
Nils 
 
______________________________ 
Scipy-dev mailing list 
Scipy-dev at scipy.net 
http://www.scipy.net/mailman/listinfo/scipy-dev 
 


From pearu at scipy.org  Tue Nov 25 08:29:11 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 25 Nov 2003 07:29:11 -0600 (CST)
Subject: [SciPy-dev] Reason for failures
	=?iso-8859-1?q?inscipy.test=28=29?= =?iso-8859-1?q?_=3F?=
In-Reply-To: <20031125132142.F28A43EB39@www.scipy.com>
Message-ID: <Pine.LNX.4.44.0311250727440.27361-100000@scipy.org>



On Tue, 25 Nov 2003, Nils Wagner wrote:

> What is the meaning of sse2 ? 

google: sse sse2

Eg read
  http://www.tommesani.com/SSE2Intro.html

Pearu


From nwagner at mecha.uni-stuttgart.de  Tue Nov 25 08:34:18 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 25 Nov 2003 14:34:18 +0100
Subject: [SciPy-dev] Reason for failuresinscipy.test()  ?
References: <Pine.LNX.4.44.0311250727440.27361-100000@scipy.org>
Message-ID: <3FC35A5A.8759D742@mecha.uni-stuttgart.de>

Pearu Peterson schrieb:
> 
> On Tue, 25 Nov 2003, Nils Wagner wrote:
> 
> > What is the meaning of sse2 ?
> 
> google: sse sse2
> 
> Eg read
>   http://www.tommesani.com/SSE2Intro.html
> 
> Pearu
> 
So, this feature belongs to Intel processors - I am using an AMD
processor.

Nils

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


From pearu at scipy.org  Tue Nov 25 09:11:51 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 25 Nov 2003 08:11:51 -0600 (CST)
Subject: [SciPy-dev] Reason for failuresinscipy.test()  ?
In-Reply-To: <3FC35A5A.8759D742@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.44.0311250809320.27361-100000@scipy.org>



On Tue, 25 Nov 2003, Nils Wagner wrote:

> Pearu Peterson schrieb:
> > 
> > On Tue, 25 Nov 2003, Nils Wagner wrote:
> > 
> > > What is the meaning of sse2 ?
> > 
> > google: sse sse2
> > 
> > Eg read
> >   http://www.tommesani.com/SSE2Intro.html
> > 
> So, this feature belongs to Intel processors - I am using an AMD
> processor.

That's not true. Also AMD cpus may have sse, etc.
Please, use google!

Pearu


From jeffrey.b.layton at lmco.com  Tue Nov 25 09:23:01 2003
From: jeffrey.b.layton at lmco.com (Jeff Layton)
Date: Tue, 25 Nov 2003 09:23:01 -0500
Subject: [SciPy-dev] Reason for failuresinscipy.test()  ?
In-Reply-To: <Pine.LNX.4.44.0311250809320.27361-100000@scipy.org>
References: <Pine.LNX.4.44.0311250809320.27361-100000@scipy.org>
Message-ID: <3FC365C5.9060808@lmco.com>

Pearu Peterson wrote:

>
>
> On Tue, 25 Nov 2003, Nils Wagner wrote:
>
> > Pearu Peterson schrieb:
> > >
> > > On Tue, 25 Nov 2003, Nils Wagner wrote:
> > >
> > > > What is the meaning of sse2 ?
> > >
> > > google: sse sse2
> > >
> > > Eg read
> > >   http://www.tommesani.com/SSE2Intro.html
> > >
> > So, this feature belongs to Intel processors - I am using an AMD
> > processor.
>
> That's not true. Also AMD cpus may have sse, etc.
> Please, use google!
>

Well, it's sort of true. Some Athlon CPUs have SSE,
not SSE2. I don't think the Opterons have SSE2,
only SSE (not sure on that, I'll check - oops! Opteron
does have SSE2! So does the Athlon 64 and 64 FX).
Here is an article that might help:

http://www.tomshardware.com/cpu/20030217/index.html

   Hope this helps.


Jeff


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


-- 
Dr. Jeff Layton
Aerodynamics and CFD
Lockheed-Martin Aeronautical Company - Marietta



From wagner.nils at vdi.de  Wed Nov 26 03:10:51 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Wed, 26 Nov 2003 09:10:51 +0100
Subject: [SciPy-dev] FAIL:check_simple_complexFAIL:check_random_complex
Message-ID: <20031126081053.DD6C73EB3A@www.scipy.com>

Pearu, 
 
I have used ATLAS3.5.12 as well. However, the failures didn't vanish. 
So, what is the reason for these strange failures ? 
 
gcc ??? 
Numeric ??? 
scipy ??? 
f2py ??? 
LAPACK ??? 
ATLAS ??? 
 
>>> scipy.__version__ 
'0.2.1_251.4457' 
>>> Numeric.__version__ 
'23.1' 
nwagner at jane:~> f2py -v 
2.37.233-1545 
nwagner at jane:~> gcc -v 
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.1/specs 
Konfiguriert mit: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/
share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada 
--disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g
++ --with-slibdir=/lib --with-system-zlib --enable-shared 
--enable-__cxa_atexit i586-suse-linux 
Thread model: posix 
gcc-Version 3.3.1 (SuSE Linux) 
 
Is it possible to neglect these failures ? 
 
====================================================================== 
FAIL: check_random_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 276, in check_random_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 
592, in assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
 
====================================================================== 
FAIL: check_simple_complex 
(scipy.linalg.decomp.test_decomp.test_cholesky) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/linalg/tests/
test_decomp.py", line 250, in check_simple_complex 
    assert_array_almost_equal(cholesky(a),c) 
  File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 
592, in assert_array_almost_equal 
    assert alltrue(ravel(reduced)),\ 
AssertionError: 
Arrays are not almost equal: 
 
Nils 
 


From pearu at scipy.org  Wed Nov 26 07:24:43 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 26 Nov 2003 06:24:43 -0600 (CST)
Subject: [SciPy-dev] FAIL:check_simple_complexFAIL:check_random_complex
In-Reply-To: <20031126081053.DD6C73EB3A@www.scipy.com>
Message-ID: <Pine.LNX.4.44.0311260615270.32134-100000@scipy.org>



On Wed, 26 Nov 2003, Nils Wagner wrote:

> I have used ATLAS3.5.12 as well. However, the failures didn't vanish. 
> So, what is the reason for these strange failures ? 
>  
> gcc ??? 
> Numeric ??? 
> scipy ??? 
> f2py ??? 
> LAPACK ??? 
> ATLAS ??? 

I tried also gcc-2.95, no failures. Then installed ATLAS3.5.12, and voila,
I get these failures too. So, the answer to your question is probably 
ATLAS as I didn't get the failures with sid atlas-3.2.1.

> Is it possible to neglect these failures ? 

That is a good question. I'll look now why they are failing..

Pearu



From wagner.nils at vdi.de  Wed Nov 26 11:34:43 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Wed, 26 Nov 2003 17:34:43 +0100
Subject: [SciPy-dev] ATLAS version and failures inscipy.test()
Message-ID: <20031126163445.6037D3EB3A@www.scipy.com>

Pearu, 
 
I switched back to ATLAS3.4.1  
http://www.cs.utk.edu/~rwhaley/ATLAS/errata3.4.1.html#rLLt 
Now, scipy.test() gives 
 
====================================================================== 
FAIL: check_normal 
(scipy.stats.morestats.test_morestats.test_anderson) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
  File "/usr/local/lib/python2.3/site-packages/scipy/stats/tests/
test_morestats.py", line 49, in check_normal 
    assert(scipy.all(A < crit[-2:])) 
AssertionError 
 
---------------------------------------------------------------------- 
Ran 1028 tests in 2.348s 
 
FAILED (failures=1) 
 
Nils 
 


From pearu at scipy.org  Wed Nov 26 15:53:14 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 26 Nov 2003 14:53:14 -0600 (CST)
Subject: [SciPy-dev] ATLAS version and failures inscipy.test()
In-Reply-To: <20031126163445.6037D3EB3A@www.scipy.com>
Message-ID: <Pine.LNX.4.44.0311261323140.32134-100000@scipy.org>



On Wed, 26 Nov 2003, Nils Wagner wrote:

> Pearu, 
>  
> I switched back to ATLAS3.4.1  
> http://www.cs.utk.edu/~rwhaley/ATLAS/errata3.4.1.html#rLLt 

Yes, I found that too. I'll fix it in scipy CVS soon.
Thanks.

> Now, scipy.test() gives 
>  
> ====================================================================== 
> FAIL: check_normal 
> (scipy.stats.morestats.test_morestats.test_anderson) 
> ---------------------------------------------------------------------- 
> Traceback (most recent call last): 
>   File "/usr/local/lib/python2.3/site-packages/scipy/stats/tests/
> test_morestats.py", line 49, in check_normal 
>     assert(scipy.all(A < crit[-2:])) 
> AssertionError 

When you run scipy.test multiple times, this test may succeed.
There is always a possibility that some stats tests fail occasionally.

Pearu


From joe at enthought.com  Wed Nov 26 17:36:14 2003
From: joe at enthought.com (Joe Cooper)
Date: Wed, 26 Nov 2003 16:36:14 -0600
Subject: [SciPy-dev] Testing SpamAssassin installation
Message-ID: <3FC52AF4.9090203@enthought.com>

Hi all,

I've just installed SpamAssassin, to work alongside SpamBayes on the
SciPy mailing lists.  Though very few spams are getting through these
days, because we don't permit posting by non-subscribers, it is still a
burden to sift through the moderated requests to let the 5% legitimate
messages through.

Anyway, feel free to ignore this message, as it it just a test to be
sure we're still delivering.

Thanks.



From nwagner at mecha.uni-stuttgart.de  Thu Nov 27 07:36:14 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 27 Nov 2003 13:36:14 +0100
Subject: [SciPy-dev] Machine precision
Message-ID: <3FC5EFBE.CEB4754A@mecha.uni-stuttgart.de>

Dear experts,

Is it possible to implement eps as a constant (similar to pi or e)
representing
the precision of the machine in scipy ?

Any suggestion ?

Nils


From pearu at scipy.org  Thu Nov 27 07:48:02 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 27 Nov 2003 06:48:02 -0600 (CST)
Subject: [SciPy-dev] Machine precision
In-Reply-To: <3FC5EFBE.CEB4754A@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.44.0311270640410.32134-100000@scipy.org>



On Thu, 27 Nov 2003, Nils Wagner wrote:

> Dear experts,
> 
> Is it possible to implement eps as a constant (similar to pi or e)
> representin the precision of the machine in scipy ?

No, because eps is not an universal constant (such as pi or e) but
depends on the machine architecture.

However, scipy provides (calculates) machine constants in 
scipy_base.machar module.
For example (in ipython),

In [1]: from scipy_base import machar_double

In [2]: machar_double.eps
Out[2]: 2.22044604925e-16

In [3]: machar_double.epsneg
Out[3]: 1.11022302463e-16

In [4]: from scipy_base import machar_single

In [5]: machar_single.eps
Out[5]: 1.19209289551e-07

In [6]: machar_single.epsneg
Out[6]: 5.96046447754e-08

For more information, see

  help(machar_double.__class__)

HTH,
Pearu


From pearu at scipy.org  Thu Nov 27 15:03:47 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 27 Nov 2003 14:03:47 -0600 (CST)
Subject: [SciPy-dev] ATLAS version and failures inscipy.test()
In-Reply-To: <Pine.LNX.4.44.0311261323140.32134-100000@scipy.org>
Message-ID: <Pine.LNX.4.44.0311271354530.32134-100000@scipy.org>



On Wed, 26 Nov 2003, Pearu Peterson wrote:

> > I switched back to ATLAS3.4.1  
> > http://www.cs.utk.edu/~rwhaley/ATLAS/errata3.4.1.html#rLLt 
> 
> Yes, I found that too. I'll fix it in scipy CVS soon.

It turns out that the failures in scipy tests that occur with Atlas
versions higher than 3.4.1 are related to Atlas bugs. I have contacted
Clint regarding this and he has opened the corresponding Atlas bug issue:

  https://sourceforge.net/tracker/index.php?func=detail&aid=850346&group_id=23725&atid=379482

Until potrf routines get gets fixed in Atlas, scipy.linalg uses Fortran 
version of zpotrf function (which actually should call Atlas routine 
clapack_zpotrf, so there should be no remarkable performance hit because 
of that). And it is OK to use any version of ATLAS with scipy again.

Regards,
Pearu


From oliphant at ee.byu.edu  Thu Nov 27 15:13:34 2003
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 27 Nov 2003 13:13:34 -0700
Subject: [SciPy-dev] Machine precision
In-Reply-To: <Pine.LNX.4.44.0311270640410.32134-100000@scipy.org>
References: <Pine.LNX.4.44.0311270640410.32134-100000@scipy.org>
Message-ID: <3FC65AEE.9080104@ee.byu.edu>



Pearu Peterson wrote:
> 
> On Thu, 27 Nov 2003, Nils Wagner wrote:
> 
> 
>>Dear experts,
>>
>>Is it possible to implement eps as a constant (similar to pi or e)
>>representin the precision of the machine in scipy ?
> 
> 
> No, because eps is not an universal constant (such as pi or e) but
> depends on the machine architecture.
> 
> However, scipy provides (calculates) machine constants in 
> scipy_base.machar module.

I think the limits module encapuslates the more basic machar module.

You should probably import limits; e.g.

from scipy_base import limits

limits.double_epsilon
limits.float_epsilon
limits.double_tiny
limits.float_tiny

etc.

-Travis O.


From oliphant at ee.byu.edu  Thu Nov 27 16:35:47 2003
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 27 Nov 2003 14:35:47 -0700
Subject: [SciPy-dev] Segfaults with weave
Message-ID: <3FC66E33.3030008@ee.byu.edu>


With Python 2.3.2 on Mandrake 9.2  I ran into trouble with segfaults and 
weave.

I traced the problem to bsddb module in Python 2.3.2.

Apparently it segfaults under my configuration when trying to open a file.


If you are running Python 2.3.2 could you try

import bsddb

bsddb.hashopen('anyfile','c')

and see if that works for you.

I fixed the problem by remmoving _bsddb.so  (so that anydbm doesn't use 
the bsddb module as a db).

Now, weave works fine.

Could somebody else veryify to see if bsddb is working on Python 2.3.2 
for you?

-Travis Oliphant



From pearu at scipy.org  Thu Nov 27 17:01:27 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 27 Nov 2003 16:01:27 -0600 (CST)
Subject: [SciPy-dev] Segfaults with weave
In-Reply-To: <3FC66E33.3030008@ee.byu.edu>
Message-ID: <Pine.LNX.4.44.0311271544190.32134-100000@scipy.org>



On Thu, 27 Nov 2003, Travis Oliphant wrote:

> With Python 2.3.2 on Mandrake 9.2  I ran into trouble with segfaults and 
> weave.
> 
> I traced the problem to bsddb module in Python 2.3.2.
> 
> Apparently it segfaults under my configuration when trying to open a file.
> 
> 
> If you are running Python 2.3.2 could you try
> 
> import bsddb
> bsddb.hashopen('anyfile','c')

I am running Python 2.3.2 (GCC 3.3.2) on Debian sid and the above
two lines work ok. However, weave.test(10,2) segfaults at running

  test_scxx_object.test_object_print

Hidding _bsddb.so does not prevent the segfault that I am getting above.

Pearu


From wagner.nils at vdi.de  Fri Nov 28 03:03:56 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Fri, 28 Nov 2003 09:03:56 +0100
Subject: [SciPy-dev] Re: [SciPy-user] MatrixMarket I/O Functions for scipy
In-Reply-To: <200311271532.26870.josegomez@gmx.net>
Message-ID: <20031128080358.A0BEE3EB25@www.scipy.com>

------------------- 
Hi Nils, 
 
On Thursday 27 Nov 2003 1:37 pm, Nils Wagner wrote: 
> Afaik, there exists only a Fortran routine for this purpose. 
>  http://math.nist.gov/~KRemington/mmio/mmiof77.html 
 
	Since the source code is available, it is (fairly) trivial to 
wrap the  
f77 code using f2py and g77. This will allow you to call said 
functions  
from within python (+scipy). 
 
	May I recommend you read the f2py tutorial? It is to be found 
on  
<http://www.ifi.uio.no/in228/scripting/doc/python/fc/f2py-tutorial/
tutorial.pdf> 
 
	Best luck 
Jos? 
 
Hi Jose, 
 
A google search on Python MatrixMarket yields 
http://people.web.psi.ch/geus/pyfemax/pysparse.html 
It should not be stand-alone solution for myself. 
I guess, many users will benefit from the feature 
(I/O of matrices in MatrixMarket or Harwell-Boeing format), if 
it becomes a part of scipy. 
 
Any suggestion ? 
 
BTW, the Harwell-Boeing seems to be supported by scipy 
http://scipy.net/cgi-bin/viewcvsx.cgi/scipy1/sparse/SuperLU/SRC/
zreadhb.c?rev=1.2 
 
How can I invoke this function in scipy ? 
A small example is appreciated. 
 
Nils 
 
 
 
 
 
--  
Jos? L G?mez Dans			PhD student 
Tel: +44 114 222 5582			Radar & Communications Group 
FAX; +44 870 132 2990			Department of Electronic 
Engineering 
					University of Sheffield UK