Mailman 3 September 2001 - SciPy-Dev

RPMs and source distribution
by Travis Oliphant Dec. 23, 2001

Dec. 23, 2001

I've been playing for hours and finally have it so that python setup.py sdist python setup.by bdist_rpm work as expected. I have distributions and RPM's that I need to put somewhere. Thanks, -Travis

6 14

Re: Scipy-dev digest, Vol 1 #14 - 1 msg
by William Ryu Sept. 30, 2001

Sept. 30, 2001

At 12:01 PM 9/30/2001 -0500, you wrote: >From: Janko Hauser <jhauser(a)ifm.uni-kiel.de> >Date: Sun, 30 Sep 2001 16:21:18 +0200 (CEST) >To: scipy-dev(a)scipy.net >Subject: [SciPy-dev] Documentation and then some >Reply-To: scipy-dev(a)scipy.net > >Hi, I saw the notice for the new documentation and figured that this >is automatically generated stuff (HappyDoc?!). May I ask, if there is >also interest in a type of documentation like the standard python >library reference? Well as an scipy end users, I would love to see such documentation. More documentation the better. :) >As some of you may know, I had once started >something like this for NumPy. I'm willing to revamp this and build at >least a start. I would start with the documentation for the functions >which are the base of scipy (numeric+handy+misc+basic) and then some >of the other modules (I think I have special, signal, stats and fft >already covered). Is the preliminary document you started for NumPy available for download? Regards, -willryu

2 1

Documentation and then some
by Janko Hauser Sept. 30, 2001

Sept. 30, 2001

Hi, I saw the notice for the new documentation and figured that this is automatically generated stuff (HappyDoc?!). May I ask, if there is also interest in a type of documentation like the standard python library reference? As some of you may know, I had once started something like this for NumPy. I'm willing to revamp this and build at least a start. I would start with the documentation for the functions which are the base of scipy (numeric+handy+misc+basic) and then some of the other modules (I think I have special, signal, stats and fft already covered). Interest? Then I noticed that min(),max() are part of basic. This collides with the standard min and max of python. Is this a possible problem? Also I have coded amin(),amax() that if an axis=None is provided a complete minimum/maximum of the array is calculated. Then I would like to have a function which combines a.flat() and ravel() in such a way that where ever possible flat is returned, as ravel makes a copy of the array. To say the truth I have this function :-). def flatten(a): """Returns a rank 1 view of the array a. Does not create a copy if a.iscontiguous() == 1. """ # XXXIMPLEMENTATION: Should perhaps be a special case of ravel, # like ravel(a, savespace=1). if a.iscontiguous() == 1: return a.flat else: return ravel(a) Another question: Seeing scipy placed against Matlab, is there also the idea of a toolbox concept? And a last one: What help regarding the Zope-site is needed? Let me say, that I'm very happy, that scipy looks more and more like the fullfillment of an old idea. With regards, __Janko

1 0

SciPy on Cygwin
by Jochen Küpper Sept. 28, 2001

Sept. 28, 2001

I am trying to compile SciPy (cvs) on latest Cygwin (all packages besides postgresql, irc installed). Anybody got that going? - gcc version 2.95.3-5 (cygwin special) - Python 2.1.1 (#2, Sep 26 2001, 09:32:53) [GCC 2.95.3-5 (cygwin special)] on cygwin - NumPy from cvs as of today The problem I am running into in linalg is that I get compile errors in flapackmodule.c: ,---- | linalg/flapackmodule.c:447: initializer element is not constant | linalg/flapackmodule.c:502: initializer element is not constant | linalg/flapackmodule.c:557: initializer element is not constant | linalg/flapackmodule.c:616: initializer element is not constant `---- The respective code is ,----[flapackmodule.c: 447] | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; `---- I am not sure what to do about that? To get so far I had to do the following changes: a) Add /usr/local/lib to ATLAS search-path: Index: setup.py =================================================================== RCS file: /home/cvsroot/world/scipy/setup.py,v retrieving revision 1.56 diff -u -r1.56 setup.py --- setup.py 2001/09/21 08:29:55 1.56 +++ setup.py 2001/09/27 14:23:14 @@ -96,7 +96,7 @@ local_atlas1 = os.path.join(path,platform[:-1],'atlas') # first look for a system defined atlas directory - dir_search = ['/usr/local/lib/atlas','/usr/lib/atlas', + dir_search = ['/usr/local/lib/atlas','/usr/lib/atlas', '/usr/local/lib', local_atlas0, local_atlas1] for directory in dir_search: if os.path.exists(directory): b) In the cephes module I had to undefine the log2 macro from /usr/include/math.h to make it compile: Index: special/cephes.h =================================================================== RCS file: /home/cvsroot/world/scipy/special/cephes.h,v retrieving revision 1.1 diff -u -r1.1 cephes.h --- special/cephes.h 2001/06/20 05:29:41 1.1 +++ special/cephes.h 2001/09/27 14:19:50 @@ -102,6 +102,9 @@ /* extern int levnsn ( int n, double r[], double a[], double e[], double refl[] ); */ +#ifdef log2 /* some systems have log2 as a macro */ +# undef log2 +#endif extern double log2 ( double x ); /* extern long lrand ( void ); Index: special/cephes/protos.h =================================================================== RCS file: /home/cvsroot/world/scipy/special/cephes/protos.h,v retrieving revision 1.2 diff -u -r1.2 protos.h --- special/cephes/protos.h 2001/07/03 08:32:00 1.2 +++ special/cephes/protos.h 2001/09/27 14:19:50 @@ -101,6 +101,9 @@ extern int levnsn ( int n, double r[], double a[], double e[], double refl[] ); extern double log ( double x ); extern double log10 ( double x ); +#ifdef log2 /* some systems have log2 as a macro */ +# undef log2 +#endif extern double log2 ( double x ); extern long lrand ( void ); extern long lsqrt ( long x ); Any help appreciated... Greetings, Jochen -- University of North Carolina phone: 919-962-4403 Department of Chemistry phone: 919-962-1579 Venable Hall CB#3290 fax: 919-843-6041 Chapel Hill, NC 27599, USA GnuPG key: 44BCCD8E

4 4

Re: Scipy-dev digest, Vol 1 #11 - 1 msg
by Travis Oliphant Sept. 27, 2001

Sept. 27, 2001

> 1. SciPy on Cygwin (Jochen =?iso-8859-1?q?K=FCpper?=) > > --__--__-- > > Message: 1 > To: scipy-dev(a)scipy.net > Cc: Cygwin <cygwin(a)cygwin.com> > From: "Jochen =?iso-8859-1?q?K=FCpper?=" <jochen(a)unc.edu> > Organization: University of North Carolina > Date: 27 Sep 2001 10:26:13 -0400 > Subject: [SciPy-dev] SciPy on Cygwin > Reply-To: scipy-dev(a)scipy.net > > I am trying to compile SciPy (cvs) on latest Cygwin (all packages > besides postgresql, irc installed). Anybody got that going? > > - gcc version 2.95.3-5 (cygwin special) > - Python 2.1.1 (#2, Sep 26 2001, 09:32:53) > [GCC 2.95.3-5 (cygwin special)] on cygwin > - NumPy from cvs as of today > > The problem I am running into in linalg is that I get compile errors > in flapackmodule.c: > ,---- > | linalg/flapackmodule.c:447: initializer element is not constant > | linalg/flapackmodule.c:502: initializer element is not constant > | linalg/flapackmodule.c:557: initializer element is not constant > | linalg/flapackmodule.c:616: initializer element is not constant > `---- > > The respective code is > ,----[flapackmodule.c: 447] > | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; > `---- Well it looks like some more ifdefs are needed. I think there is some DL_EXPORT macro that needs to be used somewhere for it to work on CYGWIN. Because this is an f2py generated file, I'm not sure what to do. Does f2py support Cygwin? -Travis

3 3

scipy.linalg and LAPACK 3.0
by Robert Kern Sept. 6, 2001

Sept. 6, 2001

Hi, Some of the routines wrapped in generic_lapack.pyf seem to be deprecated in LAPACK 3.0, notably _GESVD, which is rather slower than the new _GESDD. Is there a reason for this (e.g. compatibility for people who haven't upgraded their LAPACK, yet), or has simply no-one done the work, yet? If the latter, I'll see what I can come up with and contribute. -- Robert Kern kern(a)caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

2 1

documentation
by Rob Sept. 3, 2001

Sept. 3, 2001

Is there a non-html version of the documentation. Like the Numpy manual, I like to print out the whole thing and keep it as a reference. Plain text would be wonderful. Thanks, Rob. ps. I still can't get the package to compile on FreeBSD, even setting X11=0. It can't find my Fortran compiler f77, even though it exists. -- The Numeric Python EM Project www.members.home.net/europax

1 0

LAPACK is not thread-safe (AFAICT)
by Robert Kern Sept. 3, 2001

Sept. 3, 2001

Disclaimer: I'm not a FORTRAN programmer or a thread expert. In linalg/docs/more_notes, Eric says he knows of no reason that any of the LAPACK functions wouldn't be thread-safe. However, I have run across a USENET discussion saying that some are not thread-safe. Some of the Netlib LAPACK's functions use FORTRAN's SAVE statement to preserve variable values across invocations, and this makes them thread-unsafe (AFAICT). C.f. http://groups.google.com/groups?q=LAPACK+thread&hl=en&safe=off&rnum=1&selm=… The affected routines are dlacon, dlaed6, dlamch, dlartg, dlasq3, dlasq4, zlacon, zlargv, zlartg, and their single-precision equivalents. Also, any function calling one of these functions is not thread-safe either. ATLAS is thread-safe, but of course, not all of the LAPACK routines have been integrated. Some vendor LAPACK libraries appear to be threadsafe. I don't know how useful this information is; I just wanted to throw it out there before someone adds the Py_BEGIN_ALLOW_THREADS to the wrappers. -- Robert Kern kern(a)caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

1 0