From juraj.krempasky at psi.ch  Tue Mar  4 04:27:00 2003
From: juraj.krempasky at psi.ch (Juraj Krempasky)
Date: Tue, 04 Mar 2003 10:27:00 +0100
Subject: [SciPy-user] scipy for Linux RH7.3 with python2.2
Message-ID: <3E647164.F5CFBEFE@psi.ch>

Hello,

installing tarball SciPy-0.2.0_alpha_105.3699.linux2_py2.2.tar.gz leads
to a Segmentation fault when importing scipy.  Is there a tarball or rpm
somewhere for python2.2?

thanks



From pearu at cens.ioc.ee  Tue Mar  4 04:40:46 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 4 Mar 2003 11:40:46 +0200 (EET)
Subject: [SciPy-user] scipy for Linux RH7.3 with python2.2
In-Reply-To: <3E647164.F5CFBEFE@psi.ch>
Message-ID: <Pine.LNX.4.21.0303041134440.1740-100000@cens.kybi>

On Tue, 4 Mar 2003, Juraj Krempasky wrote:

> installing tarball SciPy-0.2.0_alpha_105.3699.linux2_py2.2.tar.gz leads
> to a Segmentation fault when importing scipy.  Is there a tarball or rpm
> somewhere for python2.2?

  http://www.python.org/2.2.2/rpms.html

Note that segmentation faults may have very different origins.
E.g. study the output of

  python -v -c 'import scipy'

to determine which module causes the failure.

Pearu



From e.hartley at lancaster.ac.uk  Wed Mar  5 12:41:44 2003
From: e.hartley at lancaster.ac.uk (Hartley, Ed)
Date: Wed, 5 Mar 2003 17:41:44 -0000 
Subject: [SciPy-user] weave inline install problem
Message-ID: <7F332A8009EE5D4CB62C87717A3498A124B3AD@exchange-be1.lancs.ac.uk>

Hi
I'm new to SciPY but not to Python and my question relates speciaifcally to
weave.

I've installed SciPy from CVS under linux 
I've built it with gcc 2.96 using a local 2.95 for the special function
libraries.

The SciPY tests passed the weave compile tests failed but ran by defaulting to
using python.
I'm now working through the weave tutorials and I've hit a problem which I'm
assuming is installation related in some way. 

This works

	>>> import weave    
	>>> a  = 1
	>>> weave.inline('printf("%d\\n",a);',['a'])
	1

So I am assuming that the compiler call is OK however this fails

	>>> from weave import inline
	 >>> a = 'string'
	 >>> code = """
	 ...        int l = len(a);
	 ...        return_val = Py::new_reference_to(Py::Int(l));
	 ...        """
	 >>> inline(code,['a'])

In the transcript shown below there's an indication from the line containing
parse error before `::'
that the Py:: construct is not processed correctly so I'm assuming that the 
problem is installation related in some way 
any suggestions on how to resolve this would be  gratefully received.
Thanks
Ed Hartley


/home/widrith/.python22_compiled/sc_976f170a1f9617a7bab47e6e6aa92d200.cpp: In
function `PyObject 
*compiled_func (PyObject *, PyObject *)':
/home/widrith/.python22_compiled/sc_976f170a1f9617a7bab47e6e6aa92d200.cpp:649:
`len' undeclared (first 
use this function)
/home/widrith/.python22_compiled/sc_976f170a1f9617a7bab47e6e6aa92d200.cpp:649:
(Each undeclared 
identifier is reported only once for each function it appears in.)
/home/widrith/.python22_compiled/sc_976f170a1f9617a7bab47e6e6aa92d200.cpp:650:
`Py' undeclared (first 
use this function)
/home/widrith/.python22_compiled/sc_976f170a1f9617a7bab47e6e6aa92d200.cpp:650:
parse error before `::'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/weave/inline_tools.py", line 335,
in inline
    auto_downcast = auto_downcast,
  File "/usr/local/lib/python2.2/site-packages/weave/inline_tools.py", line 439,
in compile_function
    verbose=verbose, **kw)
  File "/usr/local/lib/python2.2/site-packages/weave/ext_tools.py", line 332, in
compile
    verbose = verbose, **kw)
  File "/usr/local/lib/python2.2/site-packages/weave/build_tools.py", line 237,
in build_extension
    setup(name = module_name, ext_modules = [ext],verbose=verb)
  File "/usr/local/lib/python2.2/distutils/core.py", line 157, in setup
    raise SystemExit, "error: " + str(msg)
weave.build_tools.CompileError: error: command 'gcc' failed with exit status 1






From eric at enthought.com  Wed Mar  5 18:31:13 2003
From: eric at enthought.com (eric jones)
Date: Wed, 5 Mar 2003 17:31:13 -0600
Subject: [SciPy-user] problem in converting scipy to exe
In-Reply-To: <008d01c2df39$8d8aa9c0$a13f72a0@szbk.uszeged.hu>
Message-ID: <003001c2e36f$52ad4f80$8901a8c0@ERICDESKTOP>

Hey Geza,

 

I think there is.  I can include the code in a python module instead of
leaving it as an external file, or perhaps a relative path to the
install directory will work.  How do other py2exe installations work
with data files?

 

Please submit this as a bug and assign it to me.  I am working on weave
when during spare evenings over the next several weeks.

 

Thanks,

eric

 

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701

-----Original Message-----
From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On
Behalf Of G?za Groma
Sent: Friday, February 28, 2003 5:54 AM
To: SciPy-user list
Subject: [SciPy-user] problem in converting scipy to exe

 

I tried to convert a program using scipy into an exe file on Windows NT
using both Gordon's Installer and py2exe. The problem is that weave is
hardcoded to be imported by scipy.__init__. Weave tries to open
swigptr.c using and absolute path. If the exe file built is exetuted on
an other computer it will not find it. Py2exe even gives an error
message during building the exe file.

 

To cure the problem I simply commented out importing weave in
scipy.__init__ as well as its name anddescription in _pkgs and _pkg_doc.
For the current case it eliminated the problem since I did not need
weave.

 

Any permanent solution? Can not be weave absolutely independent of
scipy?

 

Regards,

 

G?za Groma
Institute of Biophysics
Biological Research Center of Hungarian Academy of Sciences
6701 Szeged, Hungary

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

From eric at enthought.com  Thu Mar  6 18:58:29 2003
From: eric at enthought.com (eric jones)
Date: Thu, 6 Mar 2003 17:58:29 -0600
Subject: [SciPy-user] weave inline install problem
In-Reply-To: <7F332A8009EE5D4CB62C87717A3498A124B3AD@exchange-be1.lancs.ac.uk>
Message-ID: <006e01c2e43c$4c2a5a90$8901a8c0@ERICDESKTOP>

Hey Ed,

The CVS of weave is quite a bit different (improved) in its transparency
of working with Python objects.  The C++ classes have been changed to
handle most of the ref count and conversion between Python/C monkey
business under the covers.  However, the docs are not up to date.

Instead of:

	 >>> from weave import inline
	 >>> a = 'string'
	 >>> code = """
	 ...        int l = len(a);
	 ...        return_val = Py::new_reference_to(Py::Int(l));
	 ...        """
	 >>> inline(code,['a'])

The CVS version would be:

	 >>> from weave import inline
	 >>> a = 'string'
	 >>> code = """
	 ...        return_val = a.length();
	 ...        """
	 >>> inline(code,['a'])

The conversions using Py::Int and Py::new_reference_to are now handled
internally.  I am slowly working on docs, but they are not ready.

Sorry about that.  Until then, I think the 0.2.3 should work as
advertised in the docs.

Thanks,
eric

> I'm new to SciPY but not to Python and my question relates
speciaifcally
> to
> weave.
> 
> I've installed SciPy from CVS under linux
> I've built it with gcc 2.96 using a local 2.95 for the special
function
> libraries.
> 
> The SciPY tests passed the weave compile tests failed but ran by
> defaulting to
> using python.
> I'm now working through the weave tutorials and I've hit a problem
which
> I'm
> assuming is installation related in some way.
> 
> This works
> 
> 	>>> import weave
> 	>>> a  = 1
> 	>>> weave.inline('printf("%d\\n",a);',['a'])
> 	1
> 
> So I am assuming that the compiler call is OK however this fails
> 
> 	>>> from weave import inline
> 	 >>> a = 'string'
> 	 >>> code = """
> 	 ...        int l = len(a);
> 	 ...        return_val = Py::new_reference_to(Py::Int(l));
> 	 ...        """
> 	 >>> inline(code,['a'])
> 
> In the transcript shown below there's an indication from the line
> containing
> parse error before `::'
> that the Py:: construct is not processed correctly so I'm assuming
that
> the
> problem is installation related in some way
> any suggestions on how to resolve this would be  gratefully received.
> Thanks
> Ed Hartley
> 

Hey Ed




From groma at nucleus.szbk.u-szeged.hu  Fri Mar  7 04:58:18 2003
From: groma at nucleus.szbk.u-szeged.hu (=?iso-8859-1?Q?G=E9za_Groma?=)
Date: Fri, 7 Mar 2003 10:58:18 +0100
Subject: [SciPy-user] problem in converting scipy to exe
References: <003001c2e36f$52ad4f80$8901a8c0@ERICDESKTOP>
Message-ID: <011101c2e490$14a97a70$a13f72a0@szbk.uszeged.hu>

Hi Eric,

The bug report is submitted. To do that I registered myself as a new user in the tracker. How to remove my name? What is the password for anonymous login?

I highly recommend to include the required code in a python module instead of using relative path. py2exe requires a manual listing of data files in setup.py. On runtime sys.prefix returns the directory of the .exe file. This makes possible the use of relative path but it requires unnecessary complicated tree of subdirectories in the distribution directory just for a single file. In extreme case, if weave is not installed into the standard sys.prefix/Lib/site-packages/weave directory but into a different drive, you even can not construct a relative path.

Regards,
Geza
  ----- Original Message ----- 
  From: eric jones 
  To: scipy-user at scipy.net 
  Sent: Thursday, March 06, 2003 12:31 AM
  Subject: RE: [SciPy-user] problem in converting scipy to exe


  Hey Geza,



  I think there is.  I can include the code in a python module instead of leaving it as an external file, or perhaps a relative path to the install directory will work.  How do other py2exe installations work with data files?



  Please submit this as a bug and assign it to me.  I am working on weave when during spare evenings over the next several weeks.



  Thanks,

  eric



  ----------------------------------------------
  eric jones                    515 Congress Ave
  www.enthought.com             Suite 1614
  512 536-1057                  Austin, Tx 78701

  -----Original Message-----
  From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On Behalf Of G?za Groma
  Sent: Friday, February 28, 2003 5:54 AM
  To: SciPy-user list
  Subject: [SciPy-user] problem in converting scipy to exe



  I tried to convert a program using scipy into an exe file on Windows NT using both Gordon's Installer and py2exe. The problem is that weave is hardcoded to be imported by scipy.__init__. Weave tries to open swigptr.c using and absolute path. If the exe file built is exetuted on an other computer it will not find it. Py2exe even gives an error message during building the exe file.



  To cure the problem I simply commented out importing weave in scipy.__init__ as well as its name anddescription in _pkgs and _pkg_doc. For the current case it eliminated the problem since I did not need weave.



  Any permanent solution? Can not be weave absolutely independent of scipy?



  Regards,



  G?za Groma
  Institute of Biophysics
  Biological Research Center of Hungarian Academy of Sciences
  6701 Szeged, Hungary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20030307/f8be0742/attachment.html>

From e.hartley at lancaster.ac.uk  Fri Mar  7 10:00:13 2003
From: e.hartley at lancaster.ac.uk (Hartley, Ed)
Date: Fri, 7 Mar 2003 15:00:13 -0000 
Subject: [SciPy-user] Re:Re:weave inline install problem
Message-ID: <7F332A8009EE5D4CB62C87717A3498A124B3AE@exchange-be1.lancs.ac.uk>

Eric
thanks for your swift answer 
the CVS version works as per your reply 
you may know it returns 
6L 
to interactive session and 
6
to a variable under python 2.2.2 I'm assuming this is 'noise'

I had tried the non CVS 0.2.3  version after the CVS attempt, but it behaved
much the same and put it down to inadequate replacement of the CVS variant
since I had installed all of scipy and just replaced weave.

Regards
Ed Hartley


From pearu at cens.ioc.ee  Sat Mar  8 09:31:11 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 8 Mar 2003 16:31:11 +0200 (EET)
Subject: [SciPy-user] Major changes in SciPy CVS repository
Message-ID: <Pine.LNX.4.21.0303081606480.11909-100000@cens.kybi>

Hi,

There has been made some major restructuring of the SciPy CVS repository:
* scipy subpackages are moved to Lib directory
* scipy_{distutils,test,base} is moved to a separate CVS module named
  scipy_core
* etc.

Here follows instructions how to update your local scipy CVS tree:

1) Make a backup of your local scipy source tree. This is relevant only if
   you have uncommited files in your local scipy copy.

2) Checkout new scipy CVS tree using

     cvs -d :pserver:anonymous at scipy.org:/home/cvsroot checkout scipy

   or

     cvs -d :ext:loginname at scipy.org:/home/cvsroot checkout scipy

3) Modified files from the old scipy tree may now copied to a new tree.

4) To install scipy, use

   cd scipy
   python setup.py install


Note that the new scipy CVS tree does not contain all the contents from
the old tree, some Attic directories and obsolete files where not copied
to the new tree. However, the old copy of scipy CVS tree is available
through

  cvs -d ... checkout scipy1

These CVS changes may cause cvs update failures on your old local
scipy CVS tree. As fix, see points 1) and 2) above.

Sorry for the inconvinience but hopefully these changes make using
scipy CVS easier for many people, both for users and distributors.

Thanks,
	Pearu



From nwagner at mecha.uni-stuttgart.de  Mon Mar 10 06:43:12 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 10 Mar 2003 12:43:12 +0100
Subject: [SciPy-user] Problems with SciPy CVS
Message-ID: <3E6C7A50.299CE6CA@mecha.uni-stuttgart.de>

Hi all,

I tried to istall scipy via the modified SciPy CVS repository.
Unfortunately  without success.

/usr/local/bin/python setup.py install
atlas_info:
  FOUND:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/lib/atlas']

/usr/local/bin/python
/export/home/wagner/cvs/scipy/Lib/linalg/setup_atlas_version.py
build_ext --inplace --force
/usr/local/bin/python -c "import atlas_version"
ATLAS version 3.4.1
### Little Endian detected ####
fftw_info:
  NOT AVAILABLE

dfftw_info:
  FOUND:
    include_dirs = ['/usr/include']
    define_macros = [('SCIPY_DFFTW_H', None)]
    library_dirs = ['/usr/lib']
    libraries = ['drfftw', 'dfftw']

djbfft_info:
  NOT AVAILABLE


    DJBFFT (http://cr.yp.to/djbfft.html) libraries not found.
    Directories to search for the libraries can be specified in the
    scipy_distutils/site.cfg file (section [djbfft]) or by setting
    the DJBFFT environment variable.
Traceback (most recent call last):
  File "setup.py", line 107, in ?
    setup_package()
  File "setup.py", line 82, in setup_package
    config_list += map(get_package_config,scipy_packages)
  File "setup.py", line 63, in get_package_config
    mod = __import__('setup_'+os.path.basename(name))
  File "Lib/xplt/setup_xplt.py", line 27, in ?
    if 'NO_XLIB' in os.environ:
  File "/usr/local/lib/python2.1/UserDict.py", line 14, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 0

Any idea ?

Nils


From travis at enthought.com  Mon Mar 10 07:41:23 2003
From: travis at enthought.com (Travis N. Vaught)
Date: Mon, 10 Mar 2003 06:41:23 -0600
Subject: [SciPy-user] Problems with SciPy CVS
In-Reply-To: <3E6C7A50.299CE6CA@mecha.uni-stuttgart.de>
Message-ID: <000201c2e702$5f64d630$0300a8c0@tvlaptop>

Hey Nils,

It's not very scientific, but I had this same problem and, due to the
massive CVS changes, cleared my local checkout and did a new checkout of
the whole thing again (rather than an update).  This worked for the
Python 2.2 nightly build for win32.  I still need to look into the
Python 2.1 build.  There may be other problems as well, but thanks for
the additional data point.  What distro are you using?

Travis

> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Nils Wagner
> Sent: Monday, March 10, 2003 5:43 AM
> To: scipy-user at scipy.net
> Subject: [SciPy-user] Problems with SciPy CVS
> 
> Hi all,
> 
> I tried to istall scipy via the modified SciPy CVS repository.
> Unfortunately  without success.
> 
> /usr/local/bin/python setup.py install
> atlas_info:
>   FOUND:
>     libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
>     library_dirs = ['/usr/local/lib/atlas']
> 
> /usr/local/bin/python
> /export/home/wagner/cvs/scipy/Lib/linalg/setup_atlas_version.py
> build_ext --inplace --force
> /usr/local/bin/python -c "import atlas_version"
> ATLAS version 3.4.1
> ### Little Endian detected ####
> fftw_info:
>   NOT AVAILABLE
> 
> dfftw_info:
>   FOUND:
>     include_dirs = ['/usr/include']
>     define_macros = [('SCIPY_DFFTW_H', None)]
>     library_dirs = ['/usr/lib']
>     libraries = ['drfftw', 'dfftw']
> 
> djbfft_info:
>   NOT AVAILABLE
> 
> 
>     DJBFFT (http://cr.yp.to/djbfft.html) libraries not found.
>     Directories to search for the libraries can be specified in the
>     scipy_distutils/site.cfg file (section [djbfft]) or by setting
>     the DJBFFT environment variable.
> Traceback (most recent call last):
>   File "setup.py", line 107, in ?
>     setup_package()
>   File "setup.py", line 82, in setup_package
>     config_list += map(get_package_config,scipy_packages)
>   File "setup.py", line 63, in get_package_config
>     mod = __import__('setup_'+os.path.basename(name))
>   File "Lib/xplt/setup_xplt.py", line 27, in ?
>     if 'NO_XLIB' in os.environ:
>   File "/usr/local/lib/python2.1/UserDict.py", line 14, in __getitem__
>     def __getitem__(self, key): return self.data[key]
> KeyError: 0
> 
> Any idea ?
> 
> Nils
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From nwagner at mecha.uni-stuttgart.de  Mon Mar 10 07:49:05 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 10 Mar 2003 13:49:05 +0100
Subject: [SciPy-user] Problems with SciPy CVS
References: <000201c2e702$5f64d630$0300a8c0@tvlaptop>
Message-ID: <3E6C89C1.31FAF956@mecha.uni-stuttgart.de>

"Travis N. Vaught" schrieb:
> 
> Hey Nils,
> 
> It's not very scientific, but I had this same problem and, due to the
> massive CVS changes, cleared my local checkout and did a new checkout of
> the whole thing again (rather than an update).  This worked for the
> Python 2.2 nightly build for win32.  I still need to look into the
> Python 2.1 build.  There may be other problems as well, but thanks for
> the additional data point.  What distro are you using?
> 
> Travis

Hi Travis,

Thank you for your reply. I will try it. I am on SuSE8.0
(http://www.suse.com) and the current python version is
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.
>>>

Cheers,

          Nils

> 
> > -----Original Message-----
> > From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
> On
> > Behalf Of Nils Wagner
> > Sent: Monday, March 10, 2003 5:43 AM
> > To: scipy-user at scipy.net
> > Subject: [SciPy-user] Problems with SciPy CVS
> >
> > Hi all,
> >
> > I tried to istall scipy via the modified SciPy CVS repository.
> > Unfortunately  without success.
> >
> > /usr/local/bin/python setup.py install
> > atlas_info:
> >   FOUND:
> >     libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
> >     library_dirs = ['/usr/local/lib/atlas']
> >
> > /usr/local/bin/python
> > /export/home/wagner/cvs/scipy/Lib/linalg/setup_atlas_version.py
> > build_ext --inplace --force
> > /usr/local/bin/python -c "import atlas_version"
> > ATLAS version 3.4.1
> > ### Little Endian detected ####
> > fftw_info:
> >   NOT AVAILABLE
> >
> > dfftw_info:
> >   FOUND:
> >     include_dirs = ['/usr/include']
> >     define_macros = [('SCIPY_DFFTW_H', None)]
> >     library_dirs = ['/usr/lib']
> >     libraries = ['drfftw', 'dfftw']
> >
> > djbfft_info:
> >   NOT AVAILABLE
> >
> >
> >     DJBFFT (http://cr.yp.to/djbfft.html) libraries not found.
> >     Directories to search for the libraries can be specified in the
> >     scipy_distutils/site.cfg file (section [djbfft]) or by setting
> >     the DJBFFT environment variable.
> > Traceback (most recent call last):
> >   File "setup.py", line 107, in ?
> >     setup_package()
> >   File "setup.py", line 82, in setup_package
> >     config_list += map(get_package_config,scipy_packages)
> >   File "setup.py", line 63, in get_package_config
> >     mod = __import__('setup_'+os.path.basename(name))
> >   File "Lib/xplt/setup_xplt.py", line 27, in ?
> >     if 'NO_XLIB' in os.environ:
> >   File "/usr/local/lib/python2.1/UserDict.py", line 14, in __getitem__
> >     def __getitem__(self, key): return self.data[key]
> > KeyError: 0
> >
> > Any idea ?
> >
> > Nils
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user


From travis at enthought.com  Mon Mar 10 08:48:26 2003
From: travis at enthought.com (Travis N. Vaught)
Date: Mon, 10 Mar 2003 07:48:26 -0600
Subject: [SciPy-user] Problems with SciPy CVS
In-Reply-To: <3E6C89C1.31FAF956@mecha.uni-stuttgart.de>
Message-ID: <000201c2e70b$bd522910$0300a8c0@tvlaptop>

Nils,

Actually I'm getting the same thing on Python 2.1 that you are
getting...I'm looking into it now.

Travis

> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Nils Wagner
> Sent: Monday, March 10, 2003 6:49 AM
> To: scipy-user at scipy.net
> Subject: Re: [SciPy-user] Problems with SciPy CVS
> 
> "Travis N. Vaught" schrieb:
> >
> > Hey Nils,
> >
> > It's not very scientific, but I had this same problem and, due to
the
> > massive CVS changes, cleared my local checkout and did a new
checkout of
> > the whole thing again (rather than an update).  This worked for the
> > Python 2.2 nightly build for win32.  I still need to look into the
> > Python 2.1 build.  There may be other problems as well, but thanks
for
> > the additional data point.  What distro are you using?
> >
> > Travis
> 
> Hi Travis,
> 
> Thank you for your reply. I will try it. I am on SuSE8.0
> (http://www.suse.com) and the current python version is
> 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.
> >>>
> 
> Cheers,
> 
>           Nils
> 
> >
> > > -----Original Message-----
> > > From: scipy-user-admin at scipy.net
[mailto:scipy-user-admin at scipy.net]
> > On
> > > Behalf Of Nils Wagner
> > > Sent: Monday, March 10, 2003 5:43 AM
> > > To: scipy-user at scipy.net
> > > Subject: [SciPy-user] Problems with SciPy CVS
> > >
> > > Hi all,
> > >
> > > I tried to istall scipy via the modified SciPy CVS repository.
> > > Unfortunately  without success.
> > >
> > > /usr/local/bin/python setup.py install
> > > atlas_info:
> > >   FOUND:
> > >     libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
> > >     library_dirs = ['/usr/local/lib/atlas']
> > >
> > > /usr/local/bin/python
> > > /export/home/wagner/cvs/scipy/Lib/linalg/setup_atlas_version.py
> > > build_ext --inplace --force
> > > /usr/local/bin/python -c "import atlas_version"
> > > ATLAS version 3.4.1
> > > ### Little Endian detected ####
> > > fftw_info:
> > >   NOT AVAILABLE
> > >
> > > dfftw_info:
> > >   FOUND:
> > >     include_dirs = ['/usr/include']
> > >     define_macros = [('SCIPY_DFFTW_H', None)]
> > >     library_dirs = ['/usr/lib']
> > >     libraries = ['drfftw', 'dfftw']
> > >
> > > djbfft_info:
> > >   NOT AVAILABLE
> > >
> > >
> > >     DJBFFT (http://cr.yp.to/djbfft.html) libraries not found.
> > >     Directories to search for the libraries can be specified in
the
> > >     scipy_distutils/site.cfg file (section [djbfft]) or by setting
> > >     the DJBFFT environment variable.
> > > Traceback (most recent call last):
> > >   File "setup.py", line 107, in ?
> > >     setup_package()
> > >   File "setup.py", line 82, in setup_package
> > >     config_list += map(get_package_config,scipy_packages)
> > >   File "setup.py", line 63, in get_package_config
> > >     mod = __import__('setup_'+os.path.basename(name))
> > >   File "Lib/xplt/setup_xplt.py", line 27, in ?
> > >     if 'NO_XLIB' in os.environ:
> > >   File "/usr/local/lib/python2.1/UserDict.py", line 14, in
__getitem__
> > >     def __getitem__(self, key): return self.data[key]
> > > KeyError: 0
> > >
> > > Any idea ?
> > >
> > > Nils
> > > _______________________________________________
> > > SciPy-user mailing list
> > > SciPy-user at scipy.net
> > > http://www.scipy.net/mailman/listinfo/scipy-user
> >
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From nwagner at mecha.uni-stuttgart.de  Mon Mar 10 09:47:30 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 10 Mar 2003 15:47:30 +0100
Subject: [SciPy-user] Next problem in CVS
Message-ID: <3E6CA582.B219EAA2@mecha.uni-stuttgart.de>

Hi all,

there is another problem concerning the new CVS tree

/usr/i486-suse-linux/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

Any idea ?

locate libX11
/usr/X11R6/lib/libX11.a
/usr/X11R6/lib/libX11.so
/usr/X11R6/lib/libX11.so.6
/usr/X11R6/lib/libX11.so.6.2

Nils


From otttr440 at student.liu.se  Mon Mar 10 10:17:25 2003
From: otttr440 at student.liu.se (Otto Tronarp)
Date: 10 Mar 2003 16:17:25 +0100
Subject: [SciPy-user] Next problem in CVS
In-Reply-To: <3E6CA582.B219EAA2@mecha.uni-stuttgart.de>
References: <3E6CA582.B219EAA2@mecha.uni-stuttgart.de>
Message-ID: <1047309444.4277.6.camel@mathcore2>

Hi,

I also got hit by this one, it seems like you have to run 
$python setup_xplt.py config
before you do python setup.py build (in scipy dir). However I  was under
the impression that distutils should keep track of stuff like that so I
could do python setup.py install and it would automagically  configure,
build and install everything...


Otto

On Mon, 2003-03-10 at 15:47, Nils Wagner wrote:
> Hi all,
> 
> there is another problem concerning the new CVS tree
> 
> /usr/i486-suse-linux/bin/ld: cannot find -lX11
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> 
> Any idea ?
> 
> locate libX11
> /usr/X11R6/lib/libX11.a
> /usr/X11R6/lib/libX11.so
> /usr/X11R6/lib/libX11.so.6
> /usr/X11R6/lib/libX11.so.6.2
> 
> Nils
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user



From pearu at cens.ioc.ee  Mon Mar 10 11:52:42 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 10 Mar 2003 18:52:42 +0200 (EET)
Subject: [SciPy-user] Next problem in CVS
In-Reply-To: <3E6CA582.B219EAA2@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0303101847460.22412-100000@cens.kybi>

On Mon, 10 Mar 2003, Nils Wagner wrote:

> there is another problem concerning the new CVS tree
> 
> /usr/i486-suse-linux/bin/ld: cannot find -lX11
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1

This is now fixed in CVS.

Btw, not all problems now or in future are related to
the new CVS tree ;)

Pearu



From Kasper.Souren at ircam.fr  Mon Mar 10 13:00:33 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 10 Mar 2003 18:00:33 +0000
Subject: [SciPy-user] compilation problem: specfun.f
Message-ID: <200303101800.33574.Kasper.Souren@ircam.fr>

Hi,

I recently (well.. yesterday..) moved from Debian to Gentoo, which is really 
much faster on my new P4 laptop :)
But now that I try to install SciPy I'm getting some troubles. This is where 
it starts:

g77  -Wall -fno-second-underscore  -fPIC -O3 -funroll-loops  -mmmx  -msse  	
-msse2  -malign-double -fomit-frame-pointer -c 
/home/guaka/cvs/scipy/Lib/special/specfun/specfun.f -o 
build/temp.linux-i686-2.2/specfun.o

After this I get a lot of warnings like this:

/home/guaka/cvs/scipy/Lib/special/specfun/specfun.f:184: warning: `qf0' might 
be used uninitialized in this function 
/home/guaka/cvs/scipy/Lib/special/specfun/specfun.f: In subroutine `cbk': 

And it ends in:

/tmp/ccJANaJb.s: Assembler messages: 
/tmp/ccJANaJb.s:100564: Error: suffix or operands invalid for `movd' 
error: failure during compile (exit status = 256) 

And this is what "g77 -v" gives me: 

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs
Configured with: /var/tmp/portage/gcc-3.2.2/work/gcc-3.2.2/configure 
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.2 
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include 
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2 
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man 
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info --enable-shared 
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib 
--enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix 
--enable-long-long --disable-checking --enable-cstdio=stdio 
--enable-clocale=generic --enable-__cxa_atexit 
--enable-version-specific-runtime-libs 
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/g++-v3 
--with-local-prefix=/usr/local --enable-shared --enable-nls 
--without-included-gettext
Thread model: posix
gcc version 3.2.2

Because of the new CVS setup, I already did an "mv scipy OLDscipy" and a fresh 
checkout.

What could I try to fix this?

bye,
Kasper
-- 
Hi! I'm a .signature virus! copy me into your .signature file to help me 
spread!


From pearu at cens.ioc.ee  Mon Mar 10 12:24:12 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 10 Mar 2003 19:24:12 +0200 (EET)
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <200303101800.33574.Kasper.Souren@ircam.fr>
Message-ID: <Pine.LNX.4.21.0303101920050.22412-100000@cens.kybi>

On Mon, 10 Mar 2003, Kasper Souren wrote:

> Hi,
> 
> I recently (well.. yesterday..) moved from Debian to Gentoo, which is really 
> much faster on my new P4 laptop :)
> But now that I try to install SciPy I'm getting some troubles. This is where 
> it starts:
> 
> g77  -Wall -fno-second-underscore  -fPIC -O3 -funroll-loops  -mmmx  -msse  	
> -msse2  -malign-double -fomit-frame-pointer -c 
> /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f -o 
> build/temp.linux-i686-2.2/specfun.o
> 
> After this I get a lot of warnings like this:
> 
> /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f:184: warning: `qf0' might 
> be used uninitialized in this function 
> /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f: In subroutine `cbk': 
> 
> And it ends in:
> 
> /tmp/ccJANaJb.s: Assembler messages: 
> /tmp/ccJANaJb.s:100564: Error: suffix or operands invalid for `movd' 
> error: failure during compile (exit status = 256) 

Could this be related to -msse, -msse2 compiler flags? Can they be used
at the same time?
Try compiling specfun.f without these flags:

  g77  -Wall -fno-second-underscore  -fPIC -O3 -funroll-loops \
   -malign-double -fomit-frame-pointer -c \
   /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f -o \
   build/temp.linux-i686-2.2/specfun.o

Is compiling succesful?

Pearu



From Kasper.Souren at ircam.fr  Mon Mar 10 13:22:05 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 10 Mar 2003 18:22:05 +0000
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <Pine.LNX.4.21.0303101920050.22412-100000@cens.kybi>
References: <Pine.LNX.4.21.0303101920050.22412-100000@cens.kybi>
Message-ID: <200303101822.05860.Kasper.Souren@ircam.fr>

> Could this be related to -msse, -msse2 compiler flags? Can they be used
> at the same time?
> Try compiling specfun.f without these flags:
>
>   g77  -Wall -fno-second-underscore  -fPIC -O3 -funroll-loops \
>    -malign-double -fomit-frame-pointer -c \
>    /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f -o \
>    build/temp.linux-i686-2.2/specfun.o
>
> Is compiling succesful?

Yep. Without the sse2 flags it's okay. I guess this is a g77/sse2 problem 
then.

bye,
Kasper


From pearu at cens.ioc.ee  Mon Mar 10 12:45:05 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 10 Mar 2003 19:45:05 +0200 (EET)
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <200303101822.05860.Kasper.Souren@ircam.fr>
Message-ID: <Pine.LNX.4.21.0303101941210.22412-100000@cens.kybi>

On Mon, 10 Mar 2003, Kasper Souren wrote:

> > Could this be related to -msse, -msse2 compiler flags? Can they be used
> > at the same time?
> > Try compiling specfun.f without these flags:
> >
> >   g77  -Wall -fno-second-underscore  -fPIC -O3 -funroll-loops \
> >    -malign-double -fomit-frame-pointer -c \
> >    /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f -o \
> >    build/temp.linux-i686-2.2/specfun.o
> >
> > Is compiling succesful?
> 
> Yep. Without the sse2 flags it's okay. I guess this is a g77/sse2 problem 
> then.

So, it does not compile with '-msse -msse2'.
To figure out a proper solution, few questions more:
Does it compile only with -msse?
Does it compile only with -msse2?

Pearu



From Kasper.Souren at ircam.fr  Mon Mar 10 13:37:38 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 10 Mar 2003 18:37:38 +0000
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <200303101822.05860.Kasper.Souren@ircam.fr>
References: <Pine.LNX.4.21.0303101920050.22412-100000@cens.kybi> <200303101822.05860.Kasper.Souren@ircam.fr>
Message-ID: <200303101837.38881.Kasper.Souren@ircam.fr>

On Monday 10 March 2003 18:22, Kasper Souren wrote:
> > Could this be related to -msse, -msse2 compiler flags? Can they be used
> > at the same time?
> > Try compiling specfun.f without these flags:
> >
> >   g77  -Wall -fno-second-underscore  -fPIC -O3 -funroll-loops \
> >    -malign-double -fomit-frame-pointer -c \
> >    /home/guaka/cvs/scipy/Lib/special/specfun/specfun.f -o \
> >    build/temp.linux-i686-2.2/specfun.o
> >
> > Is compiling succesful?
>
> Yep. Without the sse2 flags it's okay. I guess this is a g77/sse2 problem
> then.

(schizo reply)

It seems that the errors don't occur very often, and they're always like this:

	/tmp/ccn0CQzt.s: Assembler messages:
	/tmp/ccn0CQzt.s:1927: Error: suffix or operands invalid for `movd'

(That is, only the filenames and line numbers are different.)

Where could I disable the -msse2 flag for g77 compilations?

bye,
Kasper



From Kasper.Souren at ircam.fr  Mon Mar 10 13:41:30 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 10 Mar 2003 18:41:30 +0000
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <Pine.LNX.4.21.0303101941210.22412-100000@cens.kybi>
References: <Pine.LNX.4.21.0303101941210.22412-100000@cens.kybi>
Message-ID: <200303101841.30656.Kasper.Souren@ircam.fr>

> So, it does not compile with '-msse -msse2'.
> To figure out a proper solution, few questions more:
> Does it compile only with -msse?
> Does it compile only with -msse2?

Ah, sorry, I wasn't clear enough.

-msse is okay, -msse2 sometimes causes troubles...

btw, I googled for "g77 movd sse2" and found nothing...

bye,
Kasper



From pearu at cens.ioc.ee  Mon Mar 10 12:59:55 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 10 Mar 2003 19:59:55 +0200 (EET)
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <200303101837.38881.Kasper.Souren@ircam.fr>
Message-ID: <Pine.LNX.4.21.0303101956470.22412-100000@cens.kybi>

On Mon, 10 Mar 2003, Kasper Souren wrote:

> (schizo reply)
> 
> It seems that the errors don't occur very often, and they're always like this:
> 
> 	/tmp/ccn0CQzt.s: Assembler messages:
> 	/tmp/ccn0CQzt.s:1927: Error: suffix or operands invalid for `movd'
> 
> (That is, only the filenames and line numbers are different.)
> 
> Where could I disable the -msse2 flag for g77 compilations?

Either in 
  scipy_core/scipy_distutils/command/build_flib.py
(look for cpu.has_sse2() line in gnu_fortran_compiler class)
or in
  scipy_core/scipy_distutils/command/cpuinfo.py
in the case if the detection of SSE2 is wrong.

Pearu




From Kasper.Souren at ircam.fr  Mon Mar 10 13:52:33 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 10 Mar 2003 18:52:33 +0000
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <Pine.LNX.4.21.0303101956470.22412-100000@cens.kybi>
References: <Pine.LNX.4.21.0303101956470.22412-100000@cens.kybi>
Message-ID: <200303101852.33115.Kasper.Souren@ircam.fr>

> Either in
>   scipy_core/scipy_distutils/command/build_flib.py
> (look for cpu.has_sse2() line in gnu_fortran_compiler class)
> or in
>   scipy_core/scipy_distutils/command/cpuinfo.py
> in the case if the detection of SSE2 is wrong.

Thanks. I commented out the line -msse2 is added to opt.

The best solution were of course if the bug was fixed in g77.
But in order to still have some sse2 speed in SciPy it might be possible to 
first try the opt with -msse2 and if that gives "Error: suffix or operands 
invalid for `movd'" it could be tried again without the -msse2...

bye,
Kasper



From oliphant.travis at ieee.org  Mon Mar 10 13:10:25 2003
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Mon, 10 Mar 2003 11:10:25 -0700
Subject: [SciPy-user] Next problem in CVS
References: <3E6CA582.B219EAA2@mecha.uni-stuttgart.de> <1047309444.4277.6.camel@mathcore2>
Message-ID: <3E6CD511.7010601@ieee.org>


Otto Tronarp wrote:

>Hi,
>
>I also got hit by this one, it seems like you have to run 
>$python setup_xplt.py config
>before you do python setup.py build (in scipy dir). However I  was under
>the impression that distutils should keep track of stuff like that so I
>could do python setup.py install and it would automagically  configure,
>build and install everything...
>

I'm sorry about this, I had made changes to setup.py to automatically do 
this (to avoid this hassle you speak about), but  apparently these 
changes did not make it into the tree (perhaps i forgot to do a commit 
-- or committed to the wrong tree during the major weekend 
restructuring).  I will fix this tonight.  Thanks for the feedback.





From pearu at cens.ioc.ee  Mon Mar 10 13:24:42 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 10 Mar 2003 20:24:42 +0200 (EET)
Subject: [SciPy-user] Next problem in CVS
In-Reply-To: <3E6CD511.7010601@ieee.org>
Message-ID: <Pine.LNX.4.21.0303102021080.22412-100000@cens.kybi>

On Mon, 10 Mar 2003, Travis E. Oliphant wrote:

> Otto Tronarp wrote:
> >
> >I also got hit by this one, it seems like you have to run 
> >$python setup_xplt.py config
> >before you do python setup.py build (in scipy dir). However I  was under
> >the impression that distutils should keep track of stuff like that so I
> >could do python setup.py install and it would automagically  configure,
> >build and install everything...
> >
> 
> I'm sorry about this, I had made changes to setup.py to automatically do 
> this (to avoid this hassle you speak about), but  apparently these 
> changes did not make it into the tree (perhaps i forgot to do a commit 
> -- or committed to the wrong tree during the major weekend 
> restructuring).  I will fix this tonight.  Thanks for the feedback.

Hmm, I did not have to execute `setup_xplt.py config`.
The current CVS xplt builds and works fine here (Debian, Python 2.2.1).

Pearu




From groma at nucleus.szbk.u-szeged.hu  Tue Mar 11 04:59:29 2003
From: groma at nucleus.szbk.u-szeged.hu (=?iso-8859-1?Q?G=E9za_Groma?=)
Date: Tue, 11 Mar 2003 10:59:29 +0100
Subject: [SciPy-user] another problem with building xplt from CVS
Message-ID: <004101c2e7b4$e8ec3940$a13f72a0@szbk.uszeged.hu>

Trying to build scipy from CVS on Windows NT with Python 2.2.1 I got the following error. See the illegal value of -DGISTPATH.

d:\devel\gcc-2.95.2\bin\gcc.exe -mno-cygwin -mdll -O -Wall -ID:\devel\scipy\Lib\
xplt\src/gist -ID:\devel\scipy\Lib\xplt\src/play -ID:\devel\scipy\Lib\xplt\src/p
lay/unix -Id:\Python22\include -c D:\devel\scipy\Lib\xplt\src/gist/gread.c -o bu
ild\temp.win32-2.2\Release\gread.o -DGISTPATH="\"d:\\\\Python22\\\\Lib\\\\site-p
ackages\\\\scipy\\\\xplt\\\\gistdata\"" -DWINDOWS -mwindows -DNO_EXP10
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: `d' undeclared here (not in a funct
ion)
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: parse error before `:'
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
D:\devel\scipy\Lib\xplt\src/gist/gread.c:22: stray '\' in program
error: command 'gcc' failed with exit status 1


G?za Groma
Institute of Biophysics
Biological Research Center of Hungarian Academy of Sciences
6701 Szeged, Hungary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20030311/4925e022/attachment.html>

From groma at nucleus.szbk.u-szeged.hu  Tue Mar 11 05:06:53 2003
From: groma at nucleus.szbk.u-szeged.hu (=?iso-8859-1?Q?G=E9za_Groma?=)
Date: Tue, 11 Mar 2003 11:06:53 +0100
Subject: [SciPy-user] missing cluster modul in the latest Windows binary
Message-ID: <005301c2e7b5$f119c550$a13f72a0@szbk.uszeged.hu>

SciPy-0.2.0_alpha_180.4018.win32-py2.2.exe does not install the cluster module while scipy.__init__ requires it.

G?za Groma
Institute of Biophysics
Biological Research Center of Hungarian Academy of Sciences
6701 Szeged, Hungary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20030311/19647516/attachment.html>

From Kasper.Souren at ircam.fr  Tue Mar 11 06:31:47 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Tue, 11 Mar 2003 11:31:47 +0000
Subject: [SciPy-user] scipy.cluster -> cluster
Message-ID: <200303111131.47520.Kasper.Souren@ircam.fr>

Hi,

I was having some troubles with the cluster module. I am using the cvs 
version. To install it I needed to run the setup.py in Lib/cluster.
And then my from scipy.cluster import vq obviously doesn't work anymore.

Now it's running fine again here, but I guess other people might face this 
problem as well...

bye,
Kasper!


From nwagner at mecha.uni-stuttgart.de  Tue Mar 11 07:08:59 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 11 Mar 2003 13:08:59 +0100
Subject: [SciPy-user] Further problems in scipy
Message-ID: <3E6DD1DB.9B93E709@mecha.uni-stuttgart.de>

Hi all,

I have used the latest cvs to build scipy on SuSE8.0
using Python 2.1.2 (#1, Feb 25 2002, 18:04:21)
[GCC 2.95.3 20010315 (SuSE)] on linux2

This is the output of

/usr/local/bin/python setup.py build
%%%%%%%%%%%%%%%%%%%%%%%
1
%%%%%%%%%%%%%%%%%%%%%%%
***********************************************
/export/home/wagner/cvs/scipy/Lib/xplt
***********************************************
x11_info:
  FOUND:
    include_dirs = ['/usr/X11R6/include']
    library_dirs = ['/usr/X11R6/lib']
    libraries = ['X11']

running config
  ============= begin top level configuration =============
Traceback (most recent call last):
  File "setup.py", line 44, in ?
  File "setup_xplt.py", line 865, in ?
    setup(**configuration())
  File "scipy_core/scipy_distutils/core.py", line 42, in setup
  File "/usr/local/lib/python2.1/distutils/core.py", line 138, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.1/distutils/dist.py", line 899, in
run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.1/distutils/dist.py", line 919, in
run_command
    cmd_obj.run()
  File "setup_xplt.py", line 69, in run
    self.config_toplevel()
  File "setup_xplt.py", line 79, in config_toplevel
    if not 'MATHLIB' in os.environ:
  File "/usr/local/lib/python2.1/UserDict.py", line 14, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 0

Any idea ?

           Nils


From andrew.straw at adelaide.edu.au  Wed Mar 12 07:46:18 2003
From: andrew.straw at adelaide.edu.au (Andrew Straw)
Date: Wed, 12 Mar 2003 23:16:18 +1030
Subject: [SciPy-user] build problem from CVS
Message-ID: <9E9F8AC0-5488-11D7-A178-00039311EA24@adelaide.edu.au>

I recently (this morning) checkout out the scipy CVS from a clean tree. 
  To my joy, a "python setup.py install" worked right out of the box.  
However, I then got this:

Python 2.2.1 (#2, Mar  9 2003, 18:11:19)
[GCC 2.95.4  (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import scipy
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 
49, in ?
     import special, io, linalg, stats, fftpack
   File 
"/usr/local/lib/python2.2/site-packages/scipy/special/__init__.py", 
line 330, in ?
     from basic import *
   File "/usr/local/lib/python2.2/site-packages/scipy/special/basic.py", 
line 11, in ?
     import specfun
ImportError: 
/usr/local/lib/python2.2/site-packages/scipy/special/specfun.so: 
undefined symbol: PyArray_API

What am I doing wrong?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 949 bytes
Desc: not available
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20030312/56bcfef5/attachment.bin>

From pearu at cens.ioc.ee  Wed Mar 12 08:07:50 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 12 Mar 2003 15:07:50 +0200 (EET)
Subject: [SciPy-user] build problem from CVS
In-Reply-To: <9E9F8AC0-5488-11D7-A178-00039311EA24@adelaide.edu.au>
Message-ID: <Pine.LNX.4.21.0303121456580.1096-100000@cens.kybi>

On Wed, 12 Mar 2003, Andrew Straw wrote:

> I recently (this morning) checkout out the scipy CVS from a clean tree. 
>   To my joy, a "python setup.py install" worked right out of the box.  
> However, I then got this:
> 
> Python 2.2.1 (#2, Mar  9 2003, 18:11:19)
> [GCC 2.95.4  (Debian prerelease)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import scipy
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 
> 49, in ?
>      import special, io, linalg, stats, fftpack
>    File 
> "/usr/local/lib/python2.2/site-packages/scipy/special/__init__.py", 
> line 330, in ?
>      from basic import *
>    File "/usr/local/lib/python2.2/site-packages/scipy/special/basic.py", 
> line 11, in ?
>      import specfun
> ImportError: 
> /usr/local/lib/python2.2/site-packages/scipy/special/specfun.so: 
> undefined symbol: PyArray_API
> 
> What am I doing wrong?

What Numeric version are you using? f2py version?
Do you have other versions of Numeric in your system?
How did you configure Python, did you use any special flags?

Btw, the smallest Numeric version number that still works with
the current scipy, is 21.0. Earlier it was 20.3 but now some
scipy packages import rank(..) function from Numeric and that 
is available starting at 21.0.

Pearu



From andrew.straw at adelaide.edu.au  Wed Mar 12 09:36:33 2003
From: andrew.straw at adelaide.edu.au (Andrew Straw)
Date: Thu, 13 Mar 2003 01:06:33 +1030
Subject: [SciPy-user] build problem from CVS
In-Reply-To: <Pine.LNX.4.21.0303121456580.1096-100000@cens.kybi>
Message-ID: <0598108C-5498-11D7-BF27-00039311EA24@adelaide.edu.au>

Great, building from Numeric 22.0 fixed my problem.  (I was using 20.0.)

Cheers!
Andrew

On Wednesday, March 12, 2003, at 11:37  PM, Pearu Peterson wrote:

>
> On Wed, 12 Mar 2003, Andrew Straw wrote:
>
>> I recently (this morning) checkout out the scipy CVS from a clean 
>> tree.
>>   To my joy, a "python setup.py install" worked right out of the box.
>> However, I then got this:
>>
>> Python 2.2.1 (#2, Mar  9 2003, 18:11:19)
>> [GCC 2.95.4  (Debian prerelease)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import scipy
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in ?
>>    File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", 
>> line
>> 49, in ?
>>      import special, io, linalg, stats, fftpack
>>    File
>> "/usr/local/lib/python2.2/site-packages/scipy/special/__init__.py",
>> line 330, in ?
>>      from basic import *
>>    File 
>> "/usr/local/lib/python2.2/site-packages/scipy/special/basic.py",
>> line 11, in ?
>>      import specfun
>> ImportError:
>> /usr/local/lib/python2.2/site-packages/scipy/special/specfun.so:
>> undefined symbol: PyArray_API
>>
>> What am I doing wrong?
>
> What Numeric version are you using? f2py version?
> Do you have other versions of Numeric in your system?
> How did you configure Python, did you use any special flags?
>
> Btw, the smallest Numeric version number that still works with
> the current scipy, is 21.0. Earlier it was 20.3 but now some
> scipy packages import rank(..) function from Numeric and that
> is available starting at 21.0.
>
> Pearu
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>



From nwagner at mecha.uni-stuttgart.de  Wed Mar 12 09:45:05 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 12 Mar 2003 15:45:05 +0100
Subject: [SciPy-user] Numeric23 and scipy
Message-ID: <3E6F47F1.2E0C57EA@mecha.uni-stuttgart.de>

Hi all,

I wonder, if someone has used Numeric23.0 to install scipy.

Nils


From oliphant.travis at ieee.org  Wed Mar 12 14:25:00 2003
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Wed, 12 Mar 2003 12:25:00 -0700
Subject: [SciPy-user] Numeric23 and scipy
References: <3E6F47F1.2E0C57EA@mecha.uni-stuttgart.de>
Message-ID: <3E6F898C.9010308@ieee.org>


Nils Wagner wrote:

>Hi all,
>
>I wonder, if someone has used Numeric23.0 to install scipy.
>
>Nils
>

Yes, I'm using Numeric 23.0 -- the CVS version of Numeric actually.

-Travis O.


>_______________________________________________
>SciPy-user mailing list
>SciPy-user at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-user
>  
>




From oliphant.travis at ieee.org  Wed Mar 12 14:56:58 2003
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Wed, 12 Mar 2003 12:56:58 -0700
Subject: [SciPy-user] Re: [SciPy-dev] xplt, drawing-time...
References: <3E6F2A90.1070403@gmx.de>
Message-ID: <3E6F910A.7000004@ieee.org>


Johannes Broedel wrote:

> Hi, I just tried xplt, it works fine on both, teh Linux and the 
> Windows-Machine.
> I want to show dynamic processes, e.g. computing 1000 data points to 
> be shown not all at the same time - they should appear one after the 
> other. At the moment xplt seems to collect the points and to draw them 
> finally. Does anyone know a solution for that? 


Perhaps what you want is simply the xplt.hold('on') function that will 
hold the previous plot.  Then you can plot data points one at a time in 
a loop.  You may have to issue calls to xplt.pause(<milliseconds>)  to 
delay the next plot.

I just checked in to CVS a fix for the current problem that xplt.plot 
cannot handle plotting a single data point.   (a quick fix is to get rid 
of the squeeze function everywhere it shows up in xplt/Mplot.py).  

Also, check out xplt.animate() if you think the result is blinking too 
much.

I just tried the following code and it gave me a nice animation:

xplt.figure()
x = r_[0:10:1000j]
xplt.hold('on')
for xval in x:
      yval = sin(xval / 4)
      xplt.plot(xval, yval, 'x')
      xplt.pause(100)

If you don't like the changing limits on the plot as it runs, then just 
issue
xplt.limits(xlow,xhigh,ylow,yhigh) before the for loop.

-Travis O.




>
> Thanks in advance, Johannes Broedel
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev





From johannesbroedel at gmx.de  Thu Mar 13 13:26:25 2003
From: johannesbroedel at gmx.de (Johannes Broedel)
Date: Thu, 13 Mar 2003 19:26:25 +0100
Subject: [SciPy-user] drawing time
Message-ID: <3E70CD51.7060201@gmx.de>

Hallo,

thanks for the short progrma, trying ade my computer producing the 
following message (IPython):

In [7]: run sciptest.py
---------------------------------------------------------------------------
MemoryError                               Traceback (most recent call last)

/home/jbroedel/python/graphtest/sciptest.py
      5 xplt.hold('on')
      6 for xval in x:
      7       yval = sin(xval / 4)
----> 8       xplt.plot(xval, yval, 'x')
      9       xplt.pause(100)

/home/python/PYTHON/lib/python2.2/site-packages/scipy/xplt/Mplot.py in 
plot(x, *args, **keywds)
    480             y = scipy.real(y)
    481         y = where(scipy.isfinite(y),y,0)
--> 482         
gist.plg(y,x,type=thetype,color=thecolor,marker=themarker,marks=tomark,width=linewidth)
    483
    484         nowplotting = nowplotting + 1

MemoryError:
WARNING: Failure executing file: <sciptest.py>

The real problem I had was with the following program:


#!/usr/bin/env python

from Numeric import *
from scipy.xplt import *


def standard_map(x_cor,y_cor,kappa):
    """provide one interate of the inital conditions x_cor,y_cor
       for the standard map with parameter kappa.
    """
    y_cor_new=(y_cor-kappa*sin(2.0*pi*x_cor) )% 1
    x_cor_new=(x_cor+y_cor_new )   % 1
 
    return(x_cor_new,y_cor_new)



if __name__ == '__main__':
    window()             # initialize plotting
    limits(0.0,1.0,0.0,1.0)
    x,y=0.5,0.1          # initial (x,y)
    k=1.1/(2.0*pi)       # parameter
    animate(0)
    iterations=1000
    while 1:             # iterate initial conditions
        for i in range(iterations):       
            (x,y)=standard_map(x,y,k)
            plg(array([y]),array([x]),type="none",marks=1,marker=1)
           
        ch=mouse(-1,0,"press mouse button")
      
        x,y=ch[0],ch[1]
        if(ch[9]==3): break  # mouse key 3
        plg(array([y]),array([x]))


Sorry, I didn't manage to try the other solutions you proposed, tomorrow 
I will, thanks for now, a solution for the small program would be very 
nice..
Tahnk you in advance, Johannes



From baecker at physik.tu-dresden.de  Thu Mar 13 15:55:33 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Thu, 13 Mar 2003 21:55:33 +0100 (CET)
Subject: [SciPy-user] drawing time
In-Reply-To: <3E70CD51.7060201@gmx.de>
References: <3E70CD51.7060201@gmx.de>
Message-ID: <Pine.LNX.4.51.0303132152350.20715@ptpcp2.phy.tu-dresden.de>

Hi,

there are two more issues which are nicely illustrated with
Johannes standard_map example (at least on my machine under debian linux):
  a) memory blow-up:

     clicking successively several times
     (ie. iterating the map with different initial conditions)
     and following the memory consumption with top
     (or whatever has to be used on windows)
     shows that substial amount of memory is eaten.

     ((the deeper reason for this seems to be that
       in the end all points which have been plotted are stored
       in memory, at least this is was my impression from the
       source in xplt/gist))

  b) Window redraw:

     forcing a window redraw (eg. by moving some other window
     over the Pygist window)
     shows that all points plotted so far in the corresponding region
     get re-plotted, one after another.
     (even worse: try to move some other window around several times
      over the Pygist window and watch ...)

     Wouldn't it be possible to store the picture as
     a bitmap to allow for an easier/quicker redraw ?

Any ideas/solutions ;-) concerning these ?

Arnd


On Thu, 13 Mar 2003, Johannes Broedel wrote:

> Hallo,
>
> thanks for the short progrma, trying ade my computer producing the
> following message (IPython):
>
> In [7]: run sciptest.py
> ---------------------------------------------------------------------------
> MemoryError                               Traceback (most recent call last)
>
> /home/jbroedel/python/graphtest/sciptest.py
>       5 xplt.hold('on')
>       6 for xval in x:
>       7       yval = sin(xval / 4)
> ----> 8       xplt.plot(xval, yval, 'x')
>       9       xplt.pause(100)
>
> /home/python/PYTHON/lib/python2.2/site-packages/scipy/xplt/Mplot.py in
> plot(x, *args, **keywds)
>     480             y = scipy.real(y)
>     481         y = where(scipy.isfinite(y),y,0)
> --> 482
> gist.plg(y,x,type=thetype,color=thecolor,marker=themarker,marks=tomark,width=linewidth)
>     483
>     484         nowplotting = nowplotting + 1
>
> MemoryError:
> WARNING: Failure executing file: <sciptest.py>
>
> The real problem I had was with the following program:
>
>
> #!/usr/bin/env python
>
> from Numeric import *
> from scipy.xplt import *
>
>
> def standard_map(x_cor,y_cor,kappa):
>     """provide one interate of the inital conditions x_cor,y_cor
>        for the standard map with parameter kappa.
>     """
>     y_cor_new=(y_cor-kappa*sin(2.0*pi*x_cor) )% 1
>     x_cor_new=(x_cor+y_cor_new )   % 1
>
>     return(x_cor_new,y_cor_new)
>
>
>
> if __name__ == '__main__':
>     window()             # initialize plotting
>     limits(0.0,1.0,0.0,1.0)
>     x,y=0.5,0.1          # initial (x,y)
>     k=1.1/(2.0*pi)       # parameter
>     animate(0)
>     iterations=1000
>     while 1:             # iterate initial conditions
>         for i in range(iterations):
>             (x,y)=standard_map(x,y,k)
>             plg(array([y]),array([x]),type="none",marks=1,marker=1)
>
>         ch=mouse(-1,0,"press mouse button")
>
>         x,y=ch[0],ch[1]
>         if(ch[9]==3): break  # mouse key 3
>         plg(array([y]),array([x]))
>
>
> Sorry, I didn't manage to try the other solutions you proposed, tomorrow
> I will, thanks for now, a solution for the small program would be very
> nice..
> Tahnk you in advance, Johannes
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>


From oliphant.travis at ieee.org  Thu Mar 13 17:11:23 2003
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Thu, 13 Mar 2003 15:11:23 -0700
Subject: [SciPy-user] drawing time
References: <3E70CD51.7060201@gmx.de>
Message-ID: <3E71020B.9070601@ieee.org>


Johannes Broedel wrote:

> Hallo,
>
> thanks for the short progrma, trying ade my computer producing the 
> following message (IPython):
>
> In [7]: run sciptest.py
> --------------------------------------------------------------------------- 
>
> MemoryError                               Traceback (most recent call 
> last)
>
> /home/jbroedel/python/graphtest/sciptest.py
>      5 xplt.hold('on')
>      6 for xval in x:
>      7       yval = sin(xval / 4)
> ----> 8       xplt.plot(xval, yval, 'x')
>      9       xplt.pause(100)
>
> /home/python/PYTHON/lib/python2.2/site-packages/scipy/xplt/Mplot.py in 
> plot(x, *args, **keywds)
>    480             y = scipy.real(y)
>    481         y = where(scipy.isfinite(y),y,0)
> --> 482         
> gist.plg(y,x,type=thetype,color=thecolor,marker=themarker,marks=tomark,width=linewidth) 
>
>    483
>    484         nowplotting = nowplotting + 1


This looks the problem I had when I first tried the little test program. 
 For me, it was because y and x are scalars (not 1-d arrays) (and the 
xplt.plot program uses squeeze so that even if you try to give it [x] it 
will turn the 1-d array with one element into a scalar).

Gists plg can't use scalars.  This xplt.plot problem was fixed in CVS 
two days ago.

>
> MemoryError:
> WARNING: Failure executing file: <sciptest.py>
>
> The real problem I had was with the following program:
>
> #!/usr/bin/env python
>
> from Numeric import *
> from scipy.xplt import *
>
>
> def standard_map(x_cor,y_cor,kappa):
>    """provide one interate of the inital conditions x_cor,y_cor
>       for the standard map with parameter kappa.
>    """
>    y_cor_new=(y_cor-kappa*sin(2.0*pi*x_cor) )% 1
>    x_cor_new=(x_cor+y_cor_new )   % 1
>
>    return(x_cor_new,y_cor_new)


The code you had worked for me on my system (I'm not sure what it's 
supposed to do, but it generated points on the page).

A couple of things (aside from the indentation problems I had when your 
code came through the email)

1) I would recommend using plot instead of plg.  Plot hides some of the 
oddities and use a MATLAB-style syntax
      for plottin characters.

2) I wouldn't use points for a test like this (they can be very hard to 
see).  I used the following code:


if __name__ == '__main__':
   window()             # initialize plotting
   limits(0.0,1.0,0.0,1.0)
   x,y=0.5,0.1          # initial (x,y)
   k=1.1/(2.0*pi)       # parameter
   animate(0)
   iterations=1000
   xplt.hold('off')
   xplt.fma()
   xplt.hold('on')
   while 1:             # iterate initial conditions
       for i in range(iterations):
           (x,y)=standard_map(x,y,k)
           plot(x,y,'bx')                                       # The b 
means blue, the x means make an x symbol at the point.
           ch=mouse(-1,0,"press mouse button")
           x,y=ch[0],ch[1]
           if(ch[9]==3): break  # mouse key 3
       plg(array([y]),array([x]))   # I don't now what this is supposed 
to do.


-Travis O.





From oliphant.travis at ieee.org  Thu Mar 13 17:19:48 2003
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Thu, 13 Mar 2003 15:19:48 -0700
Subject: [SciPy-user] drawing time
References: <3E70CD51.7060201@gmx.de> <Pine.LNX.4.51.0303132152350.20715@ptpcp2.phy.tu-dresden.de>
Message-ID: <3E710404.8070600@ieee.org>


baecker at physik.tu-dresden.de wrote:

>Hi,
>
>there are two more issues which are nicely illustrated with
>Johannes standard_map example (at least on my machine under debian linux):
>  a) memory blow-up:
>
>     clicking successively several times
>     (ie. iterating the map with different initial conditions)
>     and following the memory consumption with top
>     (or whatever has to be used on windows)
>     shows that substial amount of memory is eaten.
>
>     ((the deeper reason for this seems to be that
>       in the end all points which have been plotted are stored
>       in memory, at least this is was my impression from the
>       source in xplt/gist))
>
This is a common plotting strategy (having this display list allows the 
renderer to output a hard copy when required that is not a bitmap image).

It could also be that gist has memory leaks.  A possibility not 
altogether unlikely.

But!  I do not get the behavior you are observing.    There is no memory 
"blow-up" on my system.

>
>  b) Window redraw:
>
>     forcing a window redraw (eg. by moving some other window
>     over the Pygist window)
>     shows that all points plotted so far in the corresponding region
>     get re-plotted, one after another.
>     (even worse: try to move some other window around several times
>

Again, on my system, there are no problems here.  I do not see any 
noticeable flicker.  I'm not sure what you are talking about.


I don't see any of these problems,  so I'm not sure what the issue is.

-Travis O.


>     Wouldn't it be possible to store the picture as
>     a bitmap to allow for an easier/quicker redraw ?
>
Maybe, but I wouldn't go in this direction for xplt (gist).





From sfalcon at fhcrc.org  Thu Mar 13 20:44:59 2003
From: sfalcon at fhcrc.org (Seth Falcon)
Date: Thu, 13 Mar 2003 17:44:59 -0800
Subject: [SciPy-user] Newbie question on execution time of import scipy
Message-ID: <20030314014458.GI6559@queenbee.fhcrc.org>

I have a beginning to use scipy (hopefully not a beginning to use
Python) question:


I've just installed scipy and am surprised by how long it takes to
do an "import scipy".  Being very new to Python, I don't know
whether "this is how it should be" or if, perhaps something is weird
with my setup.


Example:

    import time
    >>> s = time.time(); import scipy; print time.time() - s
    16.6560000181


Details on my platform:
Win2k
CPU = 1.8GHz
RAM = 1GB
Python = 
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
cipy.__version__ = '0.2.0_alpha_182.4038'


+ seth


From fperez at colorado.edu  Thu Mar 13 20:57:08 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Thu, 13 Mar 2003 18:57:08 -0700
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <20030314014458.GI6559@queenbee.fhcrc.org>
References: <20030314014458.GI6559@queenbee.fhcrc.org>
Message-ID: <3E7136F4.4060008@colorado.edu>

> Example:
> 
>     import time
>     >>> s = time.time(); import scipy; print time.time() - s
>     16.6560000181
> 
> 
> Details on my platform:
> Win2k
> CPU = 1.8GHz
> RAM = 1GB
> Python = 
> Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
> cipy.__version__ = '0.2.0_alpha_182.4038'

Well, scipy is large, but I get:


In [1]: import time

In [2]: >>> s = time.time(); import scipy; print time.time() - s
4.10625100136

on much less hardware than you (1.1 Ghz PIII laptop, RedHat 8.0 running a lot 
of stuff at the same time).  It may be a Windows thing, I guess.

Cheers,

f.



From eric at enthought.com  Thu Mar 13 21:30:47 2003
From: eric at enthought.com (eric jones)
Date: Thu, 13 Mar 2003 20:30:47 -0600
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <3E7136F4.4060008@colorado.edu>
Message-ID: <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop>

Hey Seth,

This is excessive.  I'm not sure why it is so long... 

Using the latest CVS, on a Win XP laptop (2.2 GHz):

ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s = time.time(); import scipy; print time.time() - s
3.01400005817

It may be the build you are using, but I wouldn't think so.  SciPy
imports a lot of extensions.  One of them may be slurping up all the
import time...  You can go into your scipy/__init__.py file (probably in
c:\python22\Lib\site-packages\scipy) and start commenting import
statements out to see if the problem is associated with a particular
module.

eric

-----Original Message-----
From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On
Behalf Of Fernando Perez
Sent: Thursday, March 13, 2003 7:57 PM
To: scipy-user at scipy.net
Subject: Re: [SciPy-user] Newbie question on execution time of import
scipy


> Example:
> 
>     import time
>     >>> s = time.time(); import scipy; print time.time() - s
>     16.6560000181
> 
> 
> Details on my platform:
> Win2k
> CPU = 1.8GHz
> RAM = 1GB
> Python = 
> Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on
win32
> cipy.__version__ = '0.2.0_alpha_182.4038'

Well, scipy is large, but I get:


In [1]: import time

In [2]: >>> s = time.time(); import scipy; print time.time() - s
4.10625100136

on much less hardware than you (1.1 Ghz PIII laptop, RedHat 8.0 running
a lot 
of stuff at the same time).  It may be a Windows thing, I guess.

Cheers,

f.

_______________________________________________
SciPy-user mailing list
SciPy-user at scipy.net
http://www.scipy.net/mailman/listinfo/scipy-user




From travis at enthought.com  Fri Mar 14 00:16:30 2003
From: travis at enthought.com (Travis N. Vaught)
Date: Thu, 13 Mar 2003 23:16:30 -0600
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop>
Message-ID: <000201c2e9e8$dfe115b0$0300a8c0@ericlaptop>

Interestingly I get the following:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\travis>python
ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s=time.time();import scipy;print time.time()-s
6.45899999142
>>>
^C
C:\Documents and Settings\travis>
C:\Documents and Settings\travis>python
ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s=time.time();import scipy;print time.time()-s
1.19200003147
>>>

This is using:
Intel Pentium III processor
698 MHz
256 MB of RAM

Weird, huh?

BTW the scipy version is:
>>> scipy.__version__
'0.2.0_alpha_154.4535'
>>>

I then upgraded to the latest build for Python 2.2 and got the
following:

ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s=time.time();import scipy;print time.time()-s
5.09800004959
>>> ^Z

C:\Documents and Settings\travis>python
ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s=time.time();import scipy;print time.time()-s
1.38199996948
>>>

This is with:
>>> scipy.__version__
'0.2.0_alpha_182.4038'

Hope this provides some insight.

Travis


........................
Travis N. Vaught
Enthought, Inc.
(512)536-1057
http://www.enthought.com
........................


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of eric jones
> Sent: Thursday, March 13, 2003 8:31 PM
> To: scipy-user at scipy.net
> Subject: RE: [SciPy-user] Newbie question on execution time of import
> scipy
> 
> Hey Seth,
> 
> This is excessive.  I'm not sure why it is so long...
> 
> Using the latest CVS, on a Win XP laptop (2.2 GHz):
> 
> ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
> Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on
win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time
> >>> s = time.time(); import scipy; print time.time() - s
> 3.01400005817
> 
> It may be the build you are using, but I wouldn't think so.  SciPy
> imports a lot of extensions.  One of them may be slurping up all the
> import time...  You can go into your scipy/__init__.py file (probably
in
> c:\python22\Lib\site-packages\scipy) and start commenting import
> statements out to see if the problem is associated with a particular
> module.
> 
> eric
> 
> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Fernando Perez
> Sent: Thursday, March 13, 2003 7:57 PM
> To: scipy-user at scipy.net
> Subject: Re: [SciPy-user] Newbie question on execution time of import
> scipy
> 
> 
> > Example:
> >
> >     import time
> >     >>> s = time.time(); import scipy; print time.time() - s
> >     16.6560000181
> >
> >
> > Details on my platform:
> > Win2k
> > CPU = 1.8GHz
> > RAM = 1GB
> > Python =
> > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on
> win32
> > cipy.__version__ = '0.2.0_alpha_182.4038'
> 
> Well, scipy is large, but I get:
> 
> 
> In [1]: import time
> 
> In [2]: >>> s = time.time(); import scipy; print time.time() - s
> 4.10625100136
> 
> on much less hardware than you (1.1 Ghz PIII laptop, RedHat 8.0
running
> a lot
> of stuff at the same time).  It may be a Windows thing, I guess.
> 
> Cheers,
> 
> f.
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
> 
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user



From baecker at physik.tu-dresden.de  Fri Mar 14 02:15:08 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Fri, 14 Mar 2003 08:15:08 +0100 (CET)
Subject: [SciPy-user] drawing time
In-Reply-To: <3E710404.8070600@ieee.org>
References: <3E70CD51.7060201@gmx.de> <Pine.LNX.4.51.0303132152350.20715@ptpcp2.phy.tu-dresden.de>
 <3E710404.8070600@ieee.org>
Message-ID: <Pine.LNX.4.51.0303140800400.23214@ptpcp2.phy.tu-dresden.de>

Hi,

thank you very much for looking into this!
(Just to be sure: to enhance the effect, increase
  iterations=10000
and click several (10-20) times at different points.
Did you try this under Windows or Linux ?)

I will give more detailed tests on different machines
and report later (=Monday) to have a sample of at least three
different machines.
If you have any suggestions for this, please let me know.

Again many thanks,

Arnd

P.S.:  A few remarks on the following :

> >Johannes standard_map example (at least on my machine under debian linux):
> >  a) memory blow-up:
[...]
> This is a common plotting strategy (having this display list allows the
> renderer to output a hard copy when required that is not a bitmap image).

Valid point - however, this causes problems
in some situations, namely if one plots several thousands
of points. It seems that only pgplot and plplot (and maybe
dislin, but that's not really free) do not store the points.
However, both pgplot and plplot are not really (at least easily as
far as I know) available for MS Windows.


> It could also be that gist has memory leaks.  A possibility not
> altogether unlikely.

Hmm, but if you don't observe the problem there might be
some other reason ... (I will try tto check ...)

> >     Wouldn't it be possible to store the picture as
> >     a bitmap to allow for an easier/quicker redraw ?
> >
> Maybe, but I wouldn't go in this direction for xplt (gist).

Of course I am looking forward to chaco,
but at present I fear a bit the long tool-chain
(with wxWindows, wxPython and all their dependencies),
speed issues and, presumably it will also store all the
points which have been plotted in memory
(nice for zooming and printing, but not for several 100000 of points,
or ?) - but that might be leading to a different thread
(and I better keep my wish-list for chaco private at the moment ... ;-)


From baecker at physik.tu-dresden.de  Fri Mar 14 01:58:03 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Fri, 14 Mar 2003 07:58:03 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
Message-ID: <Pine.LNX.4.51.0303140757170.23214@ptpcp2.phy.tu-dresden.de>

Hi,

I am trying to install scipy (CVS version) under
SUSE linux.
Unfortunately, it seems the "delivered" blas is one of those
incomplete ones which don't have srotmg_ .


As the whole installation is supposed to work
for a set of Intel PIII  machines and a set of more recent Athlons
I don't think that building ATLAS would be an optimal solution.
Do you have any recommendation in this situation ?
(Should I build lapack and blas from scratch ?)

(Another thing is, that python scipy/scipy_core/system_info.py
does not detect the fftw routines (I hope they are the
right ones, but I could not test this yet) which
are found under the names:
/usr/lib/libdfftw.so.2
/usr/lib/libdfftw.so.2.0.5
/usr/lib/libdrfftw.so.2
/usr/lib/libdrfftw.so.2.0.5
/usr/lib/libsfftw.so.2
/usr/lib/libsfftw.so.2.0.5
/usr/lib/libsrfftw.so.2
/usr/lib/libsrfftw.so.2.0.5

Can one just change the names in site.cfg accordingly
to get them detected ?

((One more thing: it might be nice if system_info.py
reports which of the possible alternatives
(atlas, lapack/blas etc.) will be used in the end.))

Many thanks,

Arnd




From baecker at physik.tu-dresden.de  Fri Mar 14 01:50:05 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Fri, 14 Mar 2003 07:50:05 +0100 (CET)
Subject: [SciPy-user] xplt.eps question/problem?
Message-ID: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de>

Hi,

I tried to use the eps function in xplt
and get the following error message:

sed: -e expression #2, char 15: Extra characters after command
cat: write error: Broken pipe

An example program for this is below.

Any suggestions welcome! Many thanks,

Arnd


########################################################################
"""
    test eps output with scipy.xplt

    Hmm, markers are not shown properly near the boundary ?!

"""
#!/usr/bin/env python

from Numeric import *
from scipy.xplt import *


if __name__ == '__main__':
    window()             # initialize plotting
    limits(0.0,2.0,-1.0,1.0)

    x=arange(0.0,2.0,0.01)
    y=sin(x)
    plg(y,x,type="none",marks=1,marker=2)

    ch=mouse(-1,0,"press mouse button")

    eps("test.ps")



From lanceboyle at myrealbox.com  Fri Mar 14 04:41:50 2003
From: lanceboyle at myrealbox.com (Lance Boyle)
Date: Fri, 14 Mar 2003 02:41:50 -0700
Subject: [SciPy-user] Newbie Q: Trying to install on Mac OS X
Message-ID: <2E9C8F36-5601-11D7-9609-003065F93FF0@myrealbox.com>

I'm attempting to install SciPy on Mac OS X 10.2.4, December Developer 
Tools, 500 MHz Titanium PowerBook (G4 processor). I'm using fink 
(fink.sourceforge.net) to manage the installation, which uses Version 
20021007-1 of SciPy.

Perhaps I should ask this question of someone concerned with ATLAS. 
However:

After about an hour into the installation, a timing function in the 
ATLAS installer failed. I followed the instructions under "Your install 
dies with 'unable to get timings in tolerance'" on the ATLAS errata 
page at http://math-atlas.sourceforge.net/errata.html#tol.

I did three things. First, I killed off all unnecessary processes. 
Second, I followed this suggestion from the errata page:


... edit the files ATLAS/include/ARCH/atlas_?sysinfo.h.  Each of these 
four files will have a quantity called ATL_nkflop.  Pump this quantity 
up by some significant factor until timings are regular.  I usually 
increase it by a factor of 5 or 10...


I increased these four numbers by a factor of 10.

Third, I restarted the installation as instructed on the "errata" page. 
The ARCHDEF and MMDEF macros alluded to were empty; ARCHDEF = <blank> 
and MMDEF = <blank>, but I commented them out anyway.

I restarted the installation process and as far as I can tell, the 
ATLAS optimization is still going on some 20 hours later.

Is this normal? There is still new output appearing in the terminal. 
Suggestions?

Jerry
Tempe, AZ, USA



From sfalcon at fhcrc.org  Fri Mar 14 12:12:54 2003
From: sfalcon at fhcrc.org (Seth Falcon)
Date: Fri, 14 Mar 2003 09:12:54 -0800
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop>
References: <3E7136F4.4060008@colorado.edu> <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop>
Message-ID: <20030314171253.GA13251@queenbee.fhcrc.org>

> This is excessive.  I'm not sure why it is so long... 

Glad to hear it (that it is excessive, not that you aren't sure
why).

In playing around, I've isolated the problem somewhat:

I was running the python interpreter from within a cygwin bash
window.  I *was* careful to invoke my windows Python installation
using '/cygdrive/c/Python22/python.exe'.  Nevertheless, from within
cygwin, I get a 16 second import time for scipy.

Opening a windows cmd terminal and invoking the Python interpreter
results in a *much* improved import time: 3.0 seconds!  

Not sure why the big difference, but it looks like it is a cygwin
issue, not a Python one.

BTW, I noticed that you are using the ActivePython build.  I'm
curious to know if people have suggestions as far as which builds to
use and why. 

+ seth



From travis at enthought.com  Fri Mar 14 12:27:58 2003
From: travis at enthought.com (Travis N. Vaught)
Date: Fri, 14 Mar 2003 11:27:58 -0600
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <20030314171253.GA13251@queenbee.fhcrc.org>
Message-ID: <032701c2ea4f$0f1add50$0300a8c0@ericlaptop>

This ventures a bit off-topic, but...
As far as ActiveState vs. Python.org distributions for windows, I have
used ActiveState purely for the convenience of the win32_all extensions
(and ppm Numeric is pretty easy to get, too).  Recently this benefit has
gone away because I have installed SpamBayes Outlook 2000 plugin
(http://spambayes.sourceforge.net/) which requires a more recent
win32_all version than ActiveState distributes (so back to the separate
download).

As far as performance/stability or anything else that might affect scipy
on either Python distribution--I haven't noticed any difference either
way (as you might expect).

Travis

> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Seth Falcon
> Sent: Friday, March 14, 2003 11:13 AM
> To: scipy-user at scipy.net
> Subject: Re: [SciPy-user] Newbie question on execution time of import
> scipy
> 
> > This is excessive.  I'm not sure why it is so long...
> 
> Glad to hear it (that it is excessive, not that you aren't sure
> why).
> 
> In playing around, I've isolated the problem somewhat:
> 
> I was running the python interpreter from within a cygwin bash
> window.  I *was* careful to invoke my windows Python installation
> using '/cygdrive/c/Python22/python.exe'.  Nevertheless, from within
> cygwin, I get a 16 second import time for scipy.
> 
> Opening a windows cmd terminal and invoking the Python interpreter
> results in a *much* improved import time: 3.0 seconds!
> 
> Not sure why the big difference, but it looks like it is a cygwin
> issue, not a Python one.
> 
> BTW, I noticed that you are using the ActivePython build.  I'm
> curious to know if people have suggestions as far as which builds to
> use and why.
> 
> + seth
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user



From oliphant.travis at ieee.org  Fri Mar 14 12:35:03 2003
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Fri, 14 Mar 2003 10:35:03 -0700
Subject: [SciPy-user] xplt.eps question/problem?
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de>
Message-ID: <3E7212C7.8050405@ieee.org>


baecker at physik.tu-dresden.de wrote:
> Hi,
> 
> I tried to use the eps function in xplt
> and get the following error message:
> 
> sed: -e expression #2, char 15: Extra characters after command
> cat: write error: Broken pipe
> 

You probably have a broken ps2epsi script.   Get a later version.

You could test this by issuing noepsi=1 to xplt.eps which will not 
convert the postscript to an epsi image.


-Travis O.




From pearu at cens.ioc.ee  Fri Mar 14 02:12:51 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 14 Mar 2003 09:12:51 +0200 (EET)
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop>
Message-ID: <Pine.LNX.4.21.0303140801310.17648-100000@cens.kybi>

Hi,

On a Debian Linux with PII (400 MHz) I see similar behaviour to Travis's
report:

pearu at localhost:~$ python
import time
Python 2.2.1 (#1, Jul 29 2002, 23:15:49) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s=time.time();import scipy;print time.time()-s
13.2945020199
>>> 
pearu at localhost:~$ python
Python 2.2.1 (#1, Jul 29 2002, 23:15:49) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> s=time.time();import scipy;print time.time()-s
2.07088291645
>>> 

In the first import I also hear lots of harddisk activity while in the
second try none of that, probably all libraries are in memory cache
then. So, these excessive scipy import times actually measure the speed of
harddisks, not CPUs. And the import time may vary depending on
available RAM, whether shared libraries were loaded before (e.g. debian
provides shared ATLAS libraries), etc.

Most of the time for scipy import is taken probably by scipy.linalg
which contains the largest extension modules. If your applications require 
mostly double precision routines then the size of linalg extension modules
can be reduced by setting 

skip_single_routines = 1

in the header of linalg/setup_linalg.py (notice also comments there).

However, now I that have tested building scipy.linalg against shared and
static atlas libraries, with and without skip_single_routines being set,
I am surprised that I still cannot draw conclusions which combination
is most efficient: the results vary too much on subsequent tests
and in average the timing results seem to be the same.

It seems the states of memory and cache as well as the speed of
harddisk are the key factors that determine actual scipy import time,
the CPU speed has a secondary importance.

In any case, the scipy import time 2-13 seconds is a killer for certain
tasks, this is also one of the reasons why I have commiting so much 
patches to get scipy modules usable as standalone.

The only solution to get a speed up in scipy import would be to start
using lazy import techniques. However, such techniques are usually highly
experimental and 'from .. import ..' type of imports (that scipy modules
extensively use, unfortunately) make implementing lazy import hooks
harder.

Regards,
	Pearu




From pearu at cens.ioc.ee  Fri Mar 14 02:41:29 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 14 Mar 2003 09:41:29 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303140757170.23214@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303140919390.17648-100000@cens.kybi>

On Fri, 14 Mar 2003 baecker at physik.tu-dresden.de wrote:

> I am trying to install scipy (CVS version) under
> SUSE linux.
> Unfortunately, it seems the "delivered" blas is one of those
> incomplete ones which don't have srotmg_ .
> 
> 
> As the whole installation is supposed to work
> for a set of Intel PIII  machines and a set of more recent Athlons
> I don't think that building ATLAS would be an optimal solution.
> Do you have any recommendation in this situation ?
> (Should I build lapack and blas from scratch ?)

Using ATLAS instead of blas/lapack gives certainly a huge execution speed
advantage. However, I you wish not to use ATLAS, then rebuilding blas (no
need to rebuild lapack) would solve the problem. Another solution is
to look at linalg/setup_linalg.py and append missing symbols like srotmg
to

  skip_names['cblas']
  skip_names['fblas']

lists in appropiate places (should be clear from the code).
Whenever making changes to skip_names, you should manually remove
fblas.pyf and cblas.pyf files before building.

> (Another thing is, that python scipy/scipy_core/system_info.py
> does not detect the fftw routines (I hope they are the
> right ones, but I could not test this yet) which
> are found under the names:
> /usr/lib/libdfftw.so.2
> /usr/lib/libdfftw.so.2.0.5
> /usr/lib/libdrfftw.so.2
> /usr/lib/libdrfftw.so.2.0.5
> /usr/lib/libsfftw.so.2
> /usr/lib/libsfftw.so.2.0.5
> /usr/lib/libsrfftw.so.2
> /usr/lib/libsrfftw.so.2.0.5
> 
> Can one just change the names in site.cfg accordingly
> to get them detected ?

Not recommended.
You should install libfftw-dev package (on suse libfftw-dev may
have different name, though). Note that building fftw wrapper requires
also fftw header files.

> ((One more thing: it might be nice if system_info.py
> reports which of the possible alternatives
> (atlas, lapack/blas etc.) will be used in the end.))

Actually, system_info does not decide what will be used at the end,
setup_linalg.py makes that choice. So, you can see which resources will be
used from the output of building scipy.

The following rule applies:
  If atlas libraries are available then atlas is used;
  else if lapack/blas libraries are available then they are used;
  else if lapack/blas sources are available then they are used;
  else not found error exception is raised.

Pearu



From eric at enthought.com  Fri Mar 14 15:17:28 2003
From: eric at enthought.com (eric jones)
Date: Fri, 14 Mar 2003 14:17:28 -0600
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <Pine.LNX.4.21.0303140801310.17648-100000@cens.kybi>
Message-ID: <006001c2ea66$bf7bca80$8901a8c0@ERICDESKTOP>

> In any case, the scipy import time 2-13 seconds is a killer for
certain
> tasks, this is also one of the reasons why I have commiting so much
> patches to get scipy modules usable as standalone.

Yep.  I usually import it, along with other large modules, in a
background thread during the splash screen of GUI applications to mask
the time.  :-|

I'm don't know of an obvious way around this except for the lazy
imports. By the way, how long does it take Matlab to start up?  It has
to load a similar amount of stuff I would think.

eric




From mbakker at engr.uga.edu  Fri Mar 14 16:31:03 2003
From: mbakker at engr.uga.edu (Mark Bakker)
Date: Fri, 14 Mar 2003 16:31:03 -0500
Subject: [SciPy-user] MATLAB start-up
Message-ID: <3E724A17.7050006@engr.uga.edu>

Eric is right.
Matlab takes a very long time to start-up (MUCH longer than importing 
scipy on my machine). Although I tend to agree that importing scipy is 
somewhat annoyingly long. What I don't understand is that even when I 
import just one method, say
from scipy.special import k0
it still takes a long time.
Not sure why,
Mark

 > In any case, the scipy import time 2-13 seconds is a killer for
certain
 > tasks, this is also one of the reasons why I have commiting so much
 > patches to get scipy modules usable as standalone.

Yep.  I usually import it, along with other large modules, in a
background thread during the splash screen of GUI applications to mask
the time.  :-|

I'm don't know of an obvious way around this except for the lazy
imports. By the way, how long does it take Matlab to start up?  It has
to load a similar amount of stuff I would think.

eric



From pearu at cens.ioc.ee  Fri Mar 14 16:34:52 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 14 Mar 2003 23:34:52 +0200 (EET)
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <006001c2ea66$bf7bca80$8901a8c0@ERICDESKTOP>
Message-ID: <Pine.LNX.4.21.0303142309160.17648-100000@cens.kybi>

On Fri, 14 Mar 2003, eric jones wrote:

> I'm don't know of an obvious way around this except for the lazy
> imports.

Implementing lazy imports would be much easier and less errorprone
if scipy packages would always use 'import ..' for larger packages
such as linalg, etc, for instance.
Are there any objections to start using such a policy?
Note that using 'from .. import ..' for importing scipy_base or Numeric is
still fine, they need to be loaded anyway.

> By the way, how long does it take Matlab to start up?  It has
> to load a similar amount of stuff I would think.

(date ; matlab -nodisplay -nosplash -r quit; date)

gives 4-5 seconds difference on dual PII 350MHz with Matlab R13.
With other graphical bells and whistles matlab load time can go up to half
a minute.

Pearu



From eric at enthought.com  Fri Mar 14 16:52:17 2003
From: eric at enthought.com (eric jones)
Date: Fri, 14 Mar 2003 15:52:17 -0600
Subject: [SciPy-user] MATLAB start-up
In-Reply-To: <3E724A17.7050006@engr.uga.edu>
Message-ID: <009301c2ea73$fe409860$8901a8c0@ERICDESKTOP>

> Eric is right.
> Matlab takes a very long time to start-up (MUCH longer than importing
> scipy on my machine). 

Hmm.  That doesn't bode well for us being able to speed it up using some
magic trick.  On the bright side though, MS Word used to take forever to
load.  The recent version loads extremely fast.  They have a lot more
control over how loading occurs, but still, we can probably find some
places to cut time.  This isn't something I have much knowledge about.
Maybe David Beazley does -- he is a linker/loader/library nut.  I've
copied him on the mail.

> Although I tend to agree that importing scipy is
> somewhat annoyingly long. What I don't understand is that even when I
> import just one method, say from scipy.special import k0
> it still takes a long time.

Python runs the entire scipy/__init__.py even when you use the "from x.y
import z" format.  

> Not sure why,
> Mark
> 
>  > In any case, the scipy import time 2-13 seconds is a killer for
> certain
>  > tasks, this is also one of the reasons why I have commiting so much
>  > patches to get scipy modules usable as standalone.
> 
> Yep.  I usually import it, along with other large modules, in a
> background thread during the splash screen of GUI applications to mask
> the time.  :-|
> 
> I'm don't know of an obvious way around this except for the lazy
> imports. By the way, how long does it take Matlab to start up?  It has
> to load a similar amount of stuff I would think.
> 
> eric
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From pearu at cens.ioc.ee  Fri Mar 14 16:50:58 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 14 Mar 2003 23:50:58 +0200 (EET)
Subject: [SciPy-user] MATLAB start-up
In-Reply-To: <3E724A17.7050006@engr.uga.edu>
Message-ID: <Pine.LNX.4.21.0303142337360.17648-100000@cens.kybi>

On Fri, 14 Mar 2003, Mark Bakker wrote:

> Eric is right.
> Matlab takes a very long time to start-up (MUCH longer than importing 
> scipy on my machine). Although I tend to agree that importing scipy is 
> somewhat annoyingly long. What I don't understand is that even when I 
> import just one method, say
> from scipy.special import k0
> it still takes a long time.
> Not sure why,

This is because when you import scipy, then *everything* in scipy gets
loaded. 'from scipy.xxx import ..' is even more aggressive...
This is the price to pay for getting everything into scipy namespace when
using 'from scipy import *', for instance.

Idea: if scipy would install modules like special, linalg, fftpack etc
as scipy_special, scipy_linalg, scipy_fftpack (that are standalone modules 
that also scipy imports) then e.g.
  from scipy_special import k0
would be very fast. This approach would float site-packages directory with
packages scipy_* (there are, say, 10 of such packages) but I think it is
worth of considering. 
What do you think?

Pearu



From baecker at physik.tu-dresden.de  Fri Mar 14 18:39:36 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Sat, 15 Mar 2003 00:39:36 +0100 (CET)
Subject: [SciPy-user] xplt.eps question/problem?
In-Reply-To: <3E7212C7.8050405@ieee.org>
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de>
 <3E7212C7.8050405@ieee.org>
Message-ID: <Pine.LNX.4.51.0303150038120.27849@ptpcp2.phy.tu-dresden.de>

> You probably have a broken ps2epsi script.   Get a later version.

Just for completeness: the ps2epsi script starts with

#!/bin/sh
# $RCSfile: ps2epsi,v $ $Revision: 1.4.2.2 $

> You could test this by issuing noepsi=1 to xplt.eps which will not
> convert the postscript to an epsi image.

Indeed, that does work.
Ok, now I will start searching for a sufficiently new ps2epsi script.

Many thanks,

Arnd



From sfalcon at fhcrc.org  Fri Mar 14 19:34:47 2003
From: sfalcon at fhcrc.org (Seth Falcon)
Date: Fri, 14 Mar 2003 16:34:47 -0800
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <20030314171253.GA13251@queenbee.fhcrc.org>
References: <3E7136F4.4060008@colorado.edu> <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop> <20030314171253.GA13251@queenbee.fhcrc.org>
Message-ID: <20030315003447.GI13251@queenbee.fhcrc.org>

On Fri, Mar 14, 2003 at 09:12:54AM -0800, Seth Falcon wrote:
> In playing around, I've isolated the problem somewhat:
> 
> I was running the python interpreter from within a cygwin bash
> window.  I *was* careful to invoke my windows Python installation
> using '/cygdrive/c/Python22/python.exe'.  Nevertheless, from within
> cygwin, I get a 16 second import time for scipy.
> 
> Opening a windows cmd terminal and invoking the Python interpreter
> results in a *much* improved import time: 3.0 seconds!  


Upon some further experimentation, it turns out that the difference
in import time has nothing to do with cygwin.  Instead, it has to do
with the directory you start in.

Executing from a network mapped drive is slow.  I still find this
surprising because all of the executables/libraries/packages are on
local disk.  I know that Python will search the current directory
for modules, but I don't see how that could account for the slowdown
unless it is search on the network drive in places other than
current directory ??

+ seth


From DavidA at ActiveState.com  Fri Mar 14 20:06:31 2003
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 14 Mar 2003 17:06:31 -0800
Subject: [SciPy-user] Newbie question on execution time of import scipy
In-Reply-To: <20030315003447.GI13251@queenbee.fhcrc.org>
References: <3E7136F4.4060008@colorado.edu> <001f01c2e9d1$bc3016a0$957ba8c0@fastlaptop> <20030314171253.GA13251@queenbee.fhcrc.org> <20030315003447.GI13251@queenbee.fhcrc.org>
Message-ID: <3E727C97.8040609@ActiveState.com>

Seth Falcon wrote:

> Executing from a network mapped drive is slow.  I still find this
> surprising because all of the executables/libraries/packages are on
> local disk.  I know that Python will search the current directory
> for modules, but I don't see how that could account for the slowdown
> unless it is search on the network drive in places other than
> current directory ??

Each module import will result in a few stat() calls in the local directory 
(looking for .so, .pyd, .pyc/.pyo, and .py).  If each stat call is very slow, 
those add up, especially as scipy does a lot of imports.

--david




From loo_yee at 263.net  Fri Mar 14 21:19:56 2003
From: loo_yee at 263.net (loo yee)
Date: Sat, 15 Mar 2003 10:19:56 +0800
Subject: [SciPy-user] import scipy error
Message-ID: <000c01c2ea9c$54b6f770$1900a8c0@N15>

Hi,
    I am a newbie in Python and SciPy, but I find Python is a very good language, it is so easy to learn it:)
    I installed Python 2.2, Numeric 22.0, and SciPy-0.2.0_alpha_182.4038.win32-py2.2. But when I import scipy in IDLE Python 2.2, the import failed:|
    >>> import scipy
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    import scipy
  File "C:\PYTHON22\Lib\site-packages\scipy\__init__.py", line 49, in ?
    import special, io, linalg, stats, fftpack
  File "C:\PYTHON22\Lib\site-packages\scipy\linalg\__init__.py", line 44, in ?
    from basic import *
  File "C:\PYTHON22\Lib\site-packages\scipy\linalg\basic.py", line 11, in ?
    from lapack import get_lapack_funcs
  File "C:\PYTHON22\Lib\site-packages\scipy\linalg\lapack.py", line 9, in ?
    from scipy_distutils.misc_util import PostponedException
ImportError: cannot import name PostponedException

   But when I import in PythonWin, it is successfully.

  Can anyone tell me why?

Best Regards,

Yi Lu

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

From oliphant.travis at ieee.org  Sat Mar 15 00:00:24 2003
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Fri, 14 Mar 2003 22:00:24 -0700
Subject: [SciPy-user] Newbie question on execution time of import scipy
References: <Pine.LNX.4.21.0303142309160.17648-100000@cens.kybi>
Message-ID: <3E72B368.8020102@ieee.org>


Pearu Peterson wrote:
> On Fri, 14 Mar 2003, eric jones wrote:
> 
> 
>>I'm don't know of an obvious way around this except for the lazy
>>imports.
> 
> 
> Implementing lazy imports would be much easier and less errorprone
> if scipy packages would always use 'import ..' for larger packages
> such as linalg, etc, for instance.
> Are there any objections to start using such a policy?

No, that's a good idea.  We should go back and change some of the files too.


> 
> (date ; matlab -nodisplay -nosplash -r quit; date)
> 

With Matlab R12.1 on a 930MHZ Pentium III I get 6 seconds the first time 
and 3 seconds there after.

I get very similiar results (5.5 seconds the first time and 2.5 seconds 
there after) for importing scipy.

-Travis O.




From oliphant.travis at ieee.org  Sat Mar 15 00:03:43 2003
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Fri, 14 Mar 2003 22:03:43 -0700
Subject: [SciPy-user] MATLAB start-up
References: <009301c2ea73$fe409860$8901a8c0@ERICDESKTOP>
Message-ID: <3E72B42F.70602@ieee.org>


eric jones wrote:
>>Eric is right.
>>Matlab takes a very long time to start-up (MUCH longer than importing
>>scipy on my machine). 
> 
> 
> Hmm.  That doesn't bode well for us being able to speed it up using some
> magic trick.  On the bright side though, MS Word used to take forever to
> load.  The recent version loads extremely fast.  

Isn't this because they load the DLL's at boot up time?   I don't know 
if we could pull something like that as easily.

I think Pearu's idea has some merit.  Perhaps we should think about 
making scipy wide instead of deep.  This would also allow people to use 
parts of scipy more easily.

-Travis O.




From oliphant.travis at ieee.org  Sat Mar 15 00:06:33 2003
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Fri, 14 Mar 2003 22:06:33 -0700
Subject: [SciPy-user] xplt.eps question/problem?
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de> <3E7212C7.8050405@ieee.org> <Pine.LNX.4.51.0303150038120.27849@ptpcp2.phy.tu-dresden.de>
Message-ID: <3E72B4D9.7040608@ieee.org>

> Just for completeness: the ps2epsi script starts with
> 
> #!/bin/sh
> # $RCSfile: ps2epsi,v $ $Revision: 1.4.2.2 $

This looks new enough.  The error you are getting looks like something I 
was getting a while ago.  What version of ghostscript to you have 
(ps2epsi just runs ghostscript)?   Maybe your version of ps2epsi is too 
new :-)

-Travis O.




From prabhu at aero.iitm.ernet.in  Sat Mar 15 00:45:31 2003
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 15 Mar 2003 11:15:31 +0530
Subject: [SciPy-user] MATLAB start-up
In-Reply-To: <Pine.LNX.4.21.0303142337360.17648-100000@cens.kybi>
References: <3E724A17.7050006@engr.uga.edu>
	<Pine.LNX.4.21.0303142337360.17648-100000@cens.kybi>
Message-ID: <15986.48635.223079.669547@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at cens.ioc.ee> writes:

    PP> Idea: if scipy would install modules like special, linalg,
    PP> fftpack etc as scipy_special, scipy_linalg, scipy_fftpack
    PP> (that are standalone modules that also scipy imports) then
    PP> e.g.  from scipy_special import k0 would be very fast. This
    PP> approach would float site-packages directory with packages
    PP> scipy_* (there are, say, 10 of such packages) but I think it
    PP> is worth of considering.  What do you think?

If you are going to look at lazy importing you might want to check out
the Python mega widgets.  It does some kind of lazy importing.  I
havent looked at it closely enough to know what it does but perhaps it
would be useful to look at it.

cheers,
prabhu


From pearu at cens.ioc.ee  Sat Mar 15 03:54:29 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 15 Mar 2003 10:54:29 +0200 (EET)
Subject: [SciPy-user] MATLAB start-up
In-Reply-To: <15986.48635.223079.669547@monster.linux.in>
Message-ID: <Pine.LNX.4.21.0303151018530.17648-100000@cens.kybi>

On Sat, 15 Mar 2003, Prabhu Ramachandran wrote:

> >>>>> "PP" == Pearu Peterson <pearu at cens.ioc.ee> writes:
> 
>     PP> Idea: if scipy would install modules like special, linalg,
>     PP> fftpack etc as scipy_special, scipy_linalg, scipy_fftpack
>     PP> (that are standalone modules that also scipy imports) then
>     PP> e.g.  from scipy_special import k0 would be very fast. This
>     PP> approach would float site-packages directory with packages
>     PP> scipy_* (there are, say, 10 of such packages) but I think it
>     PP> is worth of considering.  What do you think?
> 
> If you are going to look at lazy importing you might want to check out
> the Python mega widgets.  It does some kind of lazy importing.  I
> havent looked at it closely enough to know what it does but perhaps it
> would be useful to look at it.

Thanks for the hint!

The overview of a Pmw dynamic loader can be found at

  http://pmw.sourceforge.net/doc/dynamicloader.html

The three purposes of the dynamic loader are (below using scipy instead
of Pmw):

- to give access to all scipy classes and functions through a single entry
  point, `scipy`.
- to delay the importing of the sub-modules until they are needed.
- to allow a script using scipy to specify which version of scipy it
  requires.

Only the first two purposes are relevant for scipy. This should make
implementing the corresponding dynamic loader for scipy much easier.

Notice that using the idea of scipy_xxx does not exclude using dynamic
loader (in fact, Pmw assumes similar convention for its subpackages).
Further on, scipy.xxx can be still made available by using
`import scipy_xxx as xxx` in scipy/__init__.py, if scipy backforward
compatibility is important, for instance.

Pearu




From baecker at physik.tu-dresden.de  Sat Mar 15 14:58:32 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Sat, 15 Mar 2003 20:58:32 +0100 (CET)
Subject: [SciPy-user] xplt.eps question/problem?
In-Reply-To: <3E72B4D9.7040608@ieee.org>
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de>
 <3E7212C7.8050405@ieee.org> <Pine.LNX.4.51.0303150038120.27849@ptpcp2.phy.tu-dresden.de>
 <3E72B4D9.7040608@ieee.org>
Message-ID: <Pine.LNX.4.51.0303151259440.30895@ptpcp2.phy.tu-dresden.de>

Finally I found the reason for the error:

On Fri, 14 Mar 2003, Travis Oliphant wrote:

> > Just for completeness: the ps2epsi script starts with
> >
> > #!/bin/sh
> > # $RCSfile: ps2epsi,v $ $Revision: 1.4.2.2 $
>
> This looks new enough.  The error you are getting looks like something I
> was getting a while ago.  What version of ghostscript to you have

gs -v gives
GNU Ghostscript 7.05 (2002-04-22)
Copyright (C) 2002 artofcode LLC, Benicia, CA.  All rights reserved.

> (ps2epsi just runs ghostscript)?   Maybe your version of ps2epsi is too
> new :-)

Hmm, not sure - it is just the ps2epsi which comes with the ghostscript
in debian testing.

However, (to come to something positive):
using ps2epsi from the CVS of www.ghostscript.com
( Version # $Id: ps2epsi,v 1.9 2002/02/21 21:49:28 giles Exp $,
to be found under gs/lib) I don't get an error anymore.
Interestingly, the difference between the two versions is minor,
see the diff below.
At first sight one might think that it is
the encapsulation of ${infile} via "${infile}".
However, it is just a missing space in front
of the "-e" of ps2epsi (in the CVS version several spaces
are used to make the code line up nicely).

So anyone seeing this error hopefully can fix this by
just adding this space...

BTW: the noepsi=1 version is (for my example) 17KB in size
and the one with noepsi=0, i.e. the default,
is 280KB, quite a difference!

Many thanks,

Arnd

-----------------------------

diff ps2epsi ps2epsi_noncvs
2c2
< # $Id: ps2epsi,v 1.9 2002/02/21 21:49:28 giles Exp $
---
> # $RCSfile: ps2epsi,v $ $Revision: 1.4.2.2 $
18,22c18,22
<         *.ps)         base=`basename "${infile}" .ps` ;;
<         *.cps)        base=`basename "${infile}" .cps` ;;
<         *.eps)        base=`basename "${infile}" .eps` ;;
<         *.epsf)       base=`basename "${infile}" .epsf` ;;
<         *)            base=`basename "${infile}"` ;;
---
>         *.ps)         base=`basename ${infile} .ps` ;;
>         *.cps)        base=`basename ${infile} .cps` ;;
>         *.eps)        base=`basename ${infile} .eps` ;;
>         *.epsf)       base=`basename ${infile} .epsf` ;;
>         *)            base=`basename ${infile}` ;;
29c29
< ls -l "${infile}" |
---
> ls -l ${infile} |
52c52
<       ' U="$USERNAME$LOGNAME"  F=1 - F=2 "${infile}" >$tmpfile
---
>       ' U="$USERNAME$LOGNAME"  F=1 - F=2 ${infile} >$tmpfile
54c54
< gs -q -dNOPAUSE -dSAFER -dDELAYSAFER -r72 -sDEVICE=bit
-sOutputFile=/dev/null $tmpfile ps2epsi.ps $tmpfile <"${infile}" 1>&2
---
> gs -q -dNOPAUSE -dSAFER -dDELAYSAFER -r72 -sDEVICE=bit
-sOutputFile=/dev/null $tmpfile ps2epsi.ps $tmpfile <${infile} 1>&2
64c64
< cat "${infile}" |
---
> cat ${infile} |
66c66
<       -e '/^%%[A-Za-z][A-Za-z]*[^!-~]*$/d' -e '/^%%[A-Za-z][A-Za-z]*:
/d'
---
> -e '/^%%[A-Za-z][A-Za-z]*[^!-~]*$/d' -e '/^%%[A-Za-z][A-Za-z]*: /d'
74c74
< ) >> "${outfile}"
---
> ) >> ${outfile}



From oliphant.travis at ieee.org  Sat Mar 15 19:28:33 2003
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Sat, 15 Mar 2003 17:28:33 -0700
Subject: [SciPy-user] xplt.eps question/problem?
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de> <3E7212C7.8050405@ieee.org> <Pine.LNX.4.51.0303150038120.27849@ptpcp2.phy.tu-dresden.de> <3E72B4D9.7040608@ieee.org> <Pine.LNX.4.51.0303151259440.30895@ptpcp2.phy.tu-dresden.de>
Message-ID: <3E73C531.2050408@ieee.org>

> 
> So anyone seeing this error hopefully can fix this by
> just adding this space...
> 
> BTW: the noepsi=1 version is (for my example) 17KB in size
> and the one with noepsi=0, i.e. the default,
> is 280KB, quite a difference!

This is interesting.  This would indicate that running the ps file 
through ghostscript is adding quite a bit of information (could be fonts 
that gist assumes are available while ghostscript doesn't take any 
chances).  I'm not sure though.

If you use noepsi=1 then does the output .eps file work for you (i.e. 
can you embed the .eps file into another document or does it fill up a 
page)?

I have not fully tracked down the purpose for running gist postscript 
through ps2epsi --- this was done by the folks from LLNL originally.

-Travis O.



From baecker at physik.tu-dresden.de  Sun Mar 16 16:31:22 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Sun, 16 Mar 2003 22:31:22 +0100 (CET)
Subject: [SciPy-user] xplt.eps question/problem?
In-Reply-To: <3E73C531.2050408@ieee.org>
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de>
 <3E7212C7.8050405@ieee.org> <Pine.LNX.4.51.0303150038120.27849@ptpcp2.phy.tu-dresden.de>
 <3E72B4D9.7040608@ieee.org> <Pine.LNX.4.51.0303151259440.30895@ptpcp2.phy.tu-dresden.de>
 <3E73C531.2050408@ieee.org>
Message-ID: <Pine.LNX.4.51.0303161256290.5042@ptpcp2.phy.tu-dresden.de>


On Sat, 15 Mar 2003, Travis Oliphant wrote:

[...]
> > BTW: the noepsi=1 version is (for my example) 17KB in size
> > and the one with noepsi=0, i.e. the default,
> > is 280KB, quite a difference!
>
> This is interesting.  This would indicate that running the ps file
> through ghostscript is adding quite a bit of information (could be fonts
> that gist assumes are available while ghostscript doesn't take any
> chances).  I'm not sure though.


According to man ps2epsi:
"
       ps2epsi  uses  gs(1)  to process a PostScript(tm) file and
       generate as output a new file which  conforms  to  Adobe's
       Encapsulated  PostScript  Interchange (EPSI) format.  EPSI
       is a special form of encapsulated PostScript  (EPS)  which
       adds  to  the  beginning  of  the  file  in  the  form  of
       PostScript comments a bitmapped version of the final  dis
       played page.  Programs which understand EPSI (usually word
       processors or DTP programs) can use this bitmap to give  a
       preview  version  on  screen  of the PostScript.  The dis
       played quality is often not very good (e.g.,  low  resolu
       tion,  no colours), but the final printed version uses the
       real PostScript, and thus has the normal PostScript  qual
       ity.

"
> If you use noepsi=1 then does the output .eps file work for you (i.e.
> can you embed the .eps file into another document or does it fill up a
> page)?

Inclusion with latex  both variants work fine.
(I will send you examples off-list)


> I have not fully tracked down the purpose for running gist postscript
> through ps2epsi --- this was done by the folks from LLNL originally.

I am not sure, but to me it does not look as being of such importance
(in the end I personally think that I'd rather
use noepsi=1 as default ...)

Arnd


From oliphant.travis at ieee.org  Mon Mar 17 00:02:31 2003
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Sun, 16 Mar 2003 22:02:31 -0700
Subject: [SciPy-user] xplt.eps question/problem?
References: <Pine.LNX.4.51.0303140749280.23214@ptpcp2.phy.tu-dresden.de> <3E7212C7.8050405@ieee.org> <Pine.LNX.4.51.0303150038120.27849@ptpcp2.phy.tu-dresden.de> <3E72B4D9.7040608@ieee.org> <Pine.LNX.4.51.0303151259440.30895@ptpcp2.phy.tu-dresden.de> <3E73C531.2050408@ieee.org> <Pine.LNX.4.51.0303161256290.5042@ptpcp2.phy.tu-dresden.de>
Message-ID: <3E7556E7.6030708@ieee.org>


baecker at physik.tu-dresden.de wrote:
> 
> On Sat, 15 Mar 2003, Travis Oliphant wrote:
> 
> [...]

> 
> I am not sure, but to me it does not look as being of such importance
> (in the end I personally think that I'd rather
> use noepsi=1 as default ...)

Thank you for this research.  I agree with you.  I would rather use 
noepsi=1 as a default.  (I think I will change it to epsi=0 as the 
default which does not use ps2epsi).

-Travis O.


> 
> Arnd
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From baecker at physik.tu-dresden.de  Mon Mar 17 06:57:58 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 12:57:58 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303140919390.17648-100000@cens.kybi>
References: <Pine.LNX.4.21.0303140919390.17648-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171250310.9603@ptpcp2.phy.tu-dresden.de>

Hi,

thank you very much for your advice.
I followed the approach to append the missing symbols to
skip_names.

So I did the following in /Lib/linalg/setup_linalg.py:
a) skip_single_routines = 1
b) further down I finally ended up with
           skip_names['fblas'].extend(\
            'drotmg drotm  srotg crotg srotmg srot csrot srotm sswap cswap
sscal cscal'\
            ' csscal scopy ccopy sdot cdotu cdotc snrm2 scnrm2 sasum
scasum'\
            '  sgemv cgemv chemv ssymv strmv ctrmv'\
            ' sgemm cgemm'.split())

A scipy.test(1) worked fine.

With fftw-devel installed also the fftw routines were
detected.
However, for a scipy.test(10) I get the following error message:

======================================================================
ERROR: bench_random (test_basic.test_irfft)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/fftpack/tests/test_basic.py",
line 410, in bench_random
    print '|%8.2f' % self.measure('FFT_irfft(x1,size)',repeat),
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
line 99, in measure
    exec code in locs,globs
  File "ScipyTestCase runner for test_irfft", line 1, in ?
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
line 151, in inverse_real_fft
    _real_fft_cache) / n
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
line 36, in _raw_fft
    wsave = init_function(n)
TypeError: an integer is required


Below is the output of
python scipy_core/scipy_distutils/system_info.py

There are some missing fields concerning fft, so should I expect
the above error ?

Many thanks,

Arnd


Output of python scipy_core/scipy_distutils/system_info.py:
===========================================================

atlas_info:
  NOT AVAILABLE

blas_info:
  FOUND:
    libraries = ['blas']
    library_dirs = ['/usr/lib']

blas_src_info:
  NOT AVAILABLE

dfftw_info:
  FOUND:
    libraries = ['drfftw', 'dfftw']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_DFFTW_H', None)]
    include_dirs = ['/usr/include']

dfftw_threads_info:
  NOT AVAILABLE

djbfft_info:
  NOT AVAILABLE

fftw_info:
  NOT AVAILABLE

fftw_threads_info:
  NOT AVAILABLE

lapack_info:
  FOUND:
    libraries = ['lapack']
    library_dirs = ['/usr/lib']


lapack_src_info:
  NOT AVAILABLE

sfftw_info:
  FOUND:
    libraries = ['srfftw', 'sfftw']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_SFFTW_H', None)]
    include_dirs = ['/usr/include']

sfftw_threads_info:
  NOT AVAILABLE

x11_info:
  FOUND:
    libraries = ['X11']
    library_dirs = ['/usr/X11R6/lib']
    include_dirs = ['/usr/X11R6/include']




From pearu at cens.ioc.ee  Mon Mar 17 07:42:16 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 14:42:16 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303171250310.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303171427310.21149-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> I followed the approach to append the missing symbols to
> skip_names.
> 
> So I did the following in /Lib/linalg/setup_linalg.py:
> a) skip_single_routines = 1
> b) further down I finally ended up with
>            skip_names['fblas'].extend(\
>             'drotmg drotm  srotg crotg srotmg srot csrot srotm sswap cswap
> sscal cscal'\
>             ' csscal scopy ccopy sdot cdotu cdotc snrm2 scnrm2 sasum
> scasum'\
>             '  sgemv cgemv chemv ssymv strmv ctrmv'\
>             ' sgemm cgemm'.split())

The same effect (in b) can be now achived by setting
  using_lapack_blas=1
in the header of Lib/linalg/setup_linalg.py. 
Let me know if it works for you.

> However, for a scipy.test(10) I get the following error message:
> 
> ======================================================================
> ERROR: bench_random (test_basic.test_irfft)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/fftpack/tests/test_basic.py",
> line 410, in bench_random
>     print '|%8.2f' % self.measure('FFT_irfft(x1,size)',repeat),

<snip>

> "/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
> line 36, in _raw_fft
>     wsave = init_function(n)
> TypeError: an integer is required

This could be a Numeric issue. What Numeric version are you using?
(I have tested fftpack benchmark tests to pass upto Numeric 22.0, I
haven't tried 23.0, yet)

> There are some missing fields concerning fft, so should I expect
> the above error ?

No.

> dfftw_info:
>   FOUND:
>     libraries = ['drfftw', 'dfftw']
>     library_dirs = ['/usr/lib']
>     define_macros = [('SCIPY_DFFTW_H', None)]
>     include_dirs = ['/usr/include']

This looks good to me. Since scipy.test(1) includes fftpack sanity tests
that all pass, then scipy.fftpack should be ok.

Thanks for your feedback,

Pearu



From baecker at physik.tu-dresden.de  Mon Mar 17 08:23:01 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 14:23:01 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303171427310.21149-100000@cens.kybi>
References: <Pine.LNX.4.21.0303171427310.21149-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171410530.9603@ptpcp2.phy.tu-dresden.de>


On Mon, 17 Mar 2003, Pearu Peterson wrote:

>
> On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:
>
> > I followed the approach to append the missing symbols to
> > skip_names.
> >
> > So I did the following in /Lib/linalg/setup_linalg.py:
> > a) skip_single_routines = 1
> > b) further down I finally ended up with
> >            skip_names['fblas'].extend(\
> >             'drotmg drotm  srotg crotg srotmg srot csrot srotm sswap cswap
> > sscal cscal'\
> >             ' csscal scopy ccopy sdot cdotu cdotc snrm2 scnrm2 sasum
> > scasum'\
> >             '  sgemv cgemv chemv ssymv strmv ctrmv'\
> >             ' sgemm cgemm'.split())
>
> The same effect (in b) can be now achived by setting
>   using_lapack_blas=1
> in the header of Lib/linalg/setup_linalg.py.
> Let me know if it works for you.

I just did a fresh checkout I get the following

======================================================================
FAIL: check_nrm2 (test_blas.test_fblas1_simple)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/tests/test_blas.py",
line 90, in check_nrm2
    assert_almost_equal(f([3,-4,5]),math.sqrt(50))
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
line 349, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
DESIRED: 7.0710678118654755
ACTUAL: 7.0710676908493042

----------------------------------------------------------------------
Hmm, the numbers are not that unequal, but still -
what do you think ?
(I haven't seen this error before...)

In any case, I should emphasize, that I just took the example
which was there before and it very well might be that
some of the "ssymv strmv ctrmv" and some others could be included,
i.e. excluded from the above list.

> > However, for a scipy.test(10) I get the following error message:
> >
> > ======================================================================
> > ERROR: bench_random (test_basic.test_irfft)
> > ----------------------------------------------------------------------
[...]
> > TypeError: an integer is required
>
> This could be a Numeric issue. What Numeric version are you using?
> (I have tested fftpack benchmark tests to pass upto Numeric 22.0, I
> haven't tried 23.0, yet)

Yep, you are right, I am using Numeric 23.0 ...

Arnd


From pearu at cens.ioc.ee  Mon Mar 17 08:48:57 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 15:48:57 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303171410530.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303171534220.21149-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> I just did a fresh checkout I get the following
> 
> ======================================================================
> FAIL: check_nrm2 (test_blas.test_fblas1_simple)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/tests/test_blas.py",
> line 90, in check_nrm2
>     assert_almost_equal(f([3,-4,5]),math.sqrt(50))
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
> line 349, in assert_almost_equal
>     assert round(abs(desired - actual),decimal) == 0, msg
> AssertionError:
> Items are not equal:
> DESIRED: 7.0710678118654755
> ACTUAL: 7.0710676908493042
> 
> ----------------------------------------------------------------------
> Hmm, the numbers are not that unequal, but still -
> what do you think ?
> (I haven't seen this error before...)

Here I get

>>> scipy.linalg.fblas.dnrm2([3,-4,5])
7.0710678118654755
>>> scipy.linalg.fblas.snrm2([3,-4,5])
7.0710678100585938

What Fortran compiler flags were used to compile the blas library? 
Note that using 3dnow instructions may cause differences in floating
point results but I never thought it would be so noticable.

> In any case, I should emphasize, that I just took the example
> which was there before and it very well might be that
> some of the "ssymv strmv ctrmv" and some others could be included,
> i.e. excluded from the above list.

If any of those symbols would be missing in the exclude list, importing
linalg would just fail. So, I think only these 'rot' routines are
missing in your blas library.

Pearu



From baecker at physik.tu-dresden.de  Mon Mar 17 08:56:00 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 14:56:00 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303171534220.21149-100000@cens.kybi>
References: <Pine.LNX.4.21.0303171534220.21149-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171453260.9603@ptpcp2.phy.tu-dresden.de>


On Mon, 17 Mar 2003, Pearu Peterson wrote:

[...]
> Here I get
>
> >>> scipy.linalg.fblas.dnrm2([3,-4,5])
> 7.0710678118654755
> >>> scipy.linalg.fblas.snrm2([3,-4,5])
> 7.0710678100585938
>

on a different machine I can confirm these numbers till the last digit ...

> What Fortran compiler flags were used to compile the blas library?
> Note that using 3dnow instructions may cause differences in floating
> point results but I never thought it would be so noticable.

well, I just use the default ones from scipy (i.e. no change).
How can I figure out the ones which are used ?
On that machine gcc3.2 is installed per default, see below -
maybe this is the reason ??

Arnd

~/INSTALL_PYTHON/scipy> gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../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 --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2

~/INSTALL_PYTHON/scipy> g77 -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../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 --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2



From pearu at cens.ioc.ee  Mon Mar 17 09:36:03 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 16:36:03 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303171453260.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303171601200.21149-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> 
> 
> On Mon, 17 Mar 2003, Pearu Peterson wrote:
> 
> [...]
> > Here I get
> >
> > >>> scipy.linalg.fblas.dnrm2([3,-4,5])
> > 7.0710678118654755
> > >>> scipy.linalg.fblas.snrm2([3,-4,5])
> > 7.0710678100585938
> >
> 
> on a different machine I can confirm these numbers till the last digit ...

That's normal for Python float.__repr__.

> > What Fortran compiler flags were used to compile the blas library?
> > Note that using 3dnow instructions may cause differences in floating
> > point results but I never thought it would be so noticable.
> 
> well, I just use the default ones from scipy (i.e. no change).
> How can I figure out the ones which are used?

scipy defaults should not affect the behaviour of prebuilt Fortran
compiled libraries. Anyway, to find out what Fortran compiler flags are
used when building scipy, execute

>>> from scipy_distutils.command.build_flib import find_fortran_compiler
>>> print find_fortran_compiler(None,None,None,verbose=0)

OTOH, my question may be irrelevant since you are using blas library
provided by Suse... you can try to build blas libraries yourself.

Pearu



From baecker at physik.tu-dresden.de  Mon Mar 17 09:44:36 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 15:44:36 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303171601200.21149-100000@cens.kybi>
References: <Pine.LNX.4.21.0303171601200.21149-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171541590.9603@ptpcp2.phy.tu-dresden.de>


On Mon, 17 Mar 2003, Pearu Peterson wrote:

[...]

> > > What Fortran compiler flags were used to compile the blas library?
> > > Note that using 3dnow instructions may cause differences in floating
> > > point results but I never thought it would be so noticable.
> >
> > well, I just use the default ones from scipy (i.e. no change).
> > How can I figure out the ones which are used?
>
> scipy defaults should not affect the behaviour of prebuilt Fortran
> compiled libraries. Anyway, to find out what Fortran compiler flags are
> used when building scipy, execute
>
> >>> from scipy_distutils.command.build_flib import find_fortran_compiler
> >>> print find_fortran_compiler(None,None,None,verbose=0)

This gives
Gnu
 version='3.2'
 F77='g77'
 F77FLAGS=' -Wall -fno-second-underscore  -fPIC '
 F77OPT=' -O3 -funroll-loops  -mmmx  -m3dnow '
 LIBS='-lg2c'

So I could try to remove the -m3dnow
(what is the best way to do this ?)
and try a full recompile, what do you think ?

> OTOH, my question may be irrelevant since you are using blas library
> provided by Suse... you can try to build blas libraries yourself.

if I really have to ;-)

Arnd


From pearu at cens.ioc.ee  Mon Mar 17 09:57:20 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 16:57:20 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303171541590.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303171648170.21149-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> 
> 
> On Mon, 17 Mar 2003, Pearu Peterson wrote:
> 
> [...]
> 
> > > > What Fortran compiler flags were used to compile the blas library?
> > > > Note that using 3dnow instructions may cause differences in floating
> > > > point results but I never thought it would be so noticable.
> > >
> > > well, I just use the default ones from scipy (i.e. no change).
> > > How can I figure out the ones which are used?
> >
> > scipy defaults should not affect the behaviour of prebuilt Fortran
> > compiled libraries. Anyway, to find out what Fortran compiler flags are
> > used when building scipy, execute
> >
> > >>> from scipy_distutils.command.build_flib import find_fortran_compiler
> > >>> print find_fortran_compiler(None,None,None,verbose=0)
> 
> This gives
> Gnu
>  version='3.2'
>  F77='g77'
>  F77FLAGS=' -Wall -fno-second-underscore  -fPIC '
>  F77OPT=' -O3 -funroll-loops  -mmmx  -m3dnow '
>  LIBS='-lg2c'
> 
> So I could try to remove the -m3dnow
> (what is the best way to do this ?)

Currently it is by commenting out

  if cpu.has_3dnow(): opt = opt + ' -m3dnow '

line in scipy_core/scipy_distutils/command/build_flib.py (look for
gnu_fortran_compiler.get_opt method).

> and try a full recompile, what do you think ?

You can try. If removing -m3dnow will fix the test failure, I'll disable
it in get_opt..

> > OTOH, my question may be irrelevant since you are using blas library
> > provided by Suse... you can try to build blas libraries yourself.
> 
> if I really have to ;-)

IMHO, it would have been the simplest approach ;-), blas is a relatively
small library.

Pearu



From baecker at physik.tu-dresden.de  Mon Mar 17 11:27:45 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 17:27:45 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303171648170.21149-100000@cens.kybi>
References: <Pine.LNX.4.21.0303171648170.21149-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171652340.9603@ptpcp2.phy.tu-dresden.de>

[...]

> You can try. If removing -m3dnow will fix the test failure, I'll disable
> it in get_opt..

Nope, this did not work.
Just to understand all this correctly:
If the problem sits in the provided blas, does this mean
that this blas spits out wrong numbers ?
  ((wishing myself back to debian ... ;-))


> > > OTOH, my question may be irrelevant since you are using blas library
> > > provided by Suse... you can try to build blas libraries yourself.
> >
> > if I really have to ;-)
>
> IMHO, it would have been the simplest approach ;-), blas is a relatively
> small library.

After the above I am tempted to  agree ;-).
((One reason for not doing so was that I did not know how I should do
that, maybe I have overlooked that in the docs on the installation ...
What I just did is the following:

  export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas
  in setup_linalg.py:
  blas_info = {} # test building BLAS from sources.

Compilation seems to work, but I did not figure out,
where the resulting blas is and how this is linked
(in particular how it is ensured that this is the right
one and not the system provided one; presently I get the same error
as before).
What am I doing wrong here ?

Sorry for bothering you with all this ...

Arnd


From pearu at cens.ioc.ee  Mon Mar 17 12:08:45 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 19:08:45 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303171652340.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303171831340.5220-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> Just to understand all this correctly:
> If the problem sits in the provided blas, does this mean
> that this blas spits out wrong numbers ?

Sorry, I am not following you here... if blas spits out wrong numbers,
then that is the problem with blas, obviously.

On the other hand, I don't know for sure if the current problem is with
this particular blas, it is just the first thing to check out (i.e. by
trying another blas).

> What I just did is the following:
> 
>   export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas
>   in setup_linalg.py:
>   blas_info = {} # test building BLAS from sources.
> 
> Compilation seems to work, but I did not figure out,
> where the resulting blas is and how this is linked

setup_linalg.py will build libblas_src.a into build/temp.linux-i686-2.2
directory and link the fblas extension module with -lblas_src.
If after export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas

  python scipy_core/scipy_distutils/system_info.py

shows that BLAS sources were found and `blas_info = {}` is set as
above, the fblas extension module fblas.so (a copy can be found in
build/lib.linux-i686-2.2/scipy/linalg) should use just built blas
routines. To be absolutely sure, see the fblas.so linking command
(there should be no -lblas) and also `ldd fblas.so` might be informative.

> (in particular how it is ensured that this is the right
> one and not the system provided one; presently I get 
> the same error as before).

Sounds like Suse blas is working exactly like netlib blas.
Can you check nrm2 with other arguments? How wrong they are?
Also, a total clean up and starting over with scipy built could
be in order. Have you tried Numeric 22.0? (I'll try later Numeric 23.0
myself.)

Pearu



From baecker at physik.tu-dresden.de  Mon Mar 17 12:28:07 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 18:28:07 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303171831340.5220-100000@cens.kybi>
References: <Pine.LNX.4.21.0303171831340.5220-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171824200.9603@ptpcp2.phy.tu-dresden.de>

> Sounds like Suse blas is working exactly like netlib blas.
> Can you check nrm2 with other arguments? How wrong they are?

Here are three more example (let me know if you need further ones):

>>> scipy.linalg.fblas.dnrm2([3,-4,10])
11.180339887498949
>>> scipy.linalg.fblas.snrm2([3,-4,10])
11.180340051651001
>>>
>>> scipy.linalg.fblas.dnrm2([-5,-4,10])
11.874342087037917
>>> scipy.linalg.fblas.snrm2([-5,-4,10])
11.87434196472168
>>>
>>> scipy.linalg.fblas.dnrm2([7,-14,10])
18.574175621006709
>>> scipy.linalg.fblas.snrm2([7,-14,10])
18.574175119400024

((As a comparison, on my debian box (with atlas) I get:
>>> scipy.linalg.fblas.dnrm2([3,-4,10])
11.180339887498949
>>> scipy.linalg.fblas.snrm2([3,-4,10])
11.180339813232422
>>>
>>> scipy.linalg.fblas.dnrm2([-5,-4,10])
11.874342087037917
>>> scipy.linalg.fblas.snrm2([-5,-4,10])
11.87434196472168
>>>
>>> scipy.linalg.fblas.dnrm2([7,-14,10])
18.574175621006709
>>> scipy.linalg.fblas.snrm2([7,-14,10])
18.574174880981445

))

> Also, a total clean up and starting over with scipy built could
> be in order. Have you tried Numeric 22.0? (I'll try later Numeric 23.0
> myself.)

at present it uses the wrong blas, I will have to check this first
and let you know about the outcome....

Arnd


From timothymobutu2002 at rediffmail.com  Mon Mar 17 12:48:18 2003
From: timothymobutu2002 at rediffmail.com (Timothy Mobutu)
Date: Mon, 17 Mar 2003 18:48:18 +0100
Subject: [SciPy-user] URGENT ASSISTANCE
Message-ID: <20030317182758.178D93EB09@www.scipy.com>











Dear  Partner, 
I am the son of the late  president of Democratic Republic Of Zaire,President Mobutu Sese Seko, ( now The Republic Of Congo, under the leadership of the son of Mr. Laurent Kabila ). I presume you are aware there is a financial dispute between my family ( THE MOBUTU ) and the present civilian Government. This is based on what they believe as bad and corrupt governance on my late father's part. May his soul rest in perfect peace.As you might have heard how a lot of my father's bank account in Switzerland and North America has been frozen.
                            
Following the above named reasons, I am soliciting for your humble and confidential assistance to take custody of twenty five Million United States Dollars  ( US$20,000,000.00 ), also to front for me in the areas of business you desire profitable.
These funds have secretly been deposited into a confidential Security firm where it can easily be withdrawn or paid to a recommended beneficiary. The funds will be released to you by the Security firm based on my recommendations on that note, you will be presented as my partner who will be fronting for me and my family in any subsequent ventures.
Myself and my mother have decided to give 18% to you if you are able to help us claim this consignment.We have also decided to give you any money spent on phone calls or travelling expenses in the course of this transaction at the end of the transaction.
Please, I need your entire support and co-operation for the success of this business ventures, your utmost confidentiality and secrecy is highly required, due to my family's present predicament.
I sincerely will appreciate your acknowledgment as soon as possible.
I am presently in the  refugee camp here in the  Netherlands under the united nations refugee camp in Netherlands and I can be reached  on my direct telephone number +31-641-910-805 for an elaborate discussion. 
Please indicate your interest by sending your telephone and fax numbers  or call me  at anytime. I sincerely will appreciate your acknowledgement as soon as possible.

Thanks,

Timothy Mobutu Sese-Seko.
  

From eric at enthought.com  Mon Mar 17 12:53:00 2003
From: eric at enthought.com (eric jones)
Date: Mon, 17 Mar 2003 11:53:00 -0600
Subject: [SciPy-user] MATLAB start-up
In-Reply-To: <Pine.LNX.4.21.0303151018530.17648-100000@cens.kybi>
Message-ID: <00b601c2ecae$10206ba0$8901a8c0@ERICDESKTOP>

> 
> On Sat, 15 Mar 2003, Prabhu Ramachandran wrote:
> 
> > >>>>> "PP" == Pearu Peterson <pearu at cens.ioc.ee> writes:
> >
> >     PP> Idea: if scipy would install modules like special, linalg,
> >     PP> fftpack etc as scipy_special, scipy_linalg, scipy_fftpack
> >     PP> (that are standalone modules that also scipy imports) then
> >     PP> e.g.  from scipy_special import k0 would be very fast. This
> >     PP> approach would float site-packages directory with packages
> >     PP> scipy_* (there are, say, 10 of such packages) but I think it
> >     PP> is worth of considering.  What do you think?
> >
> > If you are going to look at lazy importing you might want to check
out
> > the Python mega widgets.  It does some kind of lazy importing.  I
> > havent looked at it closely enough to know what it does but perhaps
it
> > would be useful to look at it.
> 
> Thanks for the hint!
> 
> The overview of a Pmw dynamic loader can be found at
> 
>   http://pmw.sourceforge.net/doc/dynamicloader.html
> 
> The three purposes of the dynamic loader are (below using scipy
instead
> of Pmw):
> 
> - to give access to all scipy classes and functions through a single
entry
>   point, `scipy`.
> - to delay the importing of the sub-modules until they are needed.
> - to allow a script using scipy to specify which version of scipy it
>   requires.
> 
> Only the first two purposes are relevant for scipy. This should make
> implementing the corresponding dynamic loader for scipy much easier.

Actually, versioning is a huge pain also.  At Scipy '02, maintaining
compatible versions of packages was one of the things people raised
their hands about when asked, "What are the roadblocks that prevent wide
adoption of Python in Science."  It would be cool to allow multiple
versions within an installation (I always wished Python supported
versioning automatically) so that people reliant on an older version of
SciPy for production code can still try out features in a newer version.
If Pmw has figured this out already, we should definitely take a look at
all three capabilities.

> 
> Notice that using the idea of scipy_xxx does not exclude using dynamic
> loader (in fact, Pmw assumes similar convention for its subpackages).
> Further on, scipy.xxx can be still made available by using
> `import scipy_xxx as xxx` in scipy/__init__.py, if scipy backforward
> compatibility is important, for instance.

The largest drawback I see with the scipy_xxx convention is that there
are multiple ways of getting to a module, and that can cause confusion.
People will be asking "Should I use scipy_linalg or scipy.linalg?" and
"What is the difference between the two?"  It's also a little messier as
far as directories, and might not be compatible with "versioning"
features that could appear in future versions of SciPy.

I'm not all that happy with the way packages work in Python, and using
them doesn't give us much more than a namespace to group the scientific
modules under.  The idea of importing "sibling" packages without
qualifying them is nice, but doesn't provide much benefit in the nested
structure of SciPy.  You can say "import linalg" from the
scipy/common.py file, but you must say "import scipy.linalg" from
scipy/common/ga/whatever.py because it doesn't recurse up the package to
search for importable modules.  As such, it isn't a useful feature.  The
long imports time for large packages is a futher problem.

Still, if the dynamic loading can be made to work reliably, doesn't it
solve the problem we're trying to address (long load times)?  And, we
are currently striving to make all modules installable as stand alone
for those who want to use them that way.  So I'm a -0 on making the
change.  If there is a path that keeps the cleaner directory structure,
avoid any confusion about import names, and get the faster loads, I
think we should explore it before making the change to scipy_xxx.

eric






From baecker at physik.tu-dresden.de  Mon Mar 17 13:32:04 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 19:32:04 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303171831340.5220-100000@cens.kybi>
References: <Pine.LNX.4.21.0303171831340.5220-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303171903480.9603@ptpcp2.phy.tu-dresden.de>

Hi Pearu,

[...]

> > What I just did is the following:
> >
> >   export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas
> >   in setup_linalg.py:
> >   blas_info = {} # test building BLAS from sources.
> >
> > Compilation seems to work, but I did not figure out,
> > where the resulting blas is and how this is linked
>
> setup_linalg.py will build libblas_src.a into build/temp.linux-i686-2.2
> directory and link the fblas extension module with -lblas_src.
> If after export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas
>
>   python scipy_core/scipy_distutils/system_info.py
>
> shows that BLAS sources were found and `blas_info = {}` is set as
> above, the fblas extension module fblas.so (a copy can be found in
> build/lib.linux-i686-2.2/scipy/linalg) should use just built blas
> routines. To be absolutely sure, see the fblas.so linking command
> (there should be no -lblas) and also `ldd fblas.so` might be informative.

I did a total clean up and build scipy again.
Using a python setup.py install | tee install.log
I found the following line involving fblas.so

g77 -shared build/temp.linux-i686-2.2/fortranobject.o
build/temp.linux-i686-2.2/fblasmodule.o -L/usr/lib
-Lbuild/temp.linux-i686-2.2 -Lbuild/temp.linux-i686-2.2 -lfblas -llapack
-lblas_src -lg2c -o build/lib.linux-i686-2.2/scipy/linalg/fblas.so

That looks alright, or ?
However,
 `ldd build/lib.linux-i686-2.2/scipy/linalg/fblas.so`
gives
        liblapack.so.3 => /usr/lib/liblapack.so.3 (0x400ac000)
        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x40607000)
        libm.so.6 => /lib/libm.so.6 (0x40626000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40649000)
        libc.so.6 => /lib/libc.so.6 (0x40651000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0x40770000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

This seems puzzling at first, but in the linker command
above, the linking to -llapack seems not necessary
(i.e. omitting this, the command still works).
But then
  `ldd build/lib.linux-i686-2.2/scipy/linalg/fblas.so`
gives
        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x4005a000)
        libm.so.6 => /lib/libm.so.6 (0x40079000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4009c000)
        libc.so.6 => /lib/libc.so.6 (0x400a4000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

I copied the resulting fblas.so to the destination directory.
scipy.test() then gives me a different error, namely

======================================================================
ERROR: check_random (test_decomp.test_qr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/tests/test
_decomp.py", line 295, in check_random
    q,r = qr(a)
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/decomp.py"
, line 359, in qr
    gemm, = get_blas_funcs(('gemm',),(qr,))
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/blas.py",
line 43, in get_blas_funcs
    if ordering and
fblas.has_column_major_storage(arrays[ordering[0][1]]):
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_distutils/misc_ut
il.py", line 44, in __getattr__
    raise self._info[0],self._info[1]
ImportError:
/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/fblas
.so: undefined symbol: wcdotu_

The same occurs for: check_random_complex,  check_simple,
check_simple_complex


However, at the end it says:
----------------------------------------------------------------------
Ran 640 tests in 6.861s

FAILED (errors=4)
<unittest.TextTestRunner instance at 0x868f04c>


So, does this really mean, that the other problem is gone ?
The above wcdotu_ errors could be related to Numeric23.0 ?

Hope you can make more sense out of all this -

Arnd




From pearu at cens.ioc.ee  Mon Mar 17 14:02:29 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 21:02:29 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303171903480.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303172036290.5220-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> I did a total clean up and build scipy again.
> Using a python setup.py install | tee install.log
> I found the following line involving fblas.so
> 
> g77 -shared build/temp.linux-i686-2.2/fortranobject.o
> build/temp.linux-i686-2.2/fblasmodule.o -L/usr/lib
> -Lbuild/temp.linux-i686-2.2 -Lbuild/temp.linux-i686-2.2 -lfblas -llapack
> -lblas_src -lg2c -o build/lib.linux-i686-2.2/scipy/linalg/fblas.so
> 
> That looks alright, or ?

Yes, but ..

> However,
>  `ldd build/lib.linux-i686-2.2/scipy/linalg/fblas.so`
> gives
>         liblapack.so.3 => /usr/lib/liblapack.so.3 (0x400ac000)
>         libg2c.so.0 => /usr/lib/libg2c.so.0 (0x40607000)
>         libm.so.6 => /lib/libm.so.6 (0x40626000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40649000)
>         libc.so.6 => /lib/libc.so.6 (0x40651000)
>         libblas.so.3 => /usr/lib/libblas.so.3 (0x40770000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

... I am surprised that /usr/lib/libblas.so.3 was picked up and as a
result, -lblas_src has no effect. It seems that libblas.so.3 is hardcoded
to /usr/lib/liblapack.so.3 some how :(. Hmm, how can then Suse (or is it
more general, Redhat) people link their programs with an optimized blas
while using system lapack library?!

> This seems puzzling at first, but in the linker command
> above, the linking to -llapack seems not necessary
> (i.e. omitting this, the command still works).
> But then
>   `ldd build/lib.linux-i686-2.2/scipy/linalg/fblas.so`
> gives
>         libg2c.so.0 => /usr/lib/libg2c.so.0 (0x4005a000)
>         libm.so.6 => /lib/libm.so.6 (0x40079000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4009c000)
>         libc.so.6 => /lib/libc.so.6 (0x400a4000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

This looks better.

> I copied the resulting fblas.so to the destination directory.
> scipy.test() then gives me a different error, namely
> 
> ======================================================================
> ERROR: check_random (test_decomp.test_qr)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
<snip>
> ImportError:
> /home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/fblas
> .so: undefined symbol: wcdotu_
> 
> The same occurs for: check_random_complex,  check_simple,
> check_simple_complex

It seems that build/lib.linux-i686-2.2/scipy/linalg/fblas.so was not
copied to /home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg.

> So, does this really mean, that the other problem is gone ?

Not yet.

> The above wcdotu_ errors could be related to Numeric23.0 ?

No, I don't think so. Check that wcdotu.f is compiled and wcdotu_ is
defined in fblas.so (use `nm fblas.so`). Also check that fblas.so
is copied to
/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg.

> Hope you can make more sense out of all this -

This libblas.so.3 issue was unexpected. Make sure that you can import
fblas.so (that is not linked against the system blas) to python and
then rerun tests. What happens?

Pearu



From baecker at physik.tu-dresden.de  Mon Mar 17 14:41:20 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 20:41:20 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303172036290.5220-100000@cens.kybi>
References: <Pine.LNX.4.21.0303172036290.5220-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303172018140.9603@ptpcp2.phy.tu-dresden.de>

(the main point might be the one at the end of this mail...)

On Mon, 17 Mar 2003, Pearu Peterson wrote:

[...]

> It seems that build/lib.linux-i686-2.2/scipy/linalg/fblas.so was not
> copied to /home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg.

Actually, that's what I did:
cp build/lib.linux-i686-2.2/scipy/linalg/fblas.so
/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/


[...]
> No, I don't think so. Check that wcdotu.f is compiled and wcdotu_ is
> defined in fblas.so (use `nm fblas.so`).

I cannot find (in my install.log) that wcdotu.f is compiled anywhere.

The corresponding section of `nm fblas.so` is
00047d50 d two.5
         U wcdotc_
         U wcdotu_
         U wzdotc_
         U wzdotu_
00024be0 T xerbla_


> Also check that fblas.so
> is copied to
> /home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg.
>
> > Hope you can make more sense out of all this -
>
> This libblas.so.3 issue was unexpected. Make sure that you can import
> fblas.so (that is not linked against the system blas) to python and
> then rerun tests. What happens?

>>> import fblas.so
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./fblas.so: undefined symbol: wcdotu_
>>>


Where should I find this wcdotu.f ?
Namely an `ls -R` in my scipy install directory did not show such file ?
And the blas I have has the following:
ls ../blas/*dot*
  ../blas/cdotc.f  ../blas/ddot.f   ../blas/sdot.f    ../blas/zdotc.f
  ../blas/cdotu.f  ../blas/dsdot.f  ../blas/sdsdot.f  ../blas/zdotu.f
>From these the following appear in build/temp.linux-i686-2.2
  cdotc.o cdotu.o ddot.o sdot.o zdotc.o zdotu.o


Arnd


From pearu at cens.ioc.ee  Mon Mar 17 14:53:57 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 21:53:57 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303172018140.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303172149320.5220-100000@cens.kybi>

On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> On Mon, 17 Mar 2003, Pearu Peterson wrote:
> 
> > No, I don't think so. Check that wcdotu.f is compiled and wcdotu_ is
> > defined in fblas.so (use `nm fblas.so`).
> 
> I cannot find (in my install.log) that wcdotu.f is compiled anywhere.

wcdotu* symbols are actually defined in linalg/src/fblaswrap.f and
fblaswrap.f was not added to the list of fortran sources. I just fixed it
in CVS. update and try again.

Sorry for creating a confusion,
	Pearu



From wagner.nils at vdi.de  Mon Mar 17 15:37:34 2003
From: wagner.nils at vdi.de (Nils Wagner)
Date: Mon, 17 Mar 2003 21:37:34 +0100
Subject: [SciPy-user] Problems during build
Message-ID: <20030317211727.210A83EB09@www.scipy.com>

Hi all, 
 
I tried to build scipy on SuSE8.1 via latest cvs. 
python setup.py build failed with the following message 
 
In file included from 
/home/nwagner/cvs/scipy/Lib/xplt/src/play/unix/dir.c:16: 
/home/nwagner/cvs/scipy/Lib/xplt/src/play/unix/config.h:1: parse 
error before '<<' token 
error: command 'gcc' failed with exit status 1 
nwagner at linux:~/cvs/scipy> 
 
Any idea ? 
 
Nils 
 
Python 2.2.1 (#1, Sep 10 2002, 17:49:17) 
[GCC 3.2] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> 
 
 


From baecker at physik.tu-dresden.de  Mon Mar 17 15:45:04 2003
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Mon, 17 Mar 2003 21:45:04 +0100 (CET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.21.0303172149320.5220-100000@cens.kybi>
References: <Pine.LNX.4.21.0303172149320.5220-100000@cens.kybi>
Message-ID: <Pine.LNX.4.51.0303172101060.9603@ptpcp2.phy.tu-dresden.de>

On Mon, 17 Mar 2003, Pearu Peterson wrote:

[...]
> wcdotu* symbols are actually defined in linalg/src/fblaswrap.f and
> fblaswrap.f was not added to the list of fortran sources. I just fixed it
> in CVS. update and try again.
>
> Sorry for creating a confusion,

no problem, it seems we are getting closer (well, to the start, I fear):

 - I did a fresh start again.
 - again (of course) fblas.so contains the link to /usr/libblas.so
   because of the -llapack

   Therefore by hand  (the following is just one line)
   g77 -shared build/temp.linux-i686-2.2/fortranobject.o
build/temp.linux-i686-2.2/fblasmodule.o -L/usr/lib
-Lbuild/temp.linux-i686-2.2 -Lbuild/temp.linux-i686-2.2 -lfblas -lblas_src
-lg2c -o build/lib.linux-i686-2.2/scipy/linalg/fblas.so

  and (again one line)
  cp build/lib.linux-i686-2.2/scipy/linalg/fblas.so
  ~/PYTHON/lib/python2.2/site-packages/scipy/linalg
- import fblas works without error
- scipy.test(1) gives

======================================================================
FAIL: check_nrm2 (test_blas.test_fblas1_simple)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/tests/test_blas.py",
line 90, in check_nrm2
    assert_almost_equal(f([3,-4,5]),math.sqrt(50))
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
line 349, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
DESIRED: 7.0710678118654755
ACTUAL : 7.0710676908493042

BTW: How many digits agreement should one really expect here ?

I double-checked that fblas.o does not contain a reference
to the system blas,  `ldd fblas.so`
        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x4005b000)
        libm.so.6 => /lib/libm.so.6 (0x4007a000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4009d000)
        libc.so.6 => /lib/libc.so.6 (0x400a5000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

However, should I be worried about the following ones
contain reference to /usr/lib/libblas.so.3
~/PYTHON/lib/python2.2/site-packages/scipy/linalg> ldd _flinalg.so
        liblapack.so.3 => /usr/lib/liblapack.so.3 (0x40088000)
        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x405e3000)
        libm.so.6 => /lib/libm.so.6 (0x40602000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40625000)
        libc.so.6 => /lib/libc.so.6 (0x4062d000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0x4074c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
~/PYTHON/lib/python2.2/site-packages/scipy/linalg> ldd calc_lwork.so
        liblapack.so.3 => /usr/lib/liblapack.so.3 (0x40087000)
        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x405e2000)
        libm.so.6 => /lib/libm.so.6 (0x40601000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40624000)
        libc.so.6 => /lib/libc.so.6 (0x4062c000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0x4074b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

(If I had root rights on this machine I would just move
the blas in /usr/lib, but I can't do this ...)

So, what's next ?

Arnd


From pearu at cens.ioc.ee  Mon Mar 17 16:35:54 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 17 Mar 2003 23:35:54 +0200 (EET)
Subject: [SciPy-user] Problems during build
In-Reply-To: <20030317211727.210A83EB09@www.scipy.com>
Message-ID: <Pine.LNX.4.21.0303172334050.5220-100000@cens.kybi>

On Mon, 17 Mar 2003, Nils Wagner wrote:

> I tried to build scipy on SuSE8.1 via latest cvs. 
> python setup.py build failed with the following message 
>  
> In file included from 
> /home/nwagner/cvs/scipy/Lib/xplt/src/play/unix/dir.c:16: 
> /home/nwagner/cvs/scipy/Lib/xplt/src/play/unix/config.h:1: parse 
> error before '<<' token 
> error: command 'gcc' failed with exit status 1 
> nwagner at linux:~/cvs/scipy> 
>  
> Any idea ? 

Remove /home/nwagner/cvs/scipy/Lib/xplt/src/play/unix/config.h
and do cvs update again. That should fix the failure for now.

Pearu



From pearu at cens.ioc.ee  Mon Mar 17 17:29:03 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 18 Mar 2003 00:29:03 +0200 (EET)
Subject: [SciPy-user] installation on Suse8.1 (blas problem)
In-Reply-To: <Pine.LNX.4.51.0303172101060.9603@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303180002470.5220-100000@cens.kybi>


On Mon, 17 Mar 2003 baecker at physik.tu-dresden.de wrote:

> ======================================================================
> FAIL: check_nrm2 (test_blas.test_fblas1_simple)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/tests/test_blas.py",
> line 90, in check_nrm2
>     assert_almost_equal(f([3,-4,5]),math.sqrt(50))
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
> line 349, in assert_almost_equal
>     assert round(abs(desired - actual),decimal) == 0, msg
> AssertionError:
> Items are not equal:
> DESIRED: 7.0710678118654755
> ACTUAL : 7.0710676908493042
> 
> BTW: How many digits agreement should one really expect here ?

I was able produce the same result with netlib blas. Earlier I used
atlas blas and that gave more accurate result for single precision
nrm2. assert_almost_equal assumes that 7 digits are correct and
the values of DESIRED and ACTUAL confirm that. However, further
calculation in assert_almost_equal produces additional numerical 
errors:
 
>>> round((7.0710678118654755-7.0710676908493042),7)
9.9999999999999995e-08
>>> round((7.0710678118654755-7.0710676908493042),6)
0.0

and cause the test to fail.

> So, what's next ?

In conclusion, it safe to ignore the nrm2 test failure. We just need a
better method to check matching decimals in assert_almost_equal function.

Pearu



From Kasper.Souren at ircam.fr  Mon Mar 17 18:49:40 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 17 Mar 2003 23:49:40 +0000
Subject: [SciPy-user] compilation problem: specfun.f
In-Reply-To: <Pine.LNX.4.21.0303101956470.22412-100000@cens.kybi>
References: <Pine.LNX.4.21.0303101956470.22412-100000@cens.kybi>
Message-ID: <200303172349.41544.Kasper.Souren@ircam.fr>

I'd like to add something to this thread.

I had some troubles with Python being compiled with the -mpentium4 flag. int() 
was acting really strange (int(n) == 0 for n == whole number and floats gave 
me even weirder results). A recompile using -mpentium3 fixed this. So if 
someone with a Pentium 4 is getting really strange results with SciPy it 
might be because of the -mpentium4 flag for g77...

bye,
Kasper


From Kasper.Souren at ircam.fr  Mon Mar 17 18:58:45 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Mon, 17 Mar 2003 23:58:45 +0000
Subject: [SciPy-user] some more cvs compile troubles.. config.h
Message-ID: <200303172358.45912.Kasper.Souren@ircam.fr>

Hi,

"python setup.py build" ends here on my Gentoo system:

gcc -DNDEBUG -fPIC -I/home/guaka/cvs/scipy/Lib/xplt/src/gist 
-I/home/guaka/cvs/scipy/Lib/xplt/src/play 
-I/home/guaka/cvs/scipy/Lib/xplt/src/play/unix -I/usr/include/python2.2 -c 
/home/guaka/cvs/scipy/Lib/xplt/src/play/unix/dir.c -o 
build/temp.linux-i686-2.2/dir.o 
-DGISTPATH="/usr/lib/python2.2/site-packages/scipy/xplt/gistdata"
In file included from /home/guaka/cvs/scipy/Lib/xplt/src/play/unix/dir.c:16:
/home/guaka/cvs/scipy/Lib/xplt/src/play/unix/config.h:1: parse error before 
'<<' token

Putting "//" in of line 1 of config.h fixed it.

bye,
Kasper


From pearu at cens.ioc.ee  Tue Mar 18 02:36:56 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 18 Mar 2003 09:36:56 +0200 (EET)
Subject: [SciPy-user] some more cvs compile troubles.. config.h
In-Reply-To: <200303172358.45912.Kasper.Souren@ircam.fr>
Message-ID: <Pine.LNX.4.21.0303180901120.5220-100000@cens.kybi>

On Mon, 17 Mar 2003, Kasper Souren wrote:

> "python setup.py build" ends here on my Gentoo system:
> 
> gcc -DNDEBUG -fPIC -I/home/guaka/cvs/scipy/Lib/xplt/src/gist 
> -I/home/guaka/cvs/scipy/Lib/xplt/src/play 
> -I/home/guaka/cvs/scipy/Lib/xplt/src/play/unix -I/usr/include/python2.2 -c 
> /home/guaka/cvs/scipy/Lib/xplt/src/play/unix/dir.c -o 
> build/temp.linux-i686-2.2/dir.o 
> -DGISTPATH="/usr/lib/python2.2/site-packages/scipy/xplt/gistdata"
> In file included from /home/guaka/cvs/scipy/Lib/xplt/src/play/unix/dir.c:16:
> /home/guaka/cvs/scipy/Lib/xplt/src/play/unix/config.h:1: parse error before 
> '<<' token
> 
> Putting "//" in of line 1 of config.h fixed it.

To state the obvious, this config.h issue must be fixed by removing
system dependent config.h from CVS because whenever user system updates
config.h, it will be in conflict with the CVS version of config.h; and
further execution of `cvs update` will break the local config.h by
inserting to it diffs of conflicting files.

However, it is not clear where should config.h be created. The first
approach of creating it in the source tree (as it is done now) makes it
impossible to use the same scipy CVS tree for building xplt on different
platforms, unless an user knows to remove the following files
  xplt/pygist/Make.cfg
  xplt/src/play/unix/config.h
whenever switching platforms.

(Temporary) solution proposal:
First, remove config.h from CVS. Second, in local CVS tree remove 
    Lib/xplt/pygist/Make.cfg
    Lib/xplt/src/play/unix/config.h
Final note: when setup_xplt.py is called, these files are
regenerated; whenever switching platforms, remember to remove the two
files again.

Until config.h is removed from CVS, use the following instructions
after each action that changes config.h file:
- `cvs update` or "switching platforms"
- remove file
   Lib/xplt/pygist/Make.cfg
- build/install scipy

PS: the above applies only to unix systems, of course.

Pearu



From Kasper.Souren at ircam.fr  Tue Mar 18 05:44:48 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Tue, 18 Mar 2003 10:44:48 +0000
Subject: [SciPy-user] some more cvs compile troubles.. config.h
In-Reply-To: <Pine.LNX.4.21.0303180901120.5220-100000@cens.kybi>
References: <Pine.LNX.4.21.0303180901120.5220-100000@cens.kybi>
Message-ID: <200303181044.49065.Kasper.Souren@ircam.fr>

> (Temporary) solution proposal:
> First, remove config.h from CVS. Second, in local CVS tree remove
>     Lib/xplt/pygist/Make.cfg
>     Lib/xplt/src/play/unix/config.h
> Final note: when setup_xplt.py is called, these files are
> regenerated; whenever switching platforms, remember to remove the two
> files again.

Can't they be removed by "python setup.py clean"? That would be a clean 
solution I guess. Or setup_xplt.py could be forced to regenerate them.

bye,
Kasper


From baecker at physik.tu-dresden.de  Tue Mar 18 05:17:22 2003
From: baecker at physik.tu-dresden.de (Arnd Baecker)
Date: Tue, 18 Mar 2003 11:17:22 +0100 (CET)
Subject: [SciPy-user] inst. Suse8.1 - irfft error
Message-ID: <Pine.LNX.4.51.0303181035490.17776@ptpcp2.phy.tu-dresden.de>

Hi,

after the nrm2 issue is "resolved" I did a fresh checkout and install,
this time with Numeric22.0.

With scpipy.test(10) I get

======================================================================
ERROR: bench_random (test_basic.test_irfft)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/fftpack/tests/test_basic.py",
line 410, in bench_random
    print '|%8.2f' % self.measure('FFT_irfft(x1,size)',repeat),
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
line 99, in measure
    exec code in locs,globs
  File "ScipyTestCase runner for test_irfft", line 1, in ?
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
line 151, in inverse_real_fft
    _real_fft_cache) / n
  File
"/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
line 36, in _raw_fft
    wsave = init_function(n)
TypeError: an integer is required


Unless I messed up things, this problem occurs both with
Numeric22.0 and Numeric23.0.


((I cannot compare this with my debian installation
as there I get for scipy.test(1)
"[...]
cc.bisect :    1.0000000000001952
cc.ridder :    1.0000000000002143
cc.brenth :    1.0000000000006635
cc.brentq :    1.0000000000006601

.zsh: 14281 segmentation fault  python
"

And I don't know where to look ...  any clues on this as well ?
))

Many thanks,

Arnd


From baecker at physik.tu-dresden.de  Tue Mar 18 07:48:46 2003
From: baecker at physik.tu-dresden.de (Arnd Baecker)
Date: Tue, 18 Mar 2003 13:48:46 +0100 (CET)
Subject: [SciPy-user] fftpack seg-fault with scipy.test(1)
Message-ID: <Pine.LNX.4.51.0303181344580.17776@ptpcp2.phy.tu-dresden.de>

Hi,

referring to my previous questions on a seg-fault with
scipy.test(1) on a debian machine I tried to get more precise information:

To do this I hacked the class TestResult in unittest.py,
and changed this as follows.

    def startTest(self, test):
        "Called when the given test is about to be run"
        print "run"
        print test
        self.testsRun = self.testsRun + 1

    def stopTest(self, test):
        "Called when the given test has been run"
        print "ran"
        print test
        pass

This allows to properly see where the problem is-
in my case this givs
  [...]
  run
  check_definition (test_basic.test_fft)
  zsh: 14604 segmentation fault  python

Alright, changing to
   ~/PYTHON/lib/python2.2/site-packages/scipy/fftpack/tests
and running
   python test_basic.py

Gives:
run
check_definition (__main__.test_fft)
.ran
check_definition (__main__.test_fft)
run
check_djbfft (__main__.test_fft)
2
ok1
ok2
ok3
3
ok1
ok2
ok3
4
zsh: 14911 segmentation fault  python test_basic.py

The numbers: 2,3,4 and ok1, ok2 and ok3 come
from the following change in test_basic.py to

    def check_djbfft(self):
        try:
            from FFT import fft as fft2
        except ImportError:
            print 'Skipping check_djbfft (failed to import FFT)'
            return
        for i in range(2,14):
            print i
            n = 2**i
            x = range(n)
            y = fftpack.zfft(x)
            print "ok1"
            y2 = fft2(x)
            print "ok2"
            assert_array_almost_equal(y,y2)
            y = fftpack.zrfft(x)
            print "ok3"
            assert_array_almost_equal(y,y2)

Interestingly, my system_info (see below) output says
  djbfft_info:
    NOT AVAILABLE


I think that's all I can say on this, maybe someone else has a clue ?

Arnd





python scipy_core/scipy_distutils/system_info.py
atlas_info:
  FOUND:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/lib/atlas', '/usr/lib']
    include_dirs = ['/usr/include']

blas_info:
  FOUND:
    libraries = ['blas']
    library_dirs = ['/usr/lib']

blas_src_info:
  NOT AVAILABLE

dfftw_info:
  NOT AVAILABLE

dfftw_threads_info:
  NOT AVAILABLE

djbfft_info:
  NOT AVAILABLE

fftw_info:
  FOUND:
    libraries = ['rfftw', 'fftw']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_FFTW_H', None)]
    include_dirs = ['/usr/include']

fftw_threads_info:
  FOUND:
    libraries = ['rfftw_threads', 'fftw_threads']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_FFTW_THREADS_H', None)]
    include_dirs = ['/usr/include']

lapack_info:
  FOUND:
    libraries = ['lapack']
    library_dirs = ['/usr/lib']

lapack_src_info:
  NOT AVAILABLE

sfftw_info:
  FOUND:
    libraries = ['srfftw', 'sfftw']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_SFFTW_H', None)]
    include_dirs = ['/usr/include']

sfftw_threads_info:
  FOUND:
    libraries = ['srfftw_threads', 'sfftw_threads']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_SFFTW_THREADS_H', None)]
    include_dirs = ['/usr/include']


x11_info:
  FOUND:
    libraries = ['X11']
    library_dirs = ['/usr/X11R6/lib']
    include_dirs = ['/usr/X11R6/include']






From pearu at cens.ioc.ee  Tue Mar 18 11:59:23 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 18 Mar 2003 18:59:23 +0200 (EET)
Subject: [SciPy-user] inst. Suse8.1 - irfft error
In-Reply-To: <Pine.LNX.4.51.0303181035490.17776@ptpcp2.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.21.0303181851180.10627-100000@cens.kybi>

On Tue, 18 Mar 2003, Arnd Baecker wrote:

> after the nrm2 issue is "resolved" I did a fresh checkout and install,
> this time with Numeric22.0.
> 
> With scpipy.test(10) I get
> 
> ======================================================================
> ERROR: bench_random (test_basic.test_irfft)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/fftpack/tests/test_basic.py",
> line 410, in bench_random
>     print '|%8.2f' % self.measure('FFT_irfft(x1,size)',repeat),
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_test/testing.py",
> line 99, in measure
>     exec code in locs,globs
>   File "ScipyTestCase runner for test_irfft", line 1, in ?
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
> line 151, in inverse_real_fft
>     _real_fft_cache) / n
>   File
> "/home/baecker/PYTHON/lib/python2.2/site-packages/Numeric/FFT/FFT.py",
> line 36, in _raw_fft
>     wsave = init_function(n)
> TypeError: an integer is required
> 
> Unless I messed up things, this problem occurs both with
> Numeric22.0 and Numeric23.0.

Can you use FFT from Numeric directly? Is FFT.inverse_real_fft working
properly?
If yes, could you determine what is the value of `n` that causes
TypeError?


> 
> ((I cannot compare this with my debian installation
> as there I get for scipy.test(1)
> "[...]
> cc.bisect :    1.0000000000001952
> cc.ridder :    1.0000000000002143
> cc.brenth :    1.0000000000006635
> cc.brentq :    1.0000000000006601
> 
> .zsh: 14281 segmentation fault  python
> "
> 
> And I don't know where to look ...  any clues on this as well ?

Sometimes switching between Numeric versions may cause segmentation
faults. It seems that this is due to distutils that does not install
Numeric header files properly. So, check that Numeric header files
in <prefix>/include/python2.2/Numeric correspond to the ones of that
Numeric version that you are using.

Pearu



From falted at openlc.org  Tue Mar 18 15:46:04 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue, 18 Mar 2003 21:46:04 +0100
Subject: [SciPy-user] ANNOUNCE: Pytables 0.4
Message-ID: <200303182146.04307.falted@openlc.org>

Announcing PyTables 0.4
-----------------------

I'm happy to announce the first beta release of PyTables. It is labelled
beta because it has been thoroughly tested, even in production environments,
and it is getting fairly mature.

Besides, from now on, the API will remain mostly stable, so you can start
using PyTables now with the guarantee that your code will also work (well,
mostly ;-) in the future. The large amount of unit tests included in
PyTables will also ensure the backward compatibility as well as the quality
of future releases will remain at least as good as it is now (although
hopefully it should increase!).

What's new
-----------

- numarray objects (NumArray, CharArray and RecArray) supported

- As a consequence of a large internal code redesign (numarray is at
  the core of PyTables now), performance has been improved by a factor
  of 10 (see "How Fast Is It?" section)

- It consumes far less memory than previous version

- Support for reading generic HDF5 files added (!)

- Some bugs and memory leaks existing in 0.2 solved

- Updated documentation

- Added more unit tests (more than 200 now!)

What it is
----------

In short, PyTables provides a powerful and very Pythonic interface to
process table and array data.

Its goal is to enable the end user to manipulate easily scientific
data tables and Numerical and numarray Python objects in a persistent
hierarchical structure. The foundation of the underlying hierarchical
data organization is the excellent HDF5 library
(http://hdf.ncsa.uiuc.edu/HDF5).

A table is defined as a collection of records whose values are stored
in fixed-length fields. All records have the same structure and all
values in each field have the same data type.  The terms
"fixed-length" and strict "data types" seems to be quite a strange
requirement for an interpreted language like Python, but they serve a
useful function if the goal is to save very large quantities of data
(such as is generated by many scientific applications, for example) in
an efficient manner that reduces demand on CPU time and I/O resources.

Quite a bit effort has been invested to make browsing the hierarchical
data structure a pleasant experience. PyTables implements just two
(orthogonal) easy-to-use methods for browsing.

What is HDF5?
-------------

For those people who know nothing about HDF5, it is is a general
purpose library and file format for storing scientific data made at
NCSA. HDF5 can store two primary objects: datasets and groups. A
dataset is essentially a multidimensional array of data elements, and
a group is a structure for organizing objects in an HDF5 file. Using
these two basic constructs, one can create and store almost any kind of
scientific data structure, such as images, arrays of vectors, and
structured and unstructured grids. You can also mix and match them in
HDF5 files according to your needs.

How fast is it?
---------------

PyTables can write table records between 20 and 30 times faster than
cPickle and between 3 and 10 times faster than struct (it is a module
present in the Standard Library); and retrieves information around 100
times faster than cPickle and between 8 and 10 times faster than
struct.

When compared with SQLite (http://www.sqlite.org/), one of the fastest
(free) relational databases available, PyTables achieves between a 60%
and 80% the speed of SQLite during selects of dataset sizes that fit
in the O.S. filesystem memory cache. However, when those sizes does
not fit in the cache (i.e. when dealing with large amounts of data),
PyTables beats SQLite by a factor of 2 or even more (depending on the
kind of record selected), and its performance in this case is only
limited by the I/O speed of the disk subsystem.

Go to http://pytables.sourceforge.net/doc/PyCon.html#section4 for a
detailed description on the conducted benchmarks.

Platforms
---------

I'm using Linux as the main development platform, but PyTables should
be easy to compile/install on other UNIX machines. This package has
also passed all the tests on a UltraSparc platform with Solaris 7 and
Solaris 8. It also compiles and passes all the tests on a SGI
Origin2000 with MIPS R12000 processors and running IRIX 6.5.

If you are using Windows and you get the library to work, please let
me know.

An example?
-----------

At the bottom of this message there is some code that shows basic
capabilities of PyTables. You may also look at
http://pytables.sourceforge.net/tut/tutorial1-1.html and 
http://pytables.sourceforge.net/tut/tutorial1-2.html
for online code.

Web site
--------

Go to the PyTables web site for downloading and more details:

http://pytables.sf.net/

Share your experience
---------------------

Let me know of any bugs, suggestions, gripes, kudos, etc. you may
have.

Have fun!

-- Francesc Alted
falted at openlc.org


*-*-*-**-*-*-**-*-*-**-*-*- Small code example  *-*-*-**-*-*-**-*-*-**-*-*-*
from tables import *

class Particle(IsDescription):
    identity = Col("CharType", 22, " ", pos = 0)  # character String
    idnumber = Col("Int16", 1, pos = 1)  # short integer
    speed = Col("Float32", 1, pos = 1)  # single-precision

# Open a file in "w"rite mode
fileh = openFile("objecttree.h5", mode = "w")
# Get the HDF5 root group
root = fileh.root

# Create the groups:
group1 = fileh.createGroup(root, "group1")
group2 = fileh.createGroup(root, "group2")

# Now, create a table in "group0" group
array1 = fileh.createArray(root, "array1", ["string", "array"], "String 
array")
# Create 2 new tables in group1
table1 = fileh.createTable(group1, "table1", Particle)
table2 = fileh.createTable("/group2", "table2", Particle)
# Create the last table in group2
array2 = fileh.createArray("/group1", "array2", [1,2,3,4])

# Now, fill the tables:
for table in (table1, table2):
    # Get the record object associated with the table:
    row = table.row
    # Fill the table with 10 records
    for i in xrange(10):
        # First, assign the values to the Particle record
        row['identity']  = 'This is particle: %2d' % (i)
        row['idnumber'] = i
        row['speed']  = i * 2.
        # This injects the Record values
        row.append()

    # Flush the table buffers
    table.flush()

# Select actual data from table.
# on entries where TDCcount field is greater than 3 and pressure less than 50
out = [ x['identity'] for x in table.iterrows()
        if x['idnumber'] > 3 and 4 < x['speed'] < 10 ]

print out

# Finally, close the file (this also will flush all the remaining buffers!)
fileh.close()


From lanceboyle at myrealbox.com  Tue Mar 18 23:38:25 2003
From: lanceboyle at myrealbox.com (Lance Boyle)
Date: Tue, 18 Mar 2003 21:38:25 -0700
Subject: [SciPy-user] SciPy on OS X 10.2.4
Message-ID: <9FC29712-59C4-11D7-98BA-003065F93FF0@myrealbox.com>

Does SciPy install and function correctly on Mac OS X 10.2.4?
Using fink?

Jerry



From boonstb at cmg.FCNBD.COM  Fri Mar 21 10:04:45 2003
From: boonstb at cmg.FCNBD.COM (Brian Boonstra)
Date: Fri, 21 Mar 2003 09:04:45 -0600
Subject: [SciPy-user] SciPy on OS X 10.2.4
In-Reply-To: <9FC29712-59C4-11D7-98BA-003065F93FF0@myrealbox.com>
References: <9FC29712-59C4-11D7-98BA-003065F93FF0@myrealbox.com>
Message-ID: <200303211504.JAA23331@wo1203.cmg.FCNBD.COM>

It worked fine for me, but I only played with cow.

> Does SciPy install and function correctly on Mac OS X 10.2.4?
> Using fink?


From jerry at bauck.net  Fri Mar 21 18:58:45 2003
From: jerry at bauck.net (Jerry Bauck)
Date: Fri, 21 Mar 2003 16:58:45 -0700
Subject: [SciPy-user] SciPy on OS X 10.2.4
In-Reply-To: <200303211504.JAA23331@wo1203.cmg.FCNBD.COM>
Message-ID: <0D15A436-5BF9-11D7-906F-003065F93FF0@bauck.net>

I've installed it and am able to import, but haven't tried yet to get 
anything useful done with it. I had to learn of the "two-Python" Mac 
system right now, and where to put it inside the "framework-build" 
folder (site-packages, of course).

Right now I'm fighting with getting Chaco installed. Listers on 
SciPy-Chaco are being helpful, but there may be a problem with the 
installation, since the Linux side seems to be having the same problem 
as I am.

Jerry


> It worked fine for me, but I only played with cow.
>
>> Does SciPy install and function correctly on Mac OS X 10.2.4?
>> Using fink?
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>



From lanceboyle at myrealbox.com  Tue Mar 25 05:34:41 2003
From: lanceboyle at myrealbox.com (Lance Boyle)
Date: Tue, 25 Mar 2003 03:34:41 -0700
Subject: [SciPy-user] Where are the filtering tutorials?
Message-ID: <63177564-5EAD-11D7-89B8-003065F93FF0@myrealbox.com>

Does anyone know where the filtering tutorials are?

http://www.scipy.org/site_content/tutorials/ 
show_doc?input_file=node25.html

Jerry



From oliphant.travis at ieee.org  Tue Mar 25 14:20:17 2003
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Tue, 25 Mar 2003 12:20:17 -0700
Subject: [SciPy-user] Where are the filtering tutorials?
References: <63177564-5EAD-11D7-89B8-003065F93FF0@myrealbox.com>
Message-ID: <3E80ABF1.8080107@ieee.org>


Lance Boyle wrote:

> Does anyone know where the filtering tutorials are?
>
> http://www.scipy.org/site_content/tutorials/ 
> show_doc?input_file=node25.html 


The best place to look is the CVS tree under tutorials.

You can browse the CVS tree and look for *.lyx files (the tutorials are 
written in .lyx)

You can install .lyx for most platforms (even Windows---though it's a 
bit tedious but should get easier in the future) and it's freely available.

You can also use the help system

help(signal)

or

scipy.info(signal)

Most of the functions should have documentation strings.

What kind of filtering are you looking for and maybe I can point you 
down the right direction?

-Travis O.




From stephen.walton at csun.edu  Tue Mar 25 19:58:20 2003
From: stephen.walton at csun.edu (Stephen Walton)
Date: 25 Mar 2003 16:58:20 -0800
Subject: [SciPy-user] scipy.test output errors
Message-ID: <1048640306.1286.26.camel@dhcppc1>

I just built SciPy on our new RedHat 8.0 servers.  I'm using Absoft
Fortran 6.0 (which means Absoft f77 V4.6) and the previously reported
underscore problem is fixed, thanks!  I built CVS (1, 196, 1591, 4120)
using ATLAS 3.4.1, FFTW 2.1.5, F2PY 2.32, Numeric-22.0.

scipy.test(level=1) gives three errors.  I've attached its output below
my signature.

BTW, I've been using the 'checkinstall' package to monitor installation
of software on my systems with great success.  It doesn't quite work
with scipy because there are a few files included with both it and F2PY.

-- 
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
stephen.walton at csun.edu
Script started on Tue Mar 25 16:04:35 2003
hale:~> python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30) 
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
>>> scipy.test(level=1)
No test suite found for  scipy.__cvs_version__
 creating test suite for: scipy.common
No test suite found for  scipy.helpmod
No test suite found for  scipy.pilutil
No test suite found for  scipy.cow
No test suite found for  scipy.fftpack.__cvs_version__
 creating test suite for: scipy.fftpack.basic
No test suite found for  scipy.fftpack.fftpack_version
 creating test suite for: scipy.fftpack.helper
 creating test suite for: scipy.fftpack.pseudo_diffs
No test suite found for  scipy.fftpack.pre___init__
No test suite found for  scipy.ga
No test suite found for  scipy.integrate
No test suite found for  scipy.interpolate
 creating test suite for: scipy.io.array_import
No test suite found for  scipy.io.data_store
No test suite found for  scipy.io.dumb_shelve
No test suite found for  scipy.io.dumbdbm_patched
No test suite found for  scipy.io.mio
No test suite found for  scipy.io.pickler
No test suite found for  scipy.io.pre___init__
No test suite found for  scipy.linalg.__cvs_version__
 creating test suite for: scipy.linalg.basic
 creating test suite for: scipy.linalg.blas
 creating test suite for: scipy.linalg.decomp
No test suite found for  scipy.linalg.flinalg
No test suite found for  scipy.linalg.interface_gen
 creating test suite for: scipy.linalg.lapack
No test suite found for  scipy.linalg.linalg_version
 creating test suite for: scipy.linalg.matfuncs
   !! FAILURE building test for  scipy.linalg.matfuncs
    <string>:1: ImportError: No module named test_matfuncs (in ?)
No test suite found for  scipy.linalg.pre___init__
No test suite found for  anneal
No test suite found for  scipy.optimize.common_routines
No test suite found for  scipy.optimize.minpack
No test suite found for  scipy.optimize.optimize
 creating test suite for: scipy.optimize.zeros
No test suite found for  scipy.optimize.pre___init__
No test suite found for  scipy.signal.bsplines
No test suite found for  scipy.signal.filter_design
No test suite found for  scipy.signal.ltisys
 creating test suite for: scipy.signal.signaltools
No test suite found for  scipy_base.__cvs_version__
 creating test suite for: scipy_base.function_base
 creating test suite for: scipy_base.index_tricks
 creating test suite for: scipy_base.limits
 creating test suite for: scipy_base.matrix_base
No test suite found for  scipy_base.polynomial
No test suite found for  scipy_base.scimath
No test suite found for  scipy_base.scipy_base_version
 creating test suite for: scipy_base.shape_base
 creating test suite for: scipy_base.type_check
No test suite found for  ppimport
No test suite found for  scipy.signal.pre___init__
No test suite found for  scipy.special.__cvs_version__
No test suite found for  scipy.special.gendoc
No test suite found for  scipy_base.__cvs_version__
 creating test suite for: scipy_base.function_base
 creating test suite for: scipy_base.index_tricks
 creating test suite for: scipy_base.limits
 creating test suite for: scipy_base.matrix_base
No test suite found for  scipy_base.polynomial
No test suite found for  scipy_base.scimath
No test suite found for  scipy_base.scipy_base_version
 creating test suite for: scipy_base.shape_base
 creating test suite for: scipy_base.type_check
No test suite found for  ppimport
 creating test suite for: scipy.special.special
No test suite found for  scipy.special.special_version
 creating test suite for: scipy.special.basic
No test suite found for  scipy.special.pre___init__
 creating test suite for: scipy.stats.distributions
 creating test suite for: scipy.stats.morestats
No test suite found for  scipy.stats.pstat
No test suite found for  scipy.stats.rv
 creating test suite for: scipy.stats.stats
No test suite found for  scipy.stats.pre___init__
........................................................
Don't worry about a warning regarding the number of bytes read.
Warning: 1000000 bytes requested, 20 bytes read.
...................................................scopy:n=4
..scopy:n=3
....dcopy:n=4
..dcopy:n=3
....ccopy:n=4
..ccopy:n=3
....zcopy:n=4
..zcopy:n=3
.....saxpy:n=4
..saxpy:n=3
.....daxpy:n=4
..daxpy:n=3
.....caxpy:n=4
..caxpy:n=3
.....zaxpy:n=4
..zaxpy:n=3
...sscal:n=4
...dscal:n=4
...cscal:n=4
...zscal:n=4
....sswap:n=4
..sswap:n=3
....dswap:n=4
..dswap:n=3
....cswap:n=4
..cswap:n=3
....zswap:n=4
..zswap:n=3
.............................TESTING CONVERGENCE

zero should be 1

function f2

cc.bisect :    1.0000000000001952
cc.ridder :    1.0000000000004658
cc.brenth :    0.9999999999999997
cc.brentq :    0.9999999999999577



function f3

cc.bisect :    1.0000000000001952
cc.ridder :    1.0000000000000000
cc.brenth :    1.0000000000000009
cc.brentq :    1.0000000000000011



function f4

cc.bisect :    1.0000000000001952
cc.ridder :    1.0000000000001452
cc.brenth :    0.9999999999993339
cc.brentq :    0.9999999999993339



function f5

cc.bisect :    1.0000000000001952
cc.ridder :    1.0000000000004574
cc.brenth :    0.9999999999991444
cc.brentq :    0.9999999999991444



function f6

cc.bisect :    1.0000000000001952
cc.ridder :    1.0000000000003708
cc.brenth :    0.9999999999988605
cc.brentq :    1.0000000000012830



...........................................................................................................................................................................................................................................
Gamma overflow error
....................................................................................................F...............
Gamma overflow error
....................................................................................................F..............Testing uniform
.Testing norm
.Testing lognorm
.Testing expon
.Testing beta
.Testing powerlaw
.Testing bradford
.Testing burr
.Testing fisk
.Testing cauchy
.Testing halfcauchy
.Testing foldcauchy
.Testing gamma
.Testing gengamma
.Testing loggamma
.Testing alpha
.Testing anglit
.Testing arcsine
.Testing betaprime
.Testing erlang
.Testing dgamma
.Testing exponweib
.Testing exponpow
.Testing frechet_l
.Testing frechet_r
.Testing gilbrat
.Testing f
.Testing ncf
.Testing chi2
.Testing chi
.Testing nakagami
.Testing genpareto
.Testing genextreme
.Testing genhalflogistic
.Testing pareto
.Testing lomax
.Testing halfnorm
.Testing halflogistic
.Testing fatiguelife
.Testing foldnorm
.Testing ncx2
.Testing t
.Testing nct
.Testing weibull_min
.Testing weibull_max
.Testing dweibull
.Testing maxwell
.Testing rayleigh
.Testing genlogistic
.Testing logistic
.Testing gumbel_l
.Testing gumbel_r
.Testing gompertz
.Testing hypsecant
.Testing laplace
.Testing reciprocal
.Testing triang
.Testing tukeylambda
.............F..Ties preclude use of exact statistic.
..Ties preclude use of exact statistic.
..............................................................................................
======================================================================
FAIL: check_sinc (test_special.test_sinc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.2/site-packages/scipy/special/tests/test_special.py",
line 1188, in check_sinc
    assert_array_almost_equal(y, yre,4)
  File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line
405, in assert_array_almost_equal
    assert alltrue(ravel(reduced)),\
AssertionError: 
Arrays are not almost equal:
	

======================================================================
FAIL: check_sinc (test_basic.test_sinc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.2/site-packages/scipy/special/tests/test_basic.py",
line 1193, in check_sinc
    assert_array_almost_equal(y, yre,4)
  File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line
405, in assert_array_almost_equal
    assert alltrue(ravel(reduced)),\
AssertionError: 
Arrays are not almost equal:
	

======================================================================
FAIL: check_basic (test_morestats.test_shapiro)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py",
line 31, in check_basic
    assert_almost_equal(pw,0.042089745402336121,6)
  File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line
349, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
DESIRED: 0.042089745402336121
ACTUAL: 0.042089227586984634

----------------------------------------------------------------------
Ran 855 tests in 2.283s

FAILED (failures=3)
<unittest.TextTestRunner instance at 0x827e294>
>>> >>> 
hale:~> exit
exit

Script done on Tue Mar 25 16:04:49 2003




From pearu at cens.ioc.ee  Wed Mar 26 01:35:52 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 26 Mar 2003 08:35:52 +0200 (EET)
Subject: [SciPy-user] scipy.test output errors
In-Reply-To: <1048640306.1286.26.camel@dhcppc1>
Message-ID: <Pine.LNX.4.21.0303260829560.19507-100000@cens.kybi>

On 25 Mar 2003, Stephen Walton wrote:

> BTW, I've been using the 'checkinstall' package to monitor installation
> of software on my systems with great success.  It doesn't quite work
> with scipy because there are a few files included with both it and F2PY.

This issue can currently be resolved by following these steps:
1) manually disable scipy_distutils installation in F2PY setup.py script
2) install F2PY
3) install scipy

Pearu



From bardo_mueller at yahoo.de  Wed Mar 26 02:00:13 2003
From: bardo_mueller at yahoo.de (=?iso-8859-1?Q?Bardo_M=FCller?=)
Date: Wed, 26 Mar 2003 08:00:13 +0100
Subject: [SciPy-user] Python-to-Matlab converter ?
Message-ID: <002501c2f365$5abe90c0$0101a8c0@poet>

Dear all,

I guess it is kind of heretic to ask here for such a thing, but my language is Matlab.

There are some Phyton-to-C scripts around which I tried to hack and they appear to have internal errors or do not work with the latest Python version. 

Every input or pointer is welcome.

BR,

Bardo
---
bardo_mueller at yahoo.de


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

From Kasper.Souren at ircam.fr  Wed Mar 26 09:49:50 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Wed, 26 Mar 2003 15:49:50 +0100
Subject: [SciPy-user] Python-to-Matlab converter ?
In-Reply-To: <002501c2f365$5abe90c0$0101a8c0@poet>
References: <002501c2f365$5abe90c0$0101a8c0@poet>
Message-ID: <200303261549.53418.Kasper.Souren@ircam.fr>

> I guess it is kind of heretic to ask here for such a thing, but my language
> is Matlab.

I don't speak Matlab, but I know a bit about it.

> There are some Phyton-to-C scripts around which I tried to hack and they
> appear to have internal errors or do not work with the latest Python
> version.

What do you need it for? There are many ways to do many things.

If you just would want to pass data, that's easy if you don't mind saving it 
into a file first. Check scipy.io stuff, AFAIK it's compatible with Matlab's 
I/O stuff.

I guess you could also embed Python in Matlab, using mex and Python's 
excellent embedding capabilites.

> Every input or pointer is welcome.

Ok. Then I can't resist to add this one: try to start move your Matlab stuff 
into Python! ;)

bye,
Kasper


From bardo_mueller at yahoo.de  Wed Mar 26 09:58:38 2003
From: bardo_mueller at yahoo.de (=?iso-8859-1?q?Bardo=20Mueller?=)
Date: Wed, 26 Mar 2003 15:58:38 +0100 (CET)
Subject: [SciPy-user] Python-to-Matlab converter ?
In-Reply-To: <200303261549.53418.Kasper.Souren@ircam.fr>
Message-ID: <20030326145838.25278.qmail@web11405.mail.yahoo.com>

Kasper,

I have source code translation in mind, not
interfacing.

The following link is broken, anyone whos has kept a
copy ?
http://lima.mudlib.org/~rassilon/p2c/

http://www.strout.net/python/ai/python2c.py


 --- Kasper Souren <Kasper.Souren at ircam.fr> schrieb: >
> I guess it is kind of heretic to ask here for such
> a thing, but my language
> > is Matlab.
> 
> I don't speak Matlab, but I know a bit about it.
> 
> > There are some Phyton-to-C scripts around which I
> tried to hack and they
> > appear to have internal errors or do not work with
> the latest Python
> > version.
> 
> What do you need it for? There are many ways to do
> many things.
> 
> If you just would want to pass data, that's easy if
> you don't mind saving it 
> into a file first. Check scipy.io stuff, AFAIK it's
> compatible with Matlab's 
> I/O stuff.
> 
> I guess you could also embed Python in Matlab, using
> mex and Python's 
> excellent embedding capabilites.
> 
> > Every input or pointer is welcome.
> 
> Ok. Then I can't resist to add this one: try to
> start move your Matlab stuff 
> into Python! ;)
> 
> bye,
> Kasper
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user 

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de


From bardo_mueller at yahoo.de  Wed Mar 26 10:03:07 2003
From: bardo_mueller at yahoo.de (=?iso-8859-1?q?Bardo=20Mueller?=)
Date: Wed, 26 Mar 2003 16:03:07 +0100 (CET)
Subject: [SciPy-user] Python-to-Matlab converter ?
In-Reply-To: <200303261549.53418.Kasper.Souren@ircam.fr>
Message-ID: <20030326150307.55666.qmail@web11403.mail.yahoo.com>

Kasper,

I have source code translation in mind, not
interfacing. (I believe you that Python is the best
language anyway..)

These are the sources I fould for Python->C
translation, which I could use as templates for
Matlab:

The p2c link is broken. Anyone whos has kept a copy ?
  http://lima.mudlib.org/~rassilon/p2c/

python2c reports errors during the conversion. Anyone
who has it running under the latest version of Python
?
  http://www.strout.net/python/ai/python2c.py

Best,

Bardo
---
bardo_mueller at yahoo.de


 --- Kasper Souren <Kasper.Souren at ircam.fr> schrieb: >
> I guess it is kind of heretic to ask here for such
> a thing, but my language
> > is Matlab.
> 
> I don't speak Matlab, but I know a bit about it.
> 
> > There are some Phyton-to-C scripts around which I
> tried to hack and they
> > appear to have internal errors or do not work with
> the latest Python
> > version.
> 
> What do you need it for? There are many ways to do
> many things.
> 
> If you just would want to pass data, that's easy if
> you don't mind saving it 
> into a file first. Check scipy.io stuff, AFAIK it's
> compatible with Matlab's 
> I/O stuff.
> 
> I guess you could also embed Python in Matlab, using
> mex and Python's 
> excellent embedding capabilites.
> 
> > Every input or pointer is welcome.
> 
> Ok. Then I can't resist to add this one: try to
> start move your Matlab stuff 
> into Python! ;)
> 
> bye,
> Kasper
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user 

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de


From alobo at ija.csic.es  Thu Mar 27 05:15:38 2003
From: alobo at ija.csic.es (Agustin Lobo)
Date: Thu, 27 Mar 2003 11:15:38 +0100 (MET)
Subject: [SciPy-user] scipy to C ?
Message-ID: <Pine.OSF.3.91.1030327111030.20651D-100000@paleo.ija.csic.es>

Is there a tool to convert a (sci)python
program into a C program? something like
what the Matlab compiler is supossed to
do (never tried) with matlab scripts?

My interest is on improving the performance
of scipy scripts that use (unavoidable, at least
for me) "for loops".

Thanks

Agus

Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
alobo at ija.csic.es




From e.hartley at lancaster.ac.uk  Thu Mar 27 07:26:16 2003
From: e.hartley at lancaster.ac.uk (Edward Hartley)
Date: Thu, 27 Mar 2003 12:26:16 +0000
Subject: [SciPy-user] Python-to-Matlab converter
Message-ID: <4E76A072-604F-11D7-B510-0003939CD440@lancaster.ac.uk>

Hi
I know this is heretical but I can see the rationale as well
especially if you have a lot of existing matlab code.

There is the pymat module which passes python arrays to and from
a running matlab engine.

three versions are available to suit various matlab python combinations 
from

http://claymore.engineer.gvsu.edu/~steriana/Python

and a more recent cvs tree is accessible at

http://cvs.iuveno-net.de/cvs/viewcvs.cgi/MatLabDA/pymat

I have just got it to pass the test  for me with python2.2 and
matlab R12.1

There is quite a bit of variation in the matlab interface from v5 to v6 
i.e r12
and I had to tweak the cvs version to use the matlab function calls 
indicated
in Pymat22 and also add a call to mxSetName c.f. the Matlab engdemo.c
for my version.
So  what you need will depend on the specific engine.h for your matlab

Looking at r13 it appears that the interface changes again according to
the documentation though I don't have this.

Regards
Ed Hartley



From fperez at colorado.edu  Thu Mar 27 16:45:54 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Thu, 27 Mar 2003 14:45:54 -0700
Subject: [SciPy-user] IPython, a new SciPy.org netizen
Message-ID: <3E837112.6010603@colorado.edu>

Hi all,

I'd like start by publicly thanking Eric Jones, Joe Cooper and the rest of the 
SciPy team for hosting IPython.  Some of you are already users of ipython and 
may have received a message earlier today about this. My apologies for the 
double mail, this one is short :)

For those who are not previous ipython users, I encourage you to take a look 
at IPython at:

http://ipython.scipy.org

This will be IPython's new home on the net, and it will have the usual 
scipy.org accoutrements in due time.  But right now the most important things, 
  anonymous CVS access and mailing lists, are already up.

I really hope that this will not only enable me to develop ipython further, 
but also help the whole community to provide the scipy project with a good 
interactive shell.  Scipy is heavily using PyCrust already, and I have a lot 
of interest in moving ipython in the direction of integrating (optionally) 
with pycrust.

For further discussion of ipython issues, I encourage those interested to sign 
  up at the ipython-specific mailing lists, located at:

   - User list: http://scipy.net/mailman/listinfo/ipython-user
   - Dev list: http://scipy.net/mailman/listinfo/ipython-dev

This will keep the scipy-* lists focused on scipy-specific issues.

Those interested in integration with PyCrust should also sign up for the 
PyCrust list at https://lists.sourceforge.net/lists/listinfo/pycrust-users, 
following Patrick O'Brien's suggestion. Knowledgeable WxPython developers 
would be most welcome.

Hope to see you all on the lists!

Best regards,

f.



From harenma at netscape.net  Thu Mar 27 18:54:10 2003
From: harenma at netscape.net (MANPENSA DONDO)
Date: Fri, 28 Mar 2003 00:54:10 +0100
Subject: [SciPy-user] URGENT ASSISTANCE
Message-ID: <20030328003734.81BCC3EB09@www.scipy.com>

Dear Friend, 

RE: REQUEST FOR URGENT ASSISTANCE IN THE TRANSFER AND SAFEKEEPING FOR INVESTMENT OF $25.5 MILLION USD

I am Mr.MANPENSA DONDO, a financial intermediary for Mikky Kabila, the first son of the third wife of the late Congolese President, LAURENT KABILA who was assassinated by one of his bodyguards.
Mikky's father entrusted into his mother's care certain documents and trunk boxes. Amongst these documents are deposit bonds certificate and cash sum $25.5 million USD in the trunk boxes and some other family treasures, this trunk boxes containing the said cash sum were hidden in a cellar under the presidential mansion.

After the death of LAURENT KABILA, Mikky's elder brother took over as president and he immediately confiscated all of their father's properties including his bank account and all other family possessions. Mikky's mother was worse hit as she was driven out of the family mansion while Mikky himself was declared wanted. Meanwhile Mikky and his Mother were able to smuggle the boxes of cash out of the cellar in the mansion and immediately took the boxes overseas for investment. Presently the boxes are kept with CONTINENTAL SECURITY COMPANY based in Europe. Mikky has taken a temporary refugee status in one of the West African country awaiting my assistance in sourcing for a reputable trusted person who will help invest the money into a profitable venture.

I have decided to nominate you for this project as beneficiary to this fund who would claim this from the security company in Europe on behalf of the family.
Your response to this proposal is urgently needed for immediate action. In your response, please include your full name,date of birth and contact address, private tel. and fax phone number, email address for submission to the security firm as the beneficiary.

Yours Faithfully,
MANPENSA DONDO. 

NOTE:
Mikky has directed that you would be entitled to 20% of the said amount for your effort . 
Please keep this information to your self for security reasons. 

From jerry at bauck.net  Thu Mar 27 23:32:35 2003
From: jerry at bauck.net (Jerry Bauck)
Date: Thu, 27 Mar 2003 21:32:35 -0700
Subject: [SciPy-user] scipy to C ?
In-Reply-To: <Pine.OSF.3.91.1030327111030.20651D-100000@paleo.ija.csic.es>
Message-ID: <4C6F898A-60D6-11D7-89B8-003065F93FF0@bauck.net>

Is this what you need? From scipy.org:


Weave is a new  package that provides tools for including C/C++ code 
within Python code. Highlights include:

weave.inline(): Executes C code directly within Python.

weave.blitz(): Translates Python Numeric expressions to C++ for fast  
execution.

ext_tools module: Provides classes for building extension modules 
within Python, for those interested in building extension libraries.




On Thursday, Mar 27, 2003, at 03:15 America/Phoenix, Agustin Lobo wrote:

>
> Is there a tool to convert a (sci)python
> program into a C program? something like
> what the Matlab compiler is supossed to
> do (never tried) with matlab scripts?
>
> My interest is on improving the performance
> of scipy scripts that use (unavoidable, at least
> for me) "for loops".
>
> Thanks
>
> Agus
>
> Dr. Agustin Lobo
> Instituto de Ciencias de la Tierra (CSIC)
> Lluis Sole Sabaris s/n
> 08028 Barcelona SPAIN
> tel 34 93409 5410
> fax 34 93411 0012
> alobo at ija.csic.es
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>



From lanceboyle at myrealbox.com  Thu Mar 27 23:33:39 2003
From: lanceboyle at myrealbox.com (Lance Boyle)
Date: Thu, 27 Mar 2003 21:33:39 -0700
Subject: [SciPy-user] scipy to C ?
In-Reply-To: <Pine.OSF.3.91.1030327111030.20651D-100000@paleo.ija.csic.es>
Message-ID: <7308739C-60D6-11D7-89B8-003065F93FF0@myrealbox.com>

Is this what you need? From scipy.org:


Weave is a new  package that provides tools for including C/C++ code 
within Python code. Highlights include:

weave.inline(): Executes C code directly within Python.

weave.blitz(): Translates Python Numeric expressions to C++ for fast  
execution.

ext_tools module: Provides classes for building extension modules 
within Python, for those interested in building extension libraries.




On Thursday, Mar 27, 2003, at 03:15 America/Phoenix, Agustin Lobo wrote:

>
> Is there a tool to convert a (sci)python
> program into a C program? something like
> what the Matlab compiler is supossed to
> do (never tried) with matlab scripts?
>
> My interest is on improving the performance
> of scipy scripts that use (unavoidable, at least
> for me) "for loops".
>
> Thanks
>
> Agus
>
> Dr. Agustin Lobo
> Instituto de Ciencias de la Tierra (CSIC)
> Lluis Sole Sabaris s/n
> 08028 Barcelona SPAIN
> tel 34 93409 5410
> fax 34 93411 0012
> alobo at ija.csic.es
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>



From eric at enthought.com  Thu Mar 27 23:47:25 2003
From: eric at enthought.com (Eric Jones)
Date: Thu, 27 Mar 2003 22:47:25 -0600 (CST)
Subject: [SciPy-user] IPython, a new SciPy.org netizen
Message-ID: <20030328044725.50F731050@www.enthought.com>

Hey Fernando,

Cool!  Glad to hear this is all set up.  I look forward to a bright future for ipython and pycrust integration.

By the way, I'm at PyCon right now, and the conference is going very well.  They've done a great job of organizing it.

see ya,
eric

Fernando Perez <fperez at colorado.edu> wrote ..
> Hi all,
> 
> I'd like start by publicly thanking Eric Jones, Joe Cooper and the rest
> of the 
> SciPy team for hosting IPython.  Some of you are already users of ipython
> and 
> may have received a message earlier today about this. My apologies for
> the 
> double mail, this one is short :)
> 
> For those who are not previous ipython users, I encourage you to take a
> look 
> at IPython at:
> 
> http://ipython.scipy.org
> 
> This will be IPython's new home on the net, and it will have the usual
> scipy.org accoutrements in due time.  But right now the most important
> things, 
>   anonymous CVS access and mailing lists, are already up.
> 
> I really hope that this will not only enable me to develop ipython further,
> but also help the whole community to provide the scipy project with a good
> interactive shell.  Scipy is heavily using PyCrust already, and I have
> a lot 
> of interest in moving ipython in the direction of integrating (optionally)
> with pycrust.
> 
> For further discussion of ipython issues, I encourage those interested
> to sign 
>   up at the ipython-specific mailing lists, located at:
> 
>    - User list: http://scipy.net/mailman/listinfo/ipython-user
>    - Dev list: http://scipy.net/mailman/listinfo/ipython-dev
> 
> This will keep the scipy-* lists focused on scipy-specific issues.
> 
> Those interested in integration with PyCrust should also sign up for the
> PyCrust list at https://lists.sourceforge.net/lists/listinfo/pycrust-users,
> following Patrick O'Brien's suggestion. Knowledgeable WxPython developers
> would be most welcome.
> 
> Hope to see you all on the lists!
> 
> Best regards,
> 
> f.
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user

From e.hartley at lancaster.ac.uk  Fri Mar 28 05:50:49 2003
From: e.hartley at lancaster.ac.uk (Edward Hartley)
Date: Fri, 28 Mar 2003 10:50:49 +0000
Subject: [SciPy-user] Overflow Errors
Message-ID: <2301BCB2-610B-11D7-B510-0003939CD440@lancaster.ac.uk>

Hi
I'm using python 2.2.2

I know there are some issues with overflow errors

So should this version be reompiled with -lieee as
I've seen suggested on another thread and if
so does this mean I have to adjust the Makefile
or can it be done through the configure  script
Regards
Ed Hartley



From rpm at wag.caltech.edu  Fri Mar 28 09:57:05 2003
From: rpm at wag.caltech.edu (Richard Muller)
Date: Fri, 28 Mar 2003 06:57:05 -0800
Subject: [SciPy-user] SciPy and PyGSL
Message-ID: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu>

I've been spending a little time getting to know the Gnu Scientific 
Library. It shares a lot of the strengths with SciPy. I notice that 
there is a fledgling effort to make python wrappers to the GSL, and I 
now wonder how the SciPy community sees such an effort: competition, 
fellow warriors, or potential successor?

I for one would like to see the GSL become more of a standard in the 
scientific computing field, so I'd like to see PyGSL get support. But 
not necessarily at the expense of SciPy. Thoughts?

Rick

Rick Muller
rpm at wag.caltech.edu
http://wag.caltech.edu/home/rpm



From prabhu at aero.iitm.ernet.in  Fri Mar 28 10:48:11 2003
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Fri, 28 Mar 2003 21:18:11 +0530
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu>
Message-ID: <16004.28347.150885.202870@monster.linux.in>

>>>>> "RM" == Richard Muller <rpm at wag.caltech.edu> writes:

    RM> I've been spending a little time getting to know the Gnu
    RM> Scientific Library. It shares a lot of the strengths with
    RM> SciPy. I notice that there is a fledgling effort to make
    RM> python wrappers to the GSL, and I now wonder how the SciPy
    RM> community sees such an effort: competition, fellow warriors,
    RM> or potential successor?

    RM> I for one would like to see the GSL become more of a standard
    RM> in the scientific computing field, so I'd like to see PyGSL
    RM> get support. But not necessarily at the expense of
    RM> SciPy. Thoughts?

IIRC, the biggest issue with GSL is the GPL license.  SciPy uses a BSD
style license.  Since the GPL is so restrictive, if SciPy even linked
to libgsl, SciPy would need to be released as GPL.  Dual licensing as
GPL/BSD is meaningless.

 We are the Borg of FSF, non-GPL is futile, you will be GPL'd! :)

Sorry could not resist that one!

cheers,
prabhu


From bryan.cole at teraview.co.uk  Fri Mar 28 12:12:48 2003
From: bryan.cole at teraview.co.uk (bryan cole)
Date: 28 Mar 2003 17:12:48 +0000
Subject: [SciPy-user] Overflow Errors
In-Reply-To: <2301BCB2-610B-11D7-B510-0003939CD440@lancaster.ac.uk>
References: <2301BCB2-610B-11D7-B510-0003939CD440@lancaster.ac.uk>
Message-ID: <1048871568.10989.25.camel@bryan.teraviewhq.local>

Try:

 ./configure --with-libs='-lieee'

This should sort out Numeric overflow errors (well it works for me).
Add any other configure options you usually use.

I'm using py-2.2.1 (from the stock RH8.0 source rpm): for an rpm-based
system, you can install the python source-rpm then modify the
python.spec file by adding the "--with-libs='-lieee'" to the configure
line in the spec file so it reads (python.spec, line 159 for the RH8.0
src-rpm):

%configure --enable-ipv6 --enable-unicode=ucs2 --with-libs='-lieee'

You can then rebuild the rpm in the usual way.

HTH
Bryan

On Fri, 2003-03-28 at 10:50, Edward Hartley wrote:
> Hi
> I'm using python 2.2.2
> 
> I know there are some issues with overflow errors
> 
> So should this version be reompiled with -lieee as
> I've seen suggested on another thread and if
> so does this mean I have to adjust the Makefile
> or can it be done through the configure  script
> Regards
> Ed Hartley
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
-- 
Bryan Cole
Teraview Ltd., 302-304 Cambridge Science Park, Milton Road, Cambridge CB4 0WG, United Kingdom.
tel: +44 (1223) 435380 / 435386 (direct-dial) fax: +44 (1223) 435382



From fperez at colorado.edu  Fri Mar 28 13:16:54 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Fri, 28 Mar 2003 11:16:54 -0700
Subject: [SciPy-user] IPython, a new SciPy.org netizen
In-Reply-To: <20030328044725.50F731050@www.enthought.com>
References: <20030328044725.50F731050@www.enthought.com>
Message-ID: <3E849196.6000502@colorado.edu>

Hi Eric,

> Cool!  Glad to hear this is all set up.  I look forward to a bright future
> for ipython and pycrust integration.

Me too.  I'm sure this will benefit us all.

By the way, I had a question prompted by an ipython user, but which is 
relevant to all Scipy.org mailing lists.  Jacek was inquiring about being able 
to read them via gmane, the mailing-list-usenet bridge service.  Currently the 
python-devel list is available there, and in fact that's how I read it.

This is useful for people who want to loosely follow a list without direct 
involvement or without having their inboxes overflow.  The gateway is one-way, 
so there is no risk of lurkers spamming the lists without subscribing.

In order to subscribe a mailing list to gmane distribution, this short form 
has to be filled out:

http://gmane.org/subscribe.php

It's simple, but I don't want to do anything concerning the ipython lists 
before hearing your opinion.  In principle it sounds to me like a harmless, 
useful thing, but you may well have objections I'm not aware of.

If you don't object I may subscribe the ipython lists, and you might do the 
same to the scipy/chaco ones if you like.   It may give the projects more 
exposure to an audience who may not be willing to subscribe full time.

Best,

f.



From Kasper.Souren at ircam.fr  Fri Mar 28 13:49:28 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Fri, 28 Mar 2003 18:49:28 +0000
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu>
Message-ID: <200303281849.29253.Kasper.Souren@ircam.fr>

On Friday 28 March 2003 14:57, Richard Muller wrote:
> I've been spending a little time getting to know the Gnu Scientific
> Library. It shares a lot of the strengths with SciPy. I notice that
> there is a fledgling effort to make python wrappers to the GSL, and I
> now wonder how the SciPy community sees such an effort: competition,
> fellow warriors, or potential successor?
>
> I for one would like to see the GSL become more of a standard in the
> scientific computing field, so I'd like to see PyGSL get support. But
> not necessarily at the expense of SciPy. Thoughts?

If you want to keep using the GPL license for GSL, it might be more 
interesting to check out if it's possible to try to merge it into 
ScientificPython. That's a GPL'd library for Python.

bye,
Kasper


From travis at enthought.com  Fri Mar 28 14:05:17 2003
From: travis at enthought.com (Travis N. Vaught)
Date: Fri, 28 Mar 2003 13:05:17 -0600
Subject: [SciPy-user] IPython, a new SciPy.org netizen
In-Reply-To: <3E849196.6000502@colorado.edu>
Message-ID: <001e01c2f55c$fbf9be80$0300a8c0@tvlaptop>

+1 from me on the gmane indexing.

TV

> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Fernando Perez
> Sent: Friday, March 28, 2003 12:17 PM
> To: scipy-user at scipy.net
> Cc: Jacek Generowicz; eric jones
> Subject: Re: [SciPy-user] IPython, a new SciPy.org netizen
> 
> Hi Eric,
> 
> > Cool!  Glad to hear this is all set up.  I look forward to a bright
> future
> > for ipython and pycrust integration.
> 
> Me too.  I'm sure this will benefit us all.
> 
> By the way, I had a question prompted by an ipython user, but which is
> relevant to all Scipy.org mailing lists.  Jacek was inquiring about
being
> able
> to read them via gmane, the mailing-list-usenet bridge service.
Currently
> the
> python-devel list is available there, and in fact that's how I read
it.
> 
> This is useful for people who want to loosely follow a list without
direct
> involvement or without having their inboxes overflow.  The gateway is
one-
> way,
> so there is no risk of lurkers spamming the lists without subscribing.
> 
> In order to subscribe a mailing list to gmane distribution, this short
> form
> has to be filled out:
> 
> http://gmane.org/subscribe.php
> 
> It's simple, but I don't want to do anything concerning the ipython
lists
> before hearing your opinion.  In principle it sounds to me like a
> harmless,
> useful thing, but you may well have objections I'm not aware of.
> 
> If you don't object I may subscribe the ipython lists, and you might
do
> the
> same to the scipy/chaco ones if you like.   It may give the projects
more
> exposure to an audience who may not be willing to subscribe full time.
> 
> Best,
> 
> f.
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From DavidA at ActiveState.com  Fri Mar 28 14:18:49 2003
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 28 Mar 2003 14:18:49 -0500
Subject: [SciPy-user] IPython, a new SciPy.org netizen
In-Reply-To: <3E849196.6000502@colorado.edu>
References: <20030328044725.50F731050@www.enthought.com> <3E849196.6000502@colorado.edu>
Message-ID: <3E84A019.2020508@ActiveState.com>

I don't know why I haven't gotten the scipy mailing lists indexed on 
ASPN (aspn.activestate.com/Mail) yet -- I'll get that done next week 
when I'm back from PyCon.

Nothing against gmane, but the more options the better IMO. =)

--da



From tzavist at westanley.com  Fri Mar 28 15:22:29 2003
From: tzavist at westanley.com (Thomas M. Zavist)
Date: Fri, 28 Mar 2003 15:22:29 -0500
Subject: [SciPy-user] Resultant of two polynomials - Sylvester matrix
Message-ID: <3E84AF05.DD98EC69@westanley.com>

Dear scipy-user:

I stumbled upon a request on the internet by Nils Wagner.

The request is "I am looking for a function which computes the resultant
of two polynomials.  It is defined to be the determinant of their
Sylvester matrix.  A small example would be appreciated."

About 15 years ago I read what looks like the answer to the question in
the Fondren Library at Rice University in a book by Yitzhak Katznelson
entitled "Yale Lecture Series," or something like that, published in
1960.

If you have two polynomials A + Bx + Cx^2 + Dx^3 and E + Fx + Gx^2, then
the resultant of the two is the determinant of the 5 x 5 matrix with the
following elements:

A  0  E  0  0
B  A  F  E  0
C  B  G  F  E
D  C  0  G  F
0  D  0  0  G

The polynomials have a common root if and only if the determinant--the
resultant is zero.  The resultant is related to the product of the
difference of each pair of roots--one from each polynomial.  You can
define the resultant for any pair of polynomials in one variable.  A
polynomial of degree m and another of degree n lead to an (m+n) x (m+n)
determinant as their resultant.

Katznelson's lecture, which is described above, pertains to two
polynomials of one variable.

If you have two polynomials of more than one variable, you can treat
them as polynomials of one variable--treating the additional variables
as constants and dropping them into the resultant.  The result is one
polynomial that has one fewer variable than the two polynomials you had
originally.  By iterating this process you can take a system of
polynomial equations in several variables and eliminate as many
variables as there are equations in excess of one.

Besides this recursive procedure, there are other ways to generalize the
resultant to solve any system of polynomial equations.

You can also use the resultant to define a polynomial whose roots are
the sum, difference, product or quotient of the roots of other
polynomials.

I hope this is helpful.

Sincerely,

Tom Zavist




From mark_sank02 at mal.com  Sat Mar 29 00:41:03 2003
From: mark_sank02 at mal.com (MICHEAL SANKOH JNR.)
Date: Sat, 29 Mar 2003 06:41:03 +0100
Subject: [SciPy-user] URGENT RESPONSES NEEDED
Message-ID: <20030329062504.57A773EB18@www.scipy.com>

URGENT ASSISTANCE NEEDED
WITH ABSOLUTE TRUST IN GOD AND DUE RESPECT TO YOU, I WRITE TO YOU THIS LETTER WHICH I BELIEVE YOU WOULD BE OF GREAT ASSISTANCE TO ME AND WOULD KEEP THE INFORMATION CONFIDENTIAL. I AM MICHEAL SANKOH, A SON TO FODAY SANKOH, THE REBEL LEADER IN SIERRA LEONE WARRING FACTIONS, I AM ABSOLUTELY AGAINST THE UNENDING POLITICAL CRISES IN MY COUNTRY THAT HAS RESULTED TO A MISSIVE DESTRUCTION OF HUMAN LIVES AND PROPERTY WHICH IS CURRENTLY IN THE WORLD NEWS. ON THIS LAST ASSAULT BY THE FORCES. I ESCAPED  TO THE NETHERLAND THROUGH THE HELP OF UNITED NATIONS SOLDIERS WHO ARE THERE ON A PEACE MISSION. ON ARRIVAL TO AMSTERDAM, I WENT DIRECTLY TO THE ASSYLUM CAMP, TO SEEK FOR POLITICAL ASSYLUM, I WAS ASCEPTED, and BEFORE THE WAR HE DEPOSITED A TOTAL SUM $10.500 MILLION USD IN TWO TRUNK BOXES WITH A SAFE DEPOSIT WITH FINANCE HOUSE. HE DEPOSITED THEM AS FAMILY VALUABLES IN THE NAME OF HIS SON MICHAEL SANKOH. I AM  LOOKING  FOR A RELIABLE AND TRUST WORTHY PARTNER FROM A DIFFERENT COUNTRIES FROM THE NETHERLANDS SINCE THE LAW OF THE NETHERLANDS PROHIBIT A REFUGEE (ASYLUM SEEKER) TO OPEN ACCOUNT OR TO BE INVOLVED IN ANY FINANCIAL TRANSACTION.MOREOVER, 
 THE NETHERLANDS FOREIGN EXCHANGE POLICY DOES NOT ALLOW SUCH INVESTMENT FROM  ASYLUM SEEKERS.I AM FACED WITH THE DILEMA OF INVESTING THIS AMOUNT OF MONEY IN THE NETHERLANDS FOR THE FEAR OF GOING THROUGH THE SAME EXPERIENCE IN FUTURE SINCE BOTH COUNTRIES HAVE SIMILAR HISTORY. I HUMBLY SOLICIT FOR YOUR ASSISTANCE IN THE FOLLOWING:
1) PAY A SHORT WORKING DAY VISIT TO AMSTERDAM THE NETHERLANDS SO THAT WE SEE FACE TO FACE, HAVE A TABLE TALK THAT WOULD CREATE CONFIDENCE IN ME THAT THE FUND WOULD BE SAFE IN YOUR HANDS AND HAVE HAVE AN AGREEMENT FROM A ADVOCATE, WHICH WILL BE DULY AND LEGALLY SIGN IN HIS CHAMBERS BEFORE TAKEN ANY STEP IN THIS TRANSACTION.
2GET ALL THE NECESSARY DOCUMENT REGARDING THIS TRANSACTION AND CLAIM THE BOXES FROM THE SECURITY COMPANY, OPEN AN ACCOUNT IN YOUR NAME WITH A LOCAL BANK HERE AND DEPOSIT THE MONEY FOR ONWARD TRANSFER TO YOUR DESIGNATED ACCOUNTS OVERSEAS.
3) MAKE A GOOD ARRANGEMENT FOR INVESTMENT AND DO INVEST THE MONEY FOR ME. I AM WILLING TO GIVE YOU SOME PERCENTAGE FOR YOUR ASSISTANCE AND ON THIS, I OFFER YOU 15%. 5% WOULD BE USED TO OFFSET EVERY EXPENSES TO BE INCURRED AND TAXES OR CHARGES TO BE PAID IN THE COURSE ON THE TRANSACTION WHILE 80% WOULD BE INVESTED AND YOU GET YOUR WAGE MONTHLY FOR MANAGING THE 80%. I ASSURE YOU THAT THE TRANSACTION IS RISK FREE AND COULD BE COMPLETED UPON YOUR ARRIVAL IF YOU WOULD BE OF ASSISTANCE TO ME, PLEASE FORWARD YOUR REPLY THROUGH MY PRIVATE EMAIL ADDRESS AND CALL ME ON MY TELEPHONE LINE: 0031629343835 FOR FURTHER DISCUSSION, AND REMEMBER CONFIDENTIAL SINCE I AM STILL WITH THE NETHERLANDS GOVERNMENT.
THANKS AND GOD BLESS
MICHEAL SANKOH JNR.  

From chris at fonnesbeck.org  Sat Mar 29 13:01:41 2003
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Sat, 29 Mar 2003 13:01:41 -0500
Subject: [SciPy-user] cannot build SciPy on Redhat 8.0
Message-ID: <3E85DF85.7090100@fonnesbeck.org>

Hi folks,

I am trying to build SciPy on a new installation of RedHat 8.0, but am 
ahving trouble getting out of the gate.  I have installed all of the 
prerequisite packages, but when I try and run "python setup.py install", 
I get the following:

Traceback (most recent call last):
  File "setup.py", line 111, in ?
    setup_package()
  File "setup.py", line 90, in setup_package
    config_list += map(get_separate_package_config,separate_packages)
  File "setup.py", line 74, in get_separate_package_config
    return get_package_config(name,'')
  File "setup.py", line 67, in get_package_config
    mod = __import__('setup_'+os.path.basename(name))
ImportError: No module named setup_scipy_distutils

I clearly have a setup_scipy_distutils in my 
/usr/lib/python2.2/site-packages/scipy_distutils, so I don't know why I 
am getting this error.  I hope someone can clarify this for me.

Has anyone ever tried putting together rpm packages?

Thanks,
Chris Fonnesbeck



From pearu at cens.ioc.ee  Sat Mar 29 13:13:57 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 29 Mar 2003 20:13:57 +0200 (EET)
Subject: [SciPy-user] cannot build SciPy on Redhat 8.0
In-Reply-To: <3E85DF85.7090100@fonnesbeck.org>
Message-ID: <Pine.LNX.4.21.0303292004520.18248-100000@cens.kybi>

On Sat, 29 Mar 2003, Christopher Fonnesbeck wrote:

> Hi folks,
> 
> I am trying to build SciPy on a new installation of RedHat 8.0, but am 
> ahving trouble getting out of the gate.  I have installed all of the 
> prerequisite packages, but when I try and run "python setup.py install", 
> I get the following:
> 
> Traceback (most recent call last):
>   File "setup.py", line 111, in ?
>     setup_package()
>   File "setup.py", line 90, in setup_package
>     config_list += map(get_separate_package_config,separate_packages)
>   File "setup.py", line 74, in get_separate_package_config
>     return get_package_config(name,'')
>   File "setup.py", line 67, in get_package_config
>     mod = __import__('setup_'+os.path.basename(name))
> ImportError: No module named setup_scipy_distutils
> 
> I clearly have a setup_scipy_distutils in my 
> /usr/lib/python2.2/site-packages/scipy_distutils, so I don't know why I 
> am getting this error.  I hope someone can clarify this for me.

The recent scipy tar-ball (SciPy-0.2.0_alpha_196.4120_src.tar.gz)
is incomplete, it lacks few setup*.py files and a bunch of freetype
and xplt *.c and *.h files. 

Either wait for the next tar-ball or download scipy from CVS.

The latter is always more reliable (you'll never miss any files) but it's
good if someone tests ;) also distutils generated tar-balls (that
occasionally turn up to be incomplete).

Pearu



From nadavh at visionsense.com  Sun Mar 30 03:41:49 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Sun, 30 Mar 2003 10:41:49 +0200
Subject: [SciPy-user] SciPy and PyGSL
Message-ID: <3E86ADCD.7020509@visionsense.com>

As much as I know, a wrapper around a GPL library should not be 
"infected" by the GPL, since it
does not include a copy of the GPLed source code.

Am I wrong?

  Nadav.

>"RM" == Richard Muller <rpm at wag.caltech.edu> writes:
>  
>
>
>    RM> I've been spending a little time getting to know the Gnu
>    RM> Scientific Library. It shares a lot of the strengths with
>    RM> SciPy. I notice that there is a fledgling effort to make
>    RM> python wrappers to the GSL, and I now wonder how the SciPy
>    RM> community sees such an effort: competition, fellow warriors,
>    RM> or potential successor?
>
>    RM> I for one would like to see the GSL become more of a standard
>    RM> in the scientific computing field, so I'd like to see PyGSL
>    RM> get support. But not necessarily at the expense of
>    RM> SciPy. Thoughts?
>
>IIRC, the biggest issue with GSL is the GPL license.  SciPy uses a BSD
>style license.  Since the GPL is so restrictive, if SciPy even linked
>to libgsl, SciPy would need to be released as GPL.  Dual licensing as
>GPL/BSD is meaningless.
>
> We are the Borg of FSF, non-GPL is futile, you will be GPL'd! 
>
>Sorry could not resist that one!
>
>cheers,
>prabhu
>
>--__--__--
>



From prabhu at aero.iitm.ernet.in  Sun Mar 30 04:00:06 2003
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sun, 30 Mar 2003 14:30:06 +0530
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <3E86ADCD.7020509@visionsense.com>
References: <3E86ADCD.7020509@visionsense.com>
Message-ID: <16006.45590.42578.457385@monster.linux.in>

>>>>> "NH" == Nadav Horesh <nadavh at visionsense.com> writes:

    NH> As much as I know, a wrapper around a GPL library should not
    NH> be "infected" by the GPL, since it does not include a copy of
    NH> the GPLed source code.

    NH> Am I wrong?

Yes, I think you are.  As I understand it, the GPL says that any
"derived work" or a "work based" on the GPL'd program/library should
be released under GPL.  A typical example is the readline library.
Lets say you have a program that simulates the atmosphere.  If you
simply link your app to the readline library then your atmosphere
simulation code has to be released as GPL.  This is the big trouble
with the GPL as against the LGPL that allows you to link your
application.  However, even the definition of "linking" can become a
littlw wishy-washy when it comes to something like Python modules.

One other problem with the GPL is that its a very complex license and
the entier license is about 340 lines of text.  Compare this to the
BSD license which is 26 lines of text.

The GPL license does have its advantages but its certainly not
suitable for SciPy which has made a concious decision to go with a BSD
style license.

cheers,
prabhu


From bsder at allcaps.org  Sun Mar 30 06:13:06 2003
From: bsder at allcaps.org (Andrew P. Lentvorski, Jr.)
Date: Sun, 30 Mar 2003 03:13:06 -0800 (PST)
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <3E86ADCD.7020509@visionsense.com>
Message-ID: <Pine.LNX.4.44.0303300243250.21757-100000@mail.allcaps.org>

On Sun, 30 Mar 2003, Nadav Horesh wrote:

> As much as I know, a wrapper around a GPL library should not be 
> "infected" by the GPL, since it
> does not include a copy of the GPLed source code.
> 
> Am I wrong?
> 

Probably.  The GPL and the LGPL draw different distinctions around this
point.  The LGPL specifically allows linking without incurring a copyleft.  
The GPL does not.  There have been many discussions about this topic in 
the Linux kernel archives concerning binary-only device drivers.

I, personally, believe that scientific libraries really should be licensed
on something BSD-like if for no other reason than you won't need to
persuade the current copyright owner (if you can find that person) 20
years from now to let you do something with unmaintained code that might 
be outside the scope of the original license.

-a




From jack at xiph.org  Sun Mar 30 13:18:20 2003
From: jack at xiph.org (Jack Moffitt)
Date: Sun, 30 Mar 2003 11:18:20 -0700
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <3E86ADCD.7020509@visionsense.com>
References: <3E86ADCD.7020509@visionsense.com>
Message-ID: <20030330181820.GC31055@i.cantcode.com>

> >   RM> I for one would like to see the GSL become more of a standard
> >   RM> in the scientific computing field, so I'd like to see PyGSL
> >   RM> get support. But not necessarily at the expense of
> >   RM> SciPy. Thoughts?
> >
> >IIRC, the biggest issue with GSL is the GPL license.  SciPy uses a BSD
> >style license.  Since the GPL is so restrictive, if SciPy even linked
> >to libgsl, SciPy would need to be released as GPL.  Dual licensing as
> >GPL/BSD is meaningless.

Has anyone asked for _them_ to dual license?  Or change to the LGPL?  In
my experience, many projects are happy to accomodate licensing issues
like this.

jack.


From steven.robbins at videotron.ca  Sun Mar 30 13:57:29 2003
From: steven.robbins at videotron.ca (Steve M. Robbins)
Date: Sun, 30 Mar 2003 13:57:29 -0500
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <20030330181820.GC31055@i.cantcode.com>
References: <3E86ADCD.7020509@visionsense.com>
 <20030330181820.GC31055@i.cantcode.com>
Message-ID: <20030330185729.GD21194@nyongwa.montreal.qc.ca>

On Sun, Mar 30, 2003 at 11:18:20AM -0700, Jack Moffitt wrote:
> > >   RM> I for one would like to see the GSL become more of a standard
> > >   RM> in the scientific computing field, so I'd like to see PyGSL
> > >   RM> get support. But not necessarily at the expense of
> > >   RM> SciPy. Thoughts?
> > >
> > >IIRC, the biggest issue with GSL is the GPL license.  SciPy uses a BSD
> > >style license.  Since the GPL is so restrictive, if SciPy even linked
> > >to libgsl, SciPy would need to be released as GPL.  Dual licensing as
> > >GPL/BSD is meaningless.
> 
> Has anyone asked for _them_ to dual license?  Or change to the LGPL?  

The answer to this is on the GSL web page: http://sources.redhat.com/gsl/
Executive summary: the LGPL was specifically rejected in favour of
the GPL.

-S

P.S. I'm pretty sure that the reasons for this choice can be found in
the archives of the GSL mailing list.



From Kasper.Souren at ircam.fr  Sun Mar 30 17:41:14 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Sun, 30 Mar 2003 22:41:14 +0000
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <16004.28347.150885.202870@monster.linux.in>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu> <16004.28347.150885.202870@monster.linux.in>
Message-ID: <200303302241.14760.Kasper.Souren@ircam.fr>

> IIRC, the biggest issue with GSL is the GPL license.  SciPy uses a BSD
> style license.  Since the GPL is so restrictive, if SciPy even linked
> to libgsl, SciPy would need to be released as GPL.  Dual licensing as
> GPL/BSD is meaningless.

Why exactly is (or: do you find?) GPL/BSD meaningless?
KDE and OpenOffice.org use a GPL/other license. But the other license is not 
BSD in these cases.

bye,
Kasper


From kern at caltech.edu  Sun Mar 30 19:35:52 2003
From: kern at caltech.edu (Robert Kern)
Date: Sun, 30 Mar 2003 16:35:52 -0800
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <200303302241.14760.Kasper.Souren@ircam.fr>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu> <16004.28347.150885.202870@monster.linux.in> <200303302241.14760.Kasper.Souren@ircam.fr>
Message-ID: <20030331003552.GA30181@taliesen.caltech.edu>

On Sun, Mar 30, 2003 at 10:41:14PM +0000, Kasper Souren wrote:
> > IIRC, the biggest issue with GSL is the GPL license.  SciPy uses a BSD
> > style license.  Since the GPL is so restrictive, if SciPy even linked
> > to libgsl, SciPy would need to be released as GPL.  Dual licensing as
> > GPL/BSD is meaningless.
> 
> Why exactly is (or: do you find?) GPL/BSD meaningless?
> KDE and OpenOffice.org use a GPL/other license. But the other license is not 
> BSD in these cases.

I am not a lawyer.

One only needs to GPL/New-Whiz-Bang-License dual-license if
New-Whiz-Bang-License is not GPL compatible. The BSD license (in its
current incarnation) is GPL compatible.

Linking to GSL should not be enough to force SciPy to be licensed as
GPL. One is explicitly allowed to link differently licensed code as long
as the other license is GPL compatible. However, the whole work needs to
be distributed in a manner consistent with the GPL (meaning source for
GSL as well as the source for the wrapper itself). One could, then, fork
the wrapper code to, say, link to a compatible BSD library and release the
forked wrapper with the BSD library as binaries only. For example, the
Python Standard Library contains the mpz module which normally links to
the GNU MP library which (IIRC) used to be GPLed (now LGPLed). It could
also link to a BSD library which was compatible with GNU MP. Ditto for
readline.

However, linking a BSD wrapper to a GPLed library causes similar
problems as GPLing the wrapper or SciPy, so the point is moot.

> bye,
> Kasper

-- 
Robert Kern
kern at caltech.edu

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


From chris at fonnesbeck.org  Sun Mar 30 23:10:36 2003
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Sun, 30 Mar 2003 23:10:36 -0500
Subject: [SciPy-user] strange weave.inline errors in weave using gcc3.2
Message-ID: <3E87BFBC.2080708@fonnesbeck.org>

I have installed weave from cvs, and with gcc3.2 all of the tests run 
fine. However, when I run it with some of my code, Bad Things happen. 
Here are the relevant parts of the code, followed by the error messages:

         code = '''
         #line 610 "ReinforcementLearning.py"

         PyObject *key, *qval, *traceval = NULL;
         Py::List keys = qfunction.keys();
         for (int i=0; i<keys.length(); i++) {
             key = PyList_GET_ITEM(keys.ptr(),i);

             /* Grab and convert current Q-value */
             qval = PyDict_GetItem(qfunction.ptr(),key);
             double qval_raw = py_to_float(qval,"qval_raw");

             /* Grab and convert current elegibility value */
             traceval = PyDict_GetItem(etrace.ptr(),key);
             double traceval_raw = py_to_float(traceval,"traceval_raw");

             /* Calculate new Q-value */
             qval_raw += alpha * delta * traceval_raw;

             /* Return new Q-value to Q-function */
             PyObject* qval_new = PyFloat_FromDouble(qval_raw);
             PyDict_SetItem( qfunction.ptr(),
               key, qval_new );

             /* Cleanup */
             Py_DECREF(qval_new);

             /* Only update nonzero e-trace values */
             if (traceval_raw>0.0) {

                 /* Only interested in sizeable values */
                 if (traceval_raw>=tolerance) {

                     /* Calculate new elegibility value */
                     traceval_raw = gamma * lamda * traceval_raw;

                     /* Return new elegibility value to trace */
                     PyObject* traceval_new = 
PyFloat_FromDouble(traceval_raw);
                     PyDict_SetItem( etrace.ptr(),
                       key, traceval_new );

                     /* Cleanup */
                     Py_DECREF(traceval_new);
                 }
                 /* Set very small values to zero */
                 else PyDict_SetItem( etrace.ptr(), key,
                   PyFloat_FromDouble(0.0) );
             }
        }
         '''

         'Call to weave'
         weave.inline(code,
                      ['qfunction',
                       'alpha','delta','etrace',
                       'gamma','lamda','tolerance'])

This yields:


ReinforcementLearning.py: In function `PyObject* compiled_func(PyObject*,
    PyObject*)':
ReinforcementLearning.py:612: `Py' undeclared (first use this function)
ReinforcementLearning.py:612: (Each undeclared identifier is reported 
only once
    for each function it appears in.)
ReinforcementLearning.py:612: parse error before `::' token
ReinforcementLearning.py:613: `keys' undeclared (first use this function)
ReinforcementLearning.py:617: no matching function for call to 
`py::dict::ptr()
    '
ReinforcementLearning.py:621: no matching function for call to 
`py::dict::ptr()
    '
ReinforcementLearning.py:629: no matching function for call to 
`py::dict::ptr()
    '
ReinforcementLearning.py:646: no matching function for call to 
`py::dict::ptr()
    '
ReinforcementLearning.py:653: no matching function for call to 
`py::dict::ptr()
    '
Traceback (most recent call last):
   File "ReinforcementLearning.py", line 931, in __call__
     s==maxsteps-1)
   File "ReinforcementLearning.py", line 678, in update_qfunction
     ['qfunction',
   File "/usr/lib/python2.2/site-packages/weave/inline_tools.py", line 
335, in inline
     auto_downcast = auto_downcast,
   File "/usr/lib/python2.2/site-packages/weave/inline_tools.py", line 
439, in compile_function
     verbose=verbose, **kw)
   File "/usr/lib/python2.2/site-packages/weave/ext_tools.py", line 340, 
in compile
     verbose = verbose, **kw)
   File "/usr/lib/python2.2/site-packages/weave/build_tools.py", line 
272, in build_extension
     setup(name = module_name, ext_modules = [ext],verbose=verb)
   File "/usr/lib/python2.2/site-packages/scipy_distutils/core.py", line 
42, in setup
     return old_setup(**new_attr)
   File "//usr/lib/python2.2/distutils/core.py", line 157, in setup
     raise SystemExit, "error: " + str(msg)
CompileError: error: command 'gcc' failed with exit status 1


Any ideas what is happening?

-- 
Christopher J. Fonnesbeck (chris at fonnesbeck.org)
GA Coop. Fish & Wildlife Research Unit, University of Georgia

Oh my friend, what a time is this
To trade the handshake for the fist
	-- Joni Mitchell



From chris at fonnesbeck.org  Sun Mar 30 23:59:52 2003
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Sun, 30 Mar 2003 23:59:52 -0500
Subject: [SciPy-user] never mind ...
Message-ID: <3E87CB48.4030307@fonnesbeck.org>

I referred to some of the updated examples and saw that things like 
mydict.ptr() are no longer used. My updated code now compiles, with only 
the following warning:

exceptions.ImportError: 
/usr/lib/python2.2/site-packages/scipy/linalg/_flinalg.so: undefined 
symbol: dlaswp_

Cheers,
cjf

-- 
Christopher J. Fonnesbeck (chris at fonnesbeck.org)
GA Coop. Fish & Wildlife Research Unit, University of Georgia

Oh my friend, what a time is this
To trade the handshake for the fist
	-- Joni Mitchell



From pearu at cens.ioc.ee  Mon Mar 31 03:00:45 2003
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 31 Mar 2003 11:00:45 +0300 (EEST)
Subject: [SciPy-user] never mind ...
In-Reply-To: <3E87CB48.4030307@fonnesbeck.org>
Message-ID: <Pine.LNX.4.21.0303311047420.22661-100000@cens.kybi>

On Sun, 30 Mar 2003, Christopher Fonnesbeck wrote:

> I referred to some of the updated examples and saw that things like 
> mydict.ptr() are no longer used. My updated code now compiles, with only 
> the following warning:
> 
> exceptions.ImportError: 
> /usr/lib/python2.2/site-packages/scipy/linalg/_flinalg.so: undefined 
> symbol: dlaswp_

Assuming that you are using the latest scipy CVS, then hmmm. When using
weave alone, scipy should not have been loaded. Even if scipy
is imported, scipy.linalg (including _flinalg.so) is not loaded
until scipy.linalg is acctually used (e.g. some linalg function is called
or its __doc__ is accessed). So, I am bit curious why this import error
occurs at all.

Anyway, the import error above indicates that something is wrong with
using lapack library, see the troubleshooting section in
scipy/INSTALL.txt.

Pearu



From prabhu at aero.iitm.ernet.in  Mon Mar 31 12:15:34 2003
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Mon, 31 Mar 2003 22:45:34 +0530
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <20030331003552.GA30181@taliesen.caltech.edu>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu>
	<16004.28347.150885.202870@monster.linux.in>
	<200303302241.14760.Kasper.Souren@ircam.fr>
	<20030331003552.GA30181@taliesen.caltech.edu>
Message-ID: <16008.30646.336536.819502@monster.linux.in>

>>>>> "RK" == Robert Kern <kern at caltech.edu> writes:

[snip]

    >> Why exactly is (or: do you find?) GPL/BSD meaningless?  KDE and
    >> OpenOffice.org use a GPL/other license. But the other license
    >> is not BSD in these cases.

    RK> I am not a lawyer.

    RK> One only needs to GPL/New-Whiz-Bang-License dual-license if
    RK> New-Whiz-Bang-License is not GPL compatible. The BSD license
    RK> (in its current incarnation) is GPL compatible.

To clarify this a little, the compatibility works one way and not the
other way.  BSD is compatible with GPL but not vice-versa.  i.e. I
dont think you can create a BSD application that links to or uses
(derives) from a GPL'd lib/app without forcing the BSD app to release
its sources under the GPL.  By dual licensing software under GPL and
BSD you basically go completely against what the GPL stands for.  I
think Qt and Mozilla folks use dual licensing to keep the GPL folks
happy.  I'm sure RMS would sneer at dual licensing (not that it
matters though).

    RK> Linking to GSL should not be enough to force SciPy to be
    RK> licensed as GPL. One is explicitly allowed to link differently
    RK> licensed code as long as the other license is GPL
    RK> compatible. However, the whole work needs to be distributed in

Indeed, but I'm not sure there exists a license (apart from the GPL
itself) that is compatible with the GPL -- i.e. something that can
link to a GPL'd library?  Certainly the BSD is incompatible for it
explicitly allows commercial versions without releasing the sources.

    RK> a manner consistent with the GPL (meaning source for GSL as
    RK> well as the source for the wrapper itself). One could, then,

Its not just making the source available.  Its also making it
available with the same "freedoms".  i.e. no one but the copyright
holders can *distribute* modified code without releasing the source.
One can make private modifications so long as these are not
distributed or sold.

    RK> fork the wrapper code to, say, link to a compatible BSD
    RK> library and release the forked wrapper with the BSD library as

I'm not sure this will work because at some point you need to link a
BSD library to a GPL'd one which will violate something in the GPL
license.  Even if you did distribute the wrapper as binary only you
would have to make its source available and linking to the wrapper
from the BSD library would still be linking to a GPL wrapper.  So I
don't see a way out of this.  If it were so easy we would not have the
LGPL. :)

    RK> binaries only. For example, the Python Standard Library
    RK> contains the mpz module which normally links to the GNU MP
    RK> library which (IIRC) used to be GPLed (now LGPLed). It could
    RK> also link to a BSD library which was compatible with GNU
    RK> MP. Ditto for readline.

Yes, but in this case mp and readline are simply Python modules
distributed along with Python and compiled at the discretion of the
user.  Python itself does not require either.  So its somewhat like
bundling incompatible pieces together (which the GPL does allow).
However, if SciPy were to use GSL, I'm guessing that it would be a
fundamentally important part of it and one that could not be easily
separated so I doubt that it would be easy to argue that GSL is simply
bundled with SciPy for the user to optionally build...

    RK> However, linking a BSD wrapper to a GPLed library causes
    RK> similar problems as GPLing the wrapper or SciPy, so the point
    RK> is moot.

Well, you've lost me here.  Are you saying that the BSD is
incompatible with the GPL then?

cheers,
prabhu


From kern at caltech.edu  Mon Mar 31 16:03:46 2003
From: kern at caltech.edu (Robert Kern)
Date: Mon, 31 Mar 2003 13:03:46 -0800
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <16008.30646.336536.819502@monster.linux.in>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu> <16004.28347.150885.202870@monster.linux.in> <200303302241.14760.Kasper.Souren@ircam.fr> <20030331003552.GA30181@taliesen.caltech.edu> <16008.30646.336536.819502@monster.linux.in>
Message-ID: <20030331210346.GA28070@taliesen.caltech.edu>

On Mon, Mar 31, 2003 at 10:45:34PM +0530, Prabhu Ramachandran wrote:
> >>>>> "RK" == Robert Kern <kern at caltech.edu> writes:
> 
> [snip]
> 
>     >> Why exactly is (or: do you find?) GPL/BSD meaningless?  KDE and
>     >> OpenOffice.org use a GPL/other license. But the other license
>     >> is not BSD in these cases.
> 
>     RK> I am not a lawyer.
> 
>     RK> One only needs to GPL/New-Whiz-Bang-License dual-license if
>     RK> New-Whiz-Bang-License is not GPL compatible. The BSD license
>     RK> (in its current incarnation) is GPL compatible.
> 
> To clarify this a little, the compatibility works one way and not the
> other way.  BSD is compatible with GPL but not vice-versa.  i.e. I
> dont think you can create a BSD application that links to or uses
> (derives) from a GPL'd lib/app without forcing the BSD app to release
> its sources under the GPL. By dual licensing software under GPL and
> BSD you basically go completely against what the GPL stands for.  I
> think Qt and Mozilla folks use dual licensing to keep the GPL folks
> happy.  I'm sure RMS would sneer at dual licensing (not that it
> matters though).
 
Now that I reread http://www.gnu.org/licenses/gpl-faq.html , I think you
are partially right. If one links to a GPLed library, one must release
the new whole work under the GPL. However, you may release *your* code
(e.g. the wrappers) under a compatible license, say the BSD license *in
addition*. Why would you do this? Because you don't want to pass on the
GPL restrictions to everything. You may want your users to be able to
take out the GPLed library and use your code in a proprietary
environment. Or replace that library's functionality with a different
library. 

ObSciPy: FFTW is only one option for FFT libraries. If one were to
distribute a SciPy binary with FFTW, the whole work must be released
under the GPL. However, all the parts that aren't FFTW proper are also
BSD-licensed. If I'm a contractor who's on a project that only needs
linear algebra functions from SciPy, I can rip out the FFTW binary (or
replace it with FFTPACK for completeness) and release my application
(and SciPy) as binaries.

FWIW, "compatibility" is reflexive. Two licenses are compatible iff one
can simultaneously satisfy the requirements of both licenses. Since the
GPL requires that the licenses of other code in the work not apply more
restrictions than the GPL, it sort of trumps all. The BSD license does
not have such a requirement. So BSD code can be combined with GPL code
to form a larger work (which as a whole must be released under the GPL,
but the BSD code can also be released under the BSD at the same time).

C.f. http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible

>     RK> Linking to GSL should not be enough to force SciPy to be
>     RK> licensed as GPL. One is explicitly allowed to link differently
>     RK> licensed code as long as the other license is GPL
>     RK> compatible. However, the whole work needs to be distributed in
> 
> Indeed, but I'm not sure there exists a license (apart from the GPL
> itself) that is compatible with the GPL -- i.e. something that can
> link to a GPL'd library?  Certainly the BSD is incompatible for it
> explicitly allows commercial versions without releasing the sources.

But the BSD license does not force you to pass on that right to the next
person on the chain nor does it require that that right not be taken
away. The GPL places further restrictions on the code, so it works.
Furthermore, the BSD license allows you to relicense the code (the only
way you can make proprietary versions). Of course, you can still pass
along the original BSDed code as *also* under a BSD license, so one can
rip it out and make a GPL-free version.

See http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
for a big list of GPL compatible licenses.

>     RK> a manner consistent with the GPL (meaning source for GSL as
>     RK> well as the source for the wrapper itself). One could, then,
> 
> Its not just making the source available.  Its also making it
> available with the same "freedoms".  i.e. no one but the copyright
> holders can *distribute* modified code without releasing the source.
> One can make private modifications so long as these are not
> distributed or sold.

Conceded.

>     RK> fork the wrapper code to, say, link to a compatible BSD
>     RK> library and release the forked wrapper with the BSD library as
> 
> I'm not sure this will work because at some point you need to link a
> BSD library to a GPL'd one which will violate something in the GPL
> license.  Even if you did distribute the wrapper as binary only you
> would have to make its source available and linking to the wrapper
> from the BSD library would still be linking to a GPL wrapper.  So I
> don't see a way out of this.  If it were so easy we would not have the
> LGPL. :)

I think I covered this further above by dual-licensing the wrapper as
GPL/BSD. I think this is right because one is allowed to aggregate code
of different licenses (assuming compability) and one is also allowed to
rip out parts not GPLed and use them under whatever license those parts
were covered by. See
http://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL (of
course that explicitly mentions only public domain code).

WRT LGPL, the primary motivation for the LGPL is combining GNU libraries
with proprietary software, not GPL-compatible open source software. 

>     RK> binaries only. For example, the Python Standard Library
>     RK> contains the mpz module which normally links to the GNU MP
>     RK> library which (IIRC) used to be GPLed (now LGPLed). It could
>     RK> also link to a BSD library which was compatible with GNU
>     RK> MP. Ditto for readline.
> 
> Yes, but in this case mp and readline are simply Python modules
> distributed along with Python and compiled at the discretion of the
> user.  Python itself does not require either.  So its somewhat like
> bundling incompatible pieces together (which the GPL does allow).

Except that the mpz and readline modules AFAICT, are also under the
Python License, not GPL. And recent Python License versions are GPL
compatible. If I were to make a Python binary linking to GNU MP and GNU
Readline, I'd have to distribute all Python sources as well, but you
could rip out mpz and readline and re-release those binaries under the
Python License.

I could be wrong on this, but general practice seems to agree with me. I
might ping an open source licensing mailing list about this.

> However, if SciPy were to use GSL, I'm guessing that it would be a
> fundamentally important part of it and one that could not be easily
> separated so I doubt that it would be easy to argue that GSL is simply
> bundled with SciPy for the user to optionally build...
>
>     RK> However, linking a BSD wrapper to a GPLed library causes
>     RK> similar problems as GPLing the wrapper or SciPy, so the point
>     RK> is moot.
> 
> Well, you've lost me here.  Are you saying that the BSD is
> incompatible with the GPL then?

No, just that including wrappers for GPL software (unless if it's really
easy to switch out as was done for FFTW) causes a lot of confusion and
uncertainty for people doing commercial work. You and I are pretty
intelligent people, and we have fairly different ideas of what's
required and what isn't.

> cheers,
> prabhu

-- 
Robert Kern
kern at caltech.edu

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


From kern at caltech.edu  Mon Mar 31 20:17:29 2003
From: kern at caltech.edu (Robert Kern)
Date: Mon, 31 Mar 2003 17:17:29 -0800
Subject: [SciPy-user] SciPy and PyGSL
In-Reply-To: <20030331210346.GA28070@taliesen.caltech.edu>
References: <8A3F4169-612D-11D7-9D00-000393B63452@wag.caltech.edu> <16004.28347.150885.202870@monster.linux.in> <200303302241.14760.Kasper.Souren@ircam.fr> <20030331003552.GA30181@taliesen.caltech.edu> <16008.30646.336536.819502@monster.linux.in> <20030331210346.GA28070@taliesen.caltech.edu>
Message-ID: <20030401011729.GA12908@taliesen.caltech.edu>

Actually, now that I've read things over, I think you're right that you
can't dual-license GPL/BSD for wrappers (call them W) of GPL libraries
(call them G) when distributing the work as a whole (W+G). However, I
think it might be permissible to distribute W alone under BSD (and allow
whatever modifications, like linking against a BSD library called B).
Since that's how Python seems to do it with mpz and readline and no one
on debian-legal seems to have complained, then I think it's safe.

But we're getting off-topic. If there are any more issues, let's discuss
them off-list.

-- 
Robert Kern
kern at caltech.edu

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


From Kasper.Souren at ircam.fr  Wed Mar 26 09:49:50 2003
From: Kasper.Souren at ircam.fr (Kasper Souren)
Date: Wed, 26 Mar 2003 15:49:50 +0100
Subject: [SciPy-user] Python-to-Matlab converter ?
In-Reply-To: <002501c2f365$5abe90c0$0101a8c0@poet>
References: <002501c2f365$5abe90c0$0101a8c0@poet>
Message-ID: <200303261549.53418.Kasper.Souren@ircam.fr>

> I guess it is kind of heretic to ask here for such a thing, but my language
> is Matlab.

I don't speak Matlab, but I know a bit about it.

> There are some Phyton-to-C scripts around which I tried to hack and they
> appear to have internal errors or do not work with the latest Python
> version.

What do you need it for? There are many ways to do many things.

If you just would want to pass data, that's easy if you don't mind saving it 
into a file first. Check scipy.io stuff, AFAIK it's compatible with Matlab's 
I/O stuff.

I guess you could also embed Python in Matlab, using mex and Python's 
excellent embedding capabilites.

> Every input or pointer is welcome.

Ok. Then I can't resist to add this one: try to start move your Matlab stuff 
into Python! ;)

bye,
Kasper