From Chuck.Harris at sdl.usu.edu  Thu May  2 17:00:32 2002
From: Chuck.Harris at sdl.usu.edu (Chuck Harris)
Date: Thu, 2 May 2002 15:00:32 -0600
Subject: [SciPy-dev] RE: divided differences
Message-ID: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A80@cobra.usurf.usu.edu>

Hi all,

I have written fortran routines for real and complex interpolation using 
divided differences. The routines use the Steffensen form of evaluation
which zig-zags up the divided difference table in such a way as to 
minimize errors. These routines are essentially as accurate and fast as
the barycentric form of Lagrange interpolation, but without the
singularities. They are *much* more efficient than the Neville form
recommended in Numerical Recipes, and I suggest that the relevant pages
be razored out of that darned book.

f2py is used to generate the interface. What an amazing bit of software!
The complex routines can take real data and work just fine. I have written
both double and complex for efficiency. I intend to write python interfaces 
to call the appropriate routines, but haven't yet done so. The interface also
needs to convert arrays with one element to scalars on return --- maybe: this
could limit its usability as a subroutine, comments?

The routines are called:

make_table_double(xx,yy) -- xx,yy vectors, returns array dd of divided differences
make_table_complex(xx,yy) -- xx,yy vectors, returns array dd of divided differences
interpolate_double(dd,x) -- dd array, x vector, returns vector of interpolated values
interpolate_complex(dd,x) -- dd array, x vector, returns vector of interpolated values

In any case, is there an interest? If so, I suggest that these routines be included
in the interpolation directory, perhaps under a subdirectory DividedDifferences.
Perhaps there should also be a Splines subdirectory?

Chuck


From eric at scipy.org  Thu May  2 16:44:45 2002
From: eric at scipy.org (eric)
Date: Thu, 2 May 2002 16:44:45 -0400
Subject: [SciPy-dev] RE: divided differences
References: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A80@cobra.usurf.usu.edu>
Message-ID: <022c01c1f21a$31864880$6b01a8c0@ericlaptop>

Hey Chuck,

It sounds like you've done your homework on the algorithms here.  That is hugely
appreciated.  I'd like to hear other peoples opinions, but it does sound to me
like these should be in SciPy.  I don't have an opinion though as to whether
they should replace the current interpolation routines, or are they
"alternative" methods.  We should likely have multiple different methods
represented here (even the ones that are "standard but lousy") so that people
can compare to them.  The standard methods for interpolation should be aliased
to the "best in class" of the algorithms for the common class.

If you could build a python wrapper around the fortran versions that chooses the
double or complex version based on the numeric type, that would be good.  I'm
not sure whether the speed of adding a float and float complex version are worth
it.

Pearu, does f2py make a copy of a float array when it passes it into a Fortran
routine expecting a double array?  If so, then the single precision routines
would probably be a win here.  You don't want to have to make an array copy
everytime you want to do an interpolation on float arrays.

Thanks Chuck,

eric

----- Original Message -----
From: "Chuck Harris" <Chuck.Harris at sdl.usu.edu>
To: <scipy-dev at scipy.org>
Sent: Thursday, May 02, 2002 5:00 PM
Subject: [SciPy-dev] RE: divided differences


> Hi all,
>
> I have written fortran routines for real and complex interpolation using
> divided differences. The routines use the Steffensen form of evaluation
> which zig-zags up the divided difference table in such a way as to
> minimize errors. These routines are essentially as accurate and fast as
> the barycentric form of Lagrange interpolation, but without the
> singularities. They are *much* more efficient than the Neville form
> recommended in Numerical Recipes, and I suggest that the relevant pages
> be razored out of that darned book.
>
> f2py is used to generate the interface. What an amazing bit of software!
> The complex routines can take real data and work just fine. I have written
> both double and complex for efficiency. I intend to write python interfaces
> to call the appropriate routines, but haven't yet done so. The interface also
> needs to convert arrays with one element to scalars on return --- maybe: this
> could limit its usability as a subroutine, comments?
>
> The routines are called:
>
> make_table_double(xx,yy) -- xx,yy vectors, returns array dd of divided
differences
> make_table_complex(xx,yy) -- xx,yy vectors, returns array dd of divided
differences
> interpolate_double(dd,x) -- dd array, x vector, returns vector of interpolated
values
> interpolate_complex(dd,x) -- dd array, x vector, returns vector of
interpolated values
>
> In any case, is there an interest? If so, I suggest that these routines be
included
> in the interpolation directory, perhaps under a subdirectory
DividedDifferences.
> Perhaps there should also be a Splines subdirectory?
>
> Chuck
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>




From eric at scipy.org  Thu May  2 23:09:58 2002
From: eric at scipy.org (eric)
Date: Thu, 2 May 2002 23:09:58 -0400
Subject: [SciPy-dev] test_stats.py
Message-ID: <033c01c1f250$01d44ac0$6b01a8c0@ericlaptop>

There were a few import failures in Loius' stats tests due to the scipy_base
rearrangement of modules.  I fixed those so that the tests run again.  The bad
news is that it results in tons of testing errors and 1 or 2 failures on my
Linux box.  Louis, do you have time to look at what is going on?

thanks,
eric

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057





From arnd.baecker at physik.uni-ulm.de  Fri May  3 05:46:51 2002
From: arnd.baecker at physik.uni-ulm.de (arnd.baecker at physik.uni-ulm.de)
Date: Fri, 3 May 2002 11:46:51 +0200 (MEST)
Subject: [SciPy-dev] gsl and scipy
Message-ID: <Pine.SOL.4.44.0205031117240.2753-100000@wega.rz.uni-ulm.de>

Hi,

what is the opinion on including (or making accessible)
the functionality of gsl
(http://sources.redhat.com/gsl/) within scipy ?

I know of pygsl (http://sourceforge.net/projects/pygsl/)
which at present only covers a small part of gsl.

It seems that some of the functionality of gsl
is already within scipy - does this mean that
we would end up with different routines doing the same things ...?

Is there the possibility to use f2py etc. to
generate the necessary wrappers for scipy in an automatic way ?
(on the gsl page they recommend: swig, g-wrap)
How difficult would this be ?

A (slightly) related question: the output of
  help(scipy.special.airy)
is, well, not really helpful.
Would there be any way to attach the information given
at the beginning of  special/cephes/airy.c
to the documentation (again in an automatic way ?)?

Arnd





From Chuck.Harris at sdl.usu.edu  Fri May  3 08:32:29 2002
From: Chuck.Harris at sdl.usu.edu (Chuck Harris)
Date: Fri, 3 May 2002 06:32:29 -0600
Subject: [SciPy-dev] gsl and scipy
Message-ID: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu>

Hi,

> -----Original Message-----
> From: arnd.baecker at physik.uni-ulm.de
> [mailto:arnd.baecker at physik.uni-ulm.de]
> Sent: Friday, May 03, 2002 3:47 AM
> To: scipy-dev at scipy.org
> Subject: [SciPy-dev] gsl and scipy
> 
> 
> Hi,
> 
> what is the opinion on including (or making accessible)
> the functionality of gsl
> (http://sources.redhat.com/gsl/) within scipy ?
> 

Interesting. I downloaded the sources and took a look at some of the routines.
Mixed quality, IMNSHO, and I don't always agree with the design choices ---
but then, any two people would probably disagree on such issues. I think my
divided difference routines are significantly better, for instance, giving
eight extra digits of accuracy for some problems. 

These routines might be a good starting point, and gsl does seem
to provide a comprehensive list of useful software.

Chuck


From jochen at unc.edu  Fri May  3 10:18:08 2002
From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=)
Date: 03 May 2002 10:18:08 -0400
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <Pine.SOL.4.44.0205031117240.2753-100000@wega.rz.uni-ulm.de>
References: <Pine.SOL.4.44.0205031117240.2753-100000@wega.rz.uni-ulm.de>
Message-ID: <ly3cx9tivz.fsf@bock.chem.unc.edu>

On Fri, 3 May 2002 11:46:51 +0200 (MEST) arnd baecker wrote:

arnd> I know of pygsl (http://sourceforge.net/projects/pygsl/)
arnd> which at present only covers a small part of gsl.

Feel free to contribute...

arnd> It seems that some of the functionality of gsl is already within
arnd> scipy - does this mean that we would end up with different
arnd> routines doing the same things ...?

Yep.  But that isn't a bad thing by itself.

arnd> Is there the possibility to use f2py etc. to generate the
arnd> necessary wrappers for scipy in an automatic way ?  (on the gsl
arnd> page they recommend: swig, g-wrap) How difficult would this be ?

Pearu,  that's actually exactly the question I was going to ask for
the last couple of months:)


On Fri, 3 May 2002 06:32:29 -0600 Chuck Harris wrote:

Chuck> Interesting. I downloaded the sources and took a look at some
Chuck> of the routines.  Mixed quality, IMNSHO, and I don't always
Chuck> agree with the design choices --- but then, any two people
Chuck> would probably disagree on such issues. 

If you look into the GSL docs thay actually state more than once that
you can find better solutions to some problems on, e.g., netlib, if
you need the best stuff...  

Chuck> I think my divided difference routines are significantly
Chuck> better, for instance, giving eight extra digits of accuracy for
Chuck> some problems.

Feel free to contribute your better routines.  I am sure Brian is
happy to include everything that matches the GSL idea and is better
than what they have.


The problem some people might see is that GSL is GPL'ed software.  You
cannot put it under a BSD license.  But you can of course provide it
as an optional scipy-module to people that are happy with GPL.

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E



From pearu at scipy.org  Fri May  3 10:15:51 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Fri, 3 May 2002 09:15:51 -0500 (CDT)
Subject: [SciPy-dev] RE: divided differences
In-Reply-To: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A80@cobra.usurf.usu.edu>
Message-ID: <Pine.LNX.4.21.0205030833190.22371-100000@scipy.org>

Hi,

On Thu, 2 May 2002, Chuck Harris wrote:

> f2py is used to generate the interface. What an amazing bit of software!

Thanks!

> The complex routines can take real data and work just fine. I have written
> both double and complex for efficiency. I intend to write python interfaces 
> to call the appropriate routines, but haven't yet done so. The interface also
> needs to convert arrays with one element to scalars on return --- maybe: this
> could limit its usability as a subroutine, comments?

Converting one element arrays to scalars is an overkill for your
routines because they are used mostly to return >1 element arrays, right?

And if other algorithms use these routines (with the scalar conversion
enabled), they must check the return values if they are scalar or array.
This will increase the sizes of codes, I think. This is also one of the
reasons why f2py does not have supporting hooks for
1-element-array-to-scalar conversion when returning arrays.

> The routines are called:
> 
> make_table_double(xx,yy) -- xx,yy vectors, returns array dd of divided differences
> make_table_complex(xx,yy) -- xx,yy vectors, returns array dd of divided differences
> interpolate_double(dd,x) -- dd array, x vector, returns vector of interpolated values
> interpolate_complex(dd,x) -- dd array, x vector, returns vector of interpolated values
> 
> In any case, is there an interest? If so, I suggest that these routines be included
> in the interpolation directory, perhaps under a subdirectory DividedDifferences.
> Perhaps there should also be a Splines subdirectory?

Could you also think about a generic interface to the interpolation
routines?

In addition to your algorithms there is also fitpack and it would be nice
if they can be called using the same generic interface by, say, specifying
a keyword argument for choosing the algorithm or introducing a class of
interpolation methods.... Also this interface can choose which routine to
call based on the types of input data (float,double,complex,..)

I have started similar thing for ODE integrators (see
integrate/ode.py) and therefore I realize that factoring out common
properties of different algorithms with different level of generalizations
and applicability properties is a non-trivial task. But having a generic
interface to all these different algorithms will ease their usage, also
for developers when testing or timing the corresponding codes.

Pearu



From pearu at scipy.org  Fri May  3 10:23:33 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Fri, 3 May 2002 09:23:33 -0500 (CDT)
Subject: [SciPy-dev] RE: divided differences
In-Reply-To: <022c01c1f21a$31864880$6b01a8c0@ericlaptop>
Message-ID: <Pine.LNX.4.21.0205030917550.22371-100000@scipy.org>


On Thu, 2 May 2002, eric wrote:

> Pearu, does f2py make a copy of a float array when it passes it into a Fortran
> routine expecting a double array?  

Yes.

Pearu



From pearu at scipy.org  Fri May  3 10:52:24 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Fri, 3 May 2002 09:52:24 -0500 (CDT)
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <ly3cx9tivz.fsf@bock.chem.unc.edu>
Message-ID: <Pine.LNX.4.21.0205030932580.22371-100000@scipy.org>

On 3 May 2002, Jochen K?pper wrote:

> arnd> Is there the possibility to use f2py etc. to generate the
> arnd> necessary wrappers for scipy in an automatic way ?  (on the gsl
> arnd> page they recommend: swig, g-wrap) How difficult would this be ?
> 
> Pearu,  that's actually exactly the question I was going to ask for
> the last couple of months:)

It is rather straightforward for functions with scalar
(int,float,double,..), *scalar, scalar[] arguments.
 
>From a quick look to gsl I see that in some places it defines complex C
structs that f2py does not support. Some ugly tricks are needed to wrap
these guys. But wrapping the rest (most?) of the gsl with f2py seems
rather trivial. But that is only my first impression, of course ;)

Pearu



From jochen at unc.edu  Fri May  3 11:56:33 2002
From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=)
Date: 03 May 2002 11:56:33 -0400
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <Pine.LNX.4.21.0205030932580.22371-100000@scipy.org>
References: <Pine.LNX.4.21.0205030932580.22371-100000@scipy.org>
Message-ID: <lyhelpql72.fsf@bock.chem.unc.edu>

On Fri, 3 May 2002 09:52:24 -0500 (CDT) pearu  wrote:

arnd> Is there the possibility to use f2py etc. to generate the
arnd> necessary wrappers for scipy in an automatic way ?  (on the gsl
arnd> page they recommend: swig, g-wrap) How difficult would this be ?
>> 
>> Pearu,  that's actually exactly the question I was going to ask for
>> the last couple of months:)

pearu> It is rather straightforward for functions with scalar
pearu> (int,float,double,..), *scalar, scalar[] arguments.

Well, more important, besides the "complex"-problem: What's about
functions taking arrays or function arguments (which in general are
some fancy struct again)?  I.e.
,----
| void gsl_siman_solve (const gsl_rng * R, void *X0_P,
|           gsl_siman_Efunc_t EF, gsl_siman_step_t TAKE_STEP,
|           gsl_siman_metric_t DISTANCE, gsl_siman_print_t
|           PRINT_POSITION, gsl_siman_copy_t COPYFUNC,
|           gsl_siman_copy_construct_t COPY_CONSTRUCTOR,
|           gsl_siman_destroy_t DESTRUCTOR, size_t ELEMENT_SIZE,
|           gsl_siman_params_t PARAMS)
`----

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E



From eric at scipy.org  Fri May  3 11:04:38 2002
From: eric at scipy.org (eric)
Date: Fri, 3 May 2002 11:04:38 -0400
Subject: [SciPy-dev] gsl and scipy
References: <Pine.SOL.4.44.0205031117240.2753-100000@wega.rz.uni-ulm.de>
Message-ID: <03a101c1f2b3$d85c25f0$6b01a8c0@ericlaptop>

Hey Chuck,

I haven't looked at the GSL to hard, but it sounds like a nice library.  Travis
Oliphant posted a comparison of what is in gsl to what is in SciPy sometime
earlier last year.  A link to the comparison is here:

http://groups.google.com/groups?q=oliphant+gsl&hl=en&selm=Pine.LNX.4.33L2.011126
1458540.340-100000%40oliphant.ee.byu.edu&rnum=1

I've also pasted it below since the link is so stinkin long...

His conclusion was that the GSL has more functionality in several areas but not
much.  Also, there are several places that SciPy has more functionality like the
stats package.

The problem with including the GSL in SciPy is the licensing their licenses
don't mix (GPL and BSD).  Since there is already a PyGSL effort, I don't think
this is that big of a problem.  Both can advance independent of one another.
Thanks to Python's modularity, I'm pretty sure they'll interoperate without much
problem.

I'm glad to here your divided differences methods are so solid.  opefully the
other areas of SciPy will hold up just as well in comparisons.  If they don't,
we need to fix them.

eric


-------------------- Travis' post -------------------------
THE GSL
=============

Many of the GSL routines are already in SciPy.  Here is a detailed list:
The outline parallels the GSL reference.


Mathematical Functions:
     * Constants: Constants are easily defined, but presently
                  pi, e, inf, nan, are defined.
     * Elementary Functions:  from Numeric
     * Small integer powers:  from Numeric
     * Testing the sign of numbers: sign
     * Testing for odd and even numbers:  x % 2 == 0
     * Maximum and minimum functions:  max, min, amax, amin

Complex Numbers:  all handled by Numeric including inverse hyperbolic
                  functions


Roots of Polynomials:
           polynomials are represented by sequences of coefficients
     * Polynomial Evaluations:  polyval, polyder
     * Quadratic Equations:  (not specifically) --- see roots
     * Cubic equations:  (not specificially) --- see roots
     * General polynomial:  roots

Special Functions:  (all defined over arrays for Numeric).
        (using special.general_function any function which returns a
          scalar can be converted to broadcast over arrays).
     * Airy functions: yes (no zeros)
     * Bessel functions: yes (no zeros, or spherical bessel)
     * Clausen functions: not specifically (but dilogarithm is there --
         not for complex numbers though, spence.)
     * Coulomb functions: no
     * Coupling Coefficients: no
     * Dawson function: dawsn
     * Debye Functions: no
     * Dilogarithm: spence (no complex argument)
     * Elliptic integrals: yes
     * Elliptic functions: yes
     * Error functions: yes
     * Exponential functions: yes
     * Exponential integrals: yes
     * Fermi-Dirac integrals: don't think so
     * Gamma functions: yes
     * Gegenbauer functions: yes (through scipy.integrate.orthogonal)
     * Hypergeometric functions: yes
     * Laguerre functions: yes (through scipy.integrate.orthogonal)
     * Lambert W Functions: no
     * Legendre Functions: yes
     * Spherical Harmonics: (not directly)
     * Logarithm: yes
     * Power functions: yes
     * Psi (digamma): yes
     * Synchrotron: no
     * Transport: no
     * Trigonometric: yes
     * Zeta: yes


Vectors and Matrices:  Numeric (Matrix)

Permutations:  Not specifically

Sorting:  sort, argsort

BLAS interface: linalg.cblas, linalg.fblas

Linear Algebra: (linalg) --- interface to LAPACK
     * LU: yes
     * QR: yes
     * SVD: yes
     * Cholesky: yes
     * Tridiagonal decomposition (Schur): yes
     * Bidiaonlization: not sure (is this in LAPACK?)
     * Householder solve (through lapack)
     * tridiagonal systems: no

Eigensystems: yes

Fast Fourier Transforms: yes

Numerical Integration: yes (all)

Random Number Generation: yes (RandomArray)

Quasi-Random Sequences: (random in standard library?)

Random Number Distributions: many (RandomArray) -- not all

Statistics:  most of these and more

Histograms: yes (not 2-D though)

N-tuples:  yes, from Python

Monte-Carlo Integration: no

Simulated Annealing: no

Ordinary Differential equations: yes

Interpolation: yes

Numerical Differentition: yes

Chebyshev Approximations: no

Series Accelerations: no

Discrete Hankel Transforms: no

Root-Finding: yes (multi-dimensional)

Optimization: yes (multi-dimensional)

Least-squares fitting: yes

Nonlinear least-squares fitting: yes

Physical constants: no  (easily defined)

IEEE floating-point arithmetic:  relies on platform


So, asided from a few specialized applications, most everything in the
GSL is already included in SciPy.  It wouldn't take long to add the extra
functionality if there were a demand for it.

Any takers?

-Travis

----- Original Message -----
From: <arnd.baecker at physik.uni-ulm.de>
To: <scipy-dev at scipy.org>
Sent: Friday, May 03, 2002 5:46 AM
Subject: [SciPy-dev] gsl and scipy


> Hi,
>
> what is the opinion on including (or making accessible)
> the functionality of gsl
> (http://sources.redhat.com/gsl/) within scipy ?
>
> I know of pygsl (http://sourceforge.net/projects/pygsl/)
> which at present only covers a small part of gsl.
>
> It seems that some of the functionality of gsl
> is already within scipy - does this mean that
> we would end up with different routines doing the same things ...?
>
> Is there the possibility to use f2py etc. to
> generate the necessary wrappers for scipy in an automatic way ?
> (on the gsl page they recommend: swig, g-wrap)
> How difficult would this be ?
>
> A (slightly) related question: the output of
>   help(scipy.special.airy)
> is, well, not really helpful.
> Would there be any way to attach the information given
> at the beginning of  special/cephes/airy.c
> to the documentation (again in an automatic way ?)?
>
> Arnd
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>




From Chuck.Harris at sdl.usu.edu  Fri May  3 12:23:06 2002
From: Chuck.Harris at sdl.usu.edu (Chuck Harris)
Date: Fri, 3 May 2002 10:23:06 -0600
Subject: [SciPy-dev] gsl and scipy
Message-ID: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A82@cobra.usurf.usu.edu>

> ,----
> | void gsl_siman_solve (const gsl_rng * R, void *X0_P,
> |           gsl_siman_Efunc_t EF, gsl_siman_step_t TAKE_STEP,
> |           gsl_siman_metric_t DISTANCE, gsl_siman_print_t
> |           PRINT_POSITION, gsl_siman_copy_t COPYFUNC,
> |           gsl_siman_copy_construct_t COPY_CONSTRUCTOR,
> |           gsl_siman_destroy_t DESTRUCTOR, size_t ELEMENT_SIZE,
> |           gsl_siman_params_t PARAMS)
> `----
> 
> Greetings,
> Jochen
> -- 

Ouch... That's what I meant about design. In numerical stuff, I feel that classes
should be reserved for the top level and made out of simple components that use 
standard data types, i.e., arrays and scalars. That way pieces can be pulled out
and reused or modified without bringing along tons of supporting cruft.

Chuck


From pearu at cens.ioc.ee  Fri May  3 14:22:40 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 3 May 2002 21:22:40 +0300 (EEST)
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <lyhelpql72.fsf@bock.chem.unc.edu>
Message-ID: <Pine.LNX.4.21.0205032022540.3072-100000@cens.ioc.ee>

On 3 May 2002, Jochen K?pper wrote:

> On Fri, 3 May 2002 09:52:24 -0500 (CDT) pearu  wrote:
> 
> arnd> Is there the possibility to use f2py etc. to generate the
> arnd> necessary wrappers for scipy in an automatic way ?  (on the gsl
> arnd> page they recommend: swig, g-wrap) How difficult would this be ?
> >> 
> >> Pearu,  that's actually exactly the question I was going to ask for
> >> the last couple of months:)
> 
> pearu> It is rather straightforward for functions with scalar
> pearu> (int,float,double,..), *scalar, scalar[] arguments.
> 
> Well, more important, besides the "complex"-problem: What's about
> functions taking arrays or function arguments (which in general are
> some fancy struct again)?  I.e.
> ,----
> | void gsl_siman_solve (const gsl_rng * R, void *X0_P,
> |           gsl_siman_Efunc_t EF, gsl_siman_step_t TAKE_STEP,
> |           gsl_siman_metric_t DISTANCE, gsl_siman_print_t
> |           PRINT_POSITION, gsl_siman_copy_t COPYFUNC,
> |           gsl_siman_copy_construct_t COPY_CONSTRUCTOR,
> |           gsl_siman_destroy_t DESTRUCTOR, size_t ELEMENT_SIZE,
> |           gsl_siman_params_t PARAMS)
> `----

Function arguments are fine for f2py provided that they are
expected to take only scalar or array arguments.

So, let me restate what f2py can wrap:

  C/Fortran functions with scalar[+], array[++], 
      and function [*] arguments
  Global C structs [**]/Fortran COMMON blocks
  Fortran F90 module subroutines/functions
  Fortran F90 module data

[+] scalar is C char, short, int, long, float, double, {float,float},
    {double,double}
[++] array is a pointer of a scalar type, eg. *int, *double, etc.
[*] with only scalar and array arguments
[**] containing only scalars and arrays

For some "fancy" C functions it is possible to write simple interface
functions that fall into the category that f2py can wrap.

For anything else f2py is silent.

Regards,
	Pearu



From arnd.baecker at physik.uni-ulm.de  Fri May  3 15:18:44 2002
From: arnd.baecker at physik.uni-ulm.de (arnd.baecker at physik.uni-ulm.de)
Date: Fri, 3 May 2002 21:18:44 +0200 (MEST)
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <ly3cx9tivz.fsf@bock.chem.unc.edu>
Message-ID: <Pine.SOL.4.44.0205032059170.17164-100000@wega.rz.uni-ulm.de>

On 3 May 2002, Jochen K?pper wrote:

> On Fri, 3 May 2002 11:46:51 +0200 (MEST) arnd baecker wrote:
>
> arnd> I know of pygsl (http://sourceforge.net/projects/pygsl/)
> arnd> which at present only covers a small part of gsl.
>
> Feel free to contribute...

Well, I am not sure if I know enough about all this yet
(leaving alone the time aspect ... ;-). My impression is
that gsl would be worth the effort.

> arnd> It seems that some of the functionality of gsl is already within
> arnd> scipy - does this mean that we would end up with different
> arnd> routines doing the same things ...?
>
> Yep.  But that isn't a bad thing by itself.

Indeed, not at all - having different algorithms
is sometimes quite helpful...

[...]

> The problem some people might see is that GSL is GPL'ed software.  You
> cannot put it under a BSD license.  But you can of course provide it
> as an optional scipy-module to people that are happy with GPL.

Hmm, coming from the academic world this licensing stuff appears
annoying to me.

So this basically means, that pygsl will stay separate
from scipy, right ?
In principle this should be no big deal for those who have no
problems with the different licenses.
(it just means that there will be another package out there
with a substantial overlap of scipy's funtionality, according
to the very helpful comparison by Travis).

Personally I think that (at least for me) it boils down
how much time it would cost to write a full wrapper for gsl
(this seems also relevant for future upgrades of gsl).
If most of this could be done automatically, this would be optimal.
Are there any example scripts for f2py2e which could be used to wrap some
bigger library in an automatic way ?
((I havn't had a detailed look at f2py2e, but at first sight
I could not find it ...))

Arnd




From clee at spiralis.merseine.nu  Fri May  3 16:41:28 2002
From: clee at spiralis.merseine.nu (clee at spiralis.merseine.nu)
Date: 03 May 2002 15:41:28 -0500
Subject: [SciPy-dev] scipy graphics wiki/website?
In-Reply-To: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu>
References: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu>
Message-ID: <7uvga5klqf.fsf@spiralis.merseine.nu>

Periodically, I've seen mails go by on the list from people who say they are
either interested in or working on extending the graphics capabilities of
scipy.  Is there a central site for pooling  efforts and information on scipy
graphics?

Is the wiki the place to set something up?  I'm interested in helping with the
effort with a web page or two reviewing what's available for python graphics,
and an RFC/proposal for the underlying image model.


--
Christopher Lee
Washington University Dept. of Anatomy and Neurobiology


From fperez at pizero.colorado.edu  Fri May  3 16:57:32 2002
From: fperez at pizero.colorado.edu (Fernando Perez)
Date: Fri, 3 May 2002 14:57:32 -0600 (MDT)
Subject: [SciPy-dev] scipy graphics wiki/website?
In-Reply-To: <7uvga5klqf.fsf@spiralis.merseine.nu>
Message-ID: <Pine.LNX.4.44.0205031444040.29953-100000@higgs.colorado.edu>

On 3 May 2002 clee at spiralis.merseine.nu wrote:

> Periodically, I've seen mails go by on the list from people who say they are
> either interested in or working on extending the graphics capabilities of
> scipy.  Is there a central site for pooling  efforts and information on scipy
> graphics?
> 
> Is the wiki the place to set something up?  I'm interested in helping with the
> effort with a web page or two reviewing what's available for python graphics,
> and an RFC/proposal for the underlying image model.

Great! Right now all I can do is sideline-cheer, but I think it's great. I 
know the 'core' scipy team is very busy with the architecture right now, and 
there's only so much they can do. But having a central place to reference and 
discuss the issues is a good start. Here's a snippet from an old discussion on 
this which sort of summarizes my view on this:

<quote>
I don't mind that VTK is a complex toolkit: for something to scale well to 
really serious tasks, it better be. Otherwise it will crack open beyond a 
certain point. I think the challenge is writing a tool that:

1) can be easily used from the interactive python command line for 'basic' 2d 
and 3d plotting.

2) has itself a gui for fine tuning of things.

3) is scriptable from python with access to the mid and low-level routines.
</quote>

Cheers,

f



From pearu at scipy.org  Fri May  3 17:51:25 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Fri, 3 May 2002 16:51:25 -0500 (CDT)
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <Pine.SOL.4.44.0205032059170.17164-100000@wega.rz.uni-ulm.de>
Message-ID: <Pine.LNX.4.21.0205031418250.27516-100000@scipy.org>

On Fri, 3 May 2002 arnd.baecker at physik.uni-ulm.de wrote:

> Personally I think that (at least for me) it boils down
> how much time it would cost to write a full wrapper for gsl
> (this seems also relevant for future upgrades of gsl).
> If most of this could be done automatically, this would be optimal.

I think the structure of gsl makes it difficult to automate the wrapping,
at least the parts where functions take struct arguments. See also
previous messages of this thread.

> Are there any example scripts for f2py2e which could be used to wrap some
> bigger library in an automatic way ?
> ((I havn't had a detailed look at f2py2e, but at first sight
> I could not find it ...))

Is lapack library big enough? If yes, then hit [1]:

cd LAPACK-3.0

f2py -c -m lp SRC/*.f -L/path/to/blas/lib -lblas

python
>>> import lp
>>> len(dir(lp))
1306
>>> lp.zlanht('1',4,[1,2,3,2],[4,5,2])
11.0
>>>
;-)

Though I discourage this kind of automatic wrapping (use it for small
libraries or if you want to claim having a complete wrapper to something).

To use the wrappers in an enjoyable way then some effort is needed for
designing the interfaces. For example, one hardly needs all the
functions from a library (usually big libraries contain a number of
auxiliary functions). In addition, C/Fortran functions tend to take many
arguments that are releated to each other -- with some modifications to
signature files one can reduce the number of required arguments
considerably for calling these functions from Python.

For example, scipy/linalg uses f2py2e to wrap LAPACK and BLAS routines
using some helper scripts to reduce the design effort for routines with
the same functionality but with the different types of arguments.

Pearu

[1] I acctually did that. Here follows some useless statistics:
Constructing the wrapper (including reading the source
files and compiling) took approx 30 minutes on an 1GHz Pentium III,
memory consumption was approx. 35MB. The resulting wrapper code
(lapackmodule.c) was 10.5MB in size having 280000 lines of C code, LAPACK 
source itself is only a bit larger.




From eric at scipy.org  Fri May  3 18:32:19 2002
From: eric at scipy.org (eric)
Date: Fri, 3 May 2002 18:32:19 -0400
Subject: [SciPy-dev] scipy graphics wiki/website?
References: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu> <7uvga5klqf.fsf@spiralis.merseine.nu>
Message-ID: <046001c1f2f2$62f511c0$6b01a8c0@ericlaptop>

Hey Christopher,

> Periodically, I've seen mails go by on the list from people who say they are
> either interested in or working on extending the graphics capabilities of
> scipy.

Yes.

> Is there a central site for pooling  efforts and information on scipy
> graphics?

Not at the moment.

> Is the wiki the place to set something up?  I'm interested in helping with the
> effort with a web page or two reviewing what's available for python graphics,
> and an RFC/proposal for the underlying image model.

The short answer here is there is a project already underway that will replace
plt -- its just been started.  Check out the ViewCVS repository on scipy.org and
look for chaco.  I haven't gotten around to writing an announcement or web pages
for this project, as I've been working on architectural issues and a proof of
concept implementation of the low-level API on wxPython and Mac OS X.  I'll put
something together next week though so we can get some discussion going and also
so I can get some help... :-)

see ya,
eric




From clee at spiralis.merseine.nu  Sat May  4 17:25:28 2002
From: clee at spiralis.merseine.nu (clee at spiralis.merseine.nu)
Date: 04 May 2002 16:25:28 -0500
Subject: [SciPy-dev] scipy graphics wiki/website?
In-Reply-To: <046001c1f2f2$62f511c0$6b01a8c0@ericlaptop>
References: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu>
	<7uvga5klqf.fsf@spiralis.merseine.nu>
	<046001c1f2f2$62f511c0$6b01a8c0@ericlaptop>
Message-ID: <7uk7qjbo6v.fsf@spiralis.merseine.nu>

"eric" <eric at scipy.org> writes:

> > Is the wiki the place to set something up?  I'm interested in helping with the
> > effort with a web page or two reviewing what's available for python graphics,
> > and an RFC/proposal for the underlying image model.
> 
> The short answer here is there is a project already underway that will replace
> plt -- its just been started.  Check out the ViewCVS repository on scipy.org and
> look for chaco.  I haven't gotten around to writing an announcement or web pages
> for this project, as I've been working on architectural issues and a proof of
> concept implementation of the low-level API on wxPython and Mac OS X.  I'll put
> something together next week though so we can get some discussion going and also
> so I can get some help... :-)

Great.  I'm checking out the module now.

--
Christopher Lee
Washington University Dept. of Anatomy and Neurobiology


From a.schmolck at gmx.net  Sun May  5 14:32:37 2002
From: a.schmolck at gmx.net (Alexander Schmolck)
Date: 05 May 2002 19:32:37 +0100
Subject: [SciPy-dev] scipy graphics wiki/website?
In-Reply-To: <7uk7qjbo6v.fsf@spiralis.merseine.nu>
References: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu>
	<7uvga5klqf.fsf@spiralis.merseine.nu>
	<046001c1f2f2$62f511c0$6b01a8c0@ericlaptop>
	<7uk7qjbo6v.fsf@spiralis.merseine.nu>
Message-ID: <yfs8z6ybg3e.fsf@black132.ex.ac.uk>

clee at spiralis.merseine.nu writes:

> "eric" <eric at scipy.org> writes:
> 
> > > Is the wiki the place to set something up?  I'm interested in helping with the
> > > effort with a web page or two reviewing what's available for python graphics,
> > > and an RFC/proposal for the underlying image model.
> > 
> > The short answer here is there is a project already underway that will replace
> > plt -- its just been started.  Check out the ViewCVS repository on scipy.org and
> > look for chaco.  I haven't gotten around to writing an announcement or web pages
> > for this project, as I've been working on architectural issues and a proof of
> > concept implementation of the low-level API on wxPython and Mac OS X.  I'll put
> > something together next week though so we can get some discussion going and also
> > so I can get some help... :-)
> 
> Great.  I'm checking out the module now.

That's interesting, I will also need to have a look at this soon.

I've started work some time ago on a sort of uniform matlab-style plotting
interface for python which can (ideally) transparently use different backends
('anyplot' for the moment, in analogy to 'anygui' and 'anydbm'). The only
implemented backends so far are matlab (fairly advanced and useable, in fact
it is what I'm using for my work all the time) and xplt (less powerful and
reliable). I hope to make a first public release sometime next week and get
some feedback.


alex

-- 
Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/



From laytonjb at bellsouth.net  Sun May  5 16:52:51 2002
From: laytonjb at bellsouth.net (Jeff Layton)
Date: Sun, 05 May 2002 16:52:51 -0400
Subject: [SciPy-dev] scipy graphics wiki/website?
References: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A81@cobra.usurf.usu.edu>
		<7uvga5klqf.fsf@spiralis.merseine.nu>
		<046001c1f2f2$62f511c0$6b01a8c0@ericlaptop>
		<7uk7qjbo6v.fsf@spiralis.merseine.nu> <yfs8z6ybg3e.fsf@black132.ex.ac.uk>
Message-ID: <3CD59BA3.D2CC2FBF@bellsouth.net>

Alexander Schmolck wrote:

> clee at spiralis.merseine.nu writes:
>
> > "eric" <eric at scipy.org> writes:
> >
> > > > Is the wiki the place to set something up?  I'm interested in helping with the
> > > > effort with a web page or two reviewing what's available for python graphics,
> > > > and an RFC/proposal for the underlying image model.
> > >
> > > The short answer here is there is a project already underway that will replace
> > > plt -- its just been started.  Check out the ViewCVS repository on scipy.org and
> > > look for chaco.  I haven't gotten around to writing an announcement or web pages
> > > for this project, as I've been working on architectural issues and a proof of
> > > concept implementation of the low-level API on wxPython and Mac OS X.  I'll put
> > > something together next week though so we can get some discussion going and also
> > > so I can get some help... :-)
> >
> > Great.  I'm checking out the module now.
>
> That's interesting, I will also need to have a look at this soon.
>
> I've started work some time ago on a sort of uniform matlab-style plotting
> interface for python which can (ideally) transparently use different backends
> ('anyplot' for the moment, in analogy to 'anygui' and 'anydbm'). The only
> implemented backends so far are matlab (fairly advanced and useable, in fact
> it is what I'm using for my work all the time) and xplt (less powerful and
> reliable). I hope to make a first public release sometime next week and get
> some feedback.

Have you looked at kmatplot? (kmatplot.sourceforge.net)
It's the closest thing I've seen to Matlab's plotting capability.

Good Luck!

Jeff


>
>
> alex
>
> --
> Alexander Schmolck     Postgraduate Research Student
>                        Department of Computer Science
>                        University of Exeter
> A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



From kaustubhkp at hotmail.com  Mon May  6 01:23:28 2002
From: kaustubhkp at hotmail.com (Kaustubh Kalgaonkar)
Date: Mon, 06 May 2002 10:53:28 +0530
Subject: [SciPy-dev] failed to install
Message-ID: <F140CllPF6p0V7nOh9K0000c17d@hotmail.com>

Hi,
   i downloaded the win 32 exe for scipy 0.1 , I have got python 2.2 
installed on my win 2000 machine.
   When i try to install the installation stops at the "Select the python 
installation to use " screen .
   how do i install it.
thanks
kaustubh

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



From oliphant.travis at ieee.org  Mon May  6 17:30:33 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 06 May 2002 15:30:33 -0600
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <Pine.SOL.4.44.0205031117240.2753-100000@wega.rz.uni-ulm.de>
References: <Pine.SOL.4.44.0205031117240.2753-100000@wega.rz.uni-ulm.de>
Message-ID: <1020720635.5828.19.camel@travis>

On Fri, 2002-05-03 at 03:46, arnd.baecker at physik.uni-ulm.de wrote:
> Hi,
> 
> what is the opinion on including (or making accessible)
> the functionality of gsl
> (http://sources.redhat.com/gsl/) within scipy ?
> 
> Is there the possibility to use f2py etc. to
> generate the necessary wrappers for scipy in an automatic way ?
> (on the gsl page they recommend: swig, g-wrap)

Which algorithms from the gsl are you interested in?

I did a detailed comparison some time ago and found only a few that are
not in SciPy (some of those have since been implemented).

> How difficult would this be ?
> 
> A (slightly) related question: the output of
>   help(scipy.special.airy)
> is, well, not really helpful.

Use 

info(scipy.special.airy)

if you have Scipy-0.2 and greater and Python 2.2

What is not helpful about that output? (aside from the fact that
(Ai,Bi,Aip,Bip) is not shown as the output --- due to the autodoc
generator for these ufuncs.

In Python 2.2 help uses a different facility which apparently cannot
read the docstrings of builtin functions (a limititation in my view).


-Travis


> Would there be any way to attach the information given
> at the beginning of  special/cephes/airy.c
> to the documentation (again in an automatic way ?)?
> 
> Arnd
> 
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev




From roybryant at SEVENtwentyfour.com  Mon May  6 19:59:30 2002
From: roybryant at SEVENtwentyfour.com (Roy Bryant)
Date: Mon, 6 May 2002 19:59:30 -0400 
Subject: [SciPy-dev] Broken link in www.scipy.org
Message-ID: <AAE15EBA0A92D511B28400A0C99834D801EAB6F5@MAIL724>

There appears to be a problem on this page of your site.

    On page http://www.scipy.org/site_content/tutorials/build_instructions
    when you click on "here",
    the link to http://www.scipy.org/site_content/tutorials/todo
    gives the error: Not found.

As recommended by the Robot Guidelines, this email is to explain our robot's
activities and to let you know about one of the broken links we encountered.
LinkWalker does not store or publish the content of your pages, but rather
uses the link information to update our map of the World Wide Web.

Are these reports helpful? I'd love some feedback. If you prefer not to
receive these occasional error notices please let me know.

Roy Bryant

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Roy Bryant, roybryant at seventwentyfour.com
 President
 SEVENtwentyfour Inc. ("Always watching the Web")
 http://www.seventwentyfour.com
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


From arnd.baecker at physik.uni-ulm.de  Tue May  7 05:58:27 2002
From: arnd.baecker at physik.uni-ulm.de (arnd.baecker at physik.uni-ulm.de)
Date: Tue, 7 May 2002 11:58:27 +0200 (MEST)
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <1020720635.5828.19.camel@travis>
Message-ID: <Pine.SOL.4.44.0205071122070.13056-100000@wega.rz.uni-ulm.de>

On 6 May 2002, Travis Oliphant wrote:

> On Fri, 2002-05-03 at 03:46, arnd.baecker at physik.uni-ulm.de wrote:
> > Hi,
> >
> > what is the opinion on including (or making accessible)
> > the functionality of gsl
> > (http://sources.redhat.com/gsl/) within scipy ?
> >
> > Is there the possibility to use f2py etc. to
> > generate the necessary wrappers for scipy in an automatic way ?
> > (on the gsl page they recommend: swig, g-wrap)
>
> Which algorithms from the gsl are you interested in?

At present I was not interested in a specific routine
(though there might be some of the additional special functions
of interest at some point...), but more in the conceptual issues of
  a) having a quite interesting library as gsl around
     and the pygsl project to provide the python wrappers for this
     and how these two might work together ...
  b) the question of the automatic wrapping and documentation
     generation for such type of library

> I did a detailed comparison some time ago and found only a few that are
> not in SciPy (some of those have since been implemented).

>From the discussion before, I get the impression that it is easier to
implement these in scipy (if needed) than the wrapping of the full gsl ...

(I will address the issue with help(scipy.special.airy)
in a slightly more general context separately)

Arnd



From arnd.baecker at physik.uni-ulm.de  Tue May  7 06:50:02 2002
From: arnd.baecker at physik.uni-ulm.de (arnd.baecker at physik.uni-ulm.de)
Date: Tue, 7 May 2002 12:50:02 +0200 (MEST)
Subject: help/info, graphical help browser (was:  [SciPy-dev] gsl and scipy)
Message-ID: <Pine.SOL.4.44.0205071202071.13056-100000@wega.rz.uni-ulm.de>

Hi,

this started with my question and Travis answer to it:

> > A (slightly) related question: the output of
> >   help(scipy.special.airy)
> > is, well, not really helpful.
>
> Use
>
> info(scipy.special.airy)
>
> if you have Scipy-0.2 and greater and Python 2.2

Thanks - I fear that I should have know that somehow ...

> What is not helpful about that output? (aside from the fact that
> (Ai,Bi,Aip,Bip) is not shown as the output --- due to the autodoc
> generator for these ufuncs.

That output is indeed helpful - apart from what you just mentioned.
  (there seems to be also a line wrapping issue:
  From the ouput of scipy.info(scipy.special.airy)
  compared with scipy.special.airy.__doc__
  I think the \n should be before "derivative" - but that is _really_ of
  minor importance. Is this text - including the line-wrapping-
  generated automatically ?)

I think it would be good to have
 a) that (Ai,Bi,Aip,Bip)  is shown as the output.
 b) an example (or several examples ;-)

Of course, this should be done for most of the routines, if possible.
Surely b) is something for the future (after 0.2, I'd guess).

Which of course means to write the docs - I think that this
would be a good thing for the users to contribute
(which presumably means to setup a mechanism and some brief guidelines
how to do this ...).

> In Python 2.2 help uses a different facility which apparently cannot
> read the docstrings of builtin functions (a limititation in my view).

I had a look at that recently in a different context and I
think it uses pydoc in the end (please correct me if I am wrong here).
I have no idea how easy it would be to change that ...

More generally  I think that in the long run scipy
needs a good help system (don't get me wrong the
current status is already quite good!).
In particular I would like a graphical help browser
- so that one could type something like
  ghelp
or
  ghelp(topic)
to pop up the graphical help.
The graphical help could/should contain: Package indices,
routine descriptions, examples, cross-references,
further docu, tutorials etc. and a good search engine.
It should be also extensible in an easy
way (for example to cover IPython, etc etc as well).

There are surely many more things to think of ...

Would be Tkinter (with for example tkhtml to browse
html docu) a good choice for this ?
(what about qt, wxPython, anygui (to early, I fear))
((personally, I don't like to use a big browser like
mozilla for this ...))

In any case, is this something which more than one person
finds useful/helpful or even necessary for scipy ?
Would it make sense to discuss the design in more detail here ?

There are some approches which offer some of the
functionality

pydoc -g
dox      http:/dox.berlios.de/
devhelp  http://www.devhelp.net/
'microsoft html help': http://www.orgmf.com.ar/condor/pytstuff.html#python
pyhelp at http://starship.python.net/crew/theller/pyhelp.cgi

Arnd







From jochen at unc.edu  Tue May  7 10:30:10 2002
From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=)
Date: 07 May 2002 10:30:10 -0400
Subject: [SciPy-dev] gsl and scipy
In-Reply-To: <Pine.SOL.4.44.0205071122070.13056-100000@wega.rz.uni-ulm.de>
References: <Pine.SOL.4.44.0205071122070.13056-100000@wega.rz.uni-ulm.de>
Message-ID: <lysn549gjx.fsf@bock.chem.unc.edu>

On Tue, 7 May 2002 11:58:27 +0200 (MEST) arnd baecker wrote:

arnd> At present I was not interested in a specific routine (though
arnd> there might be some of the additional special functions of
arnd> interest at some point...),

And as you know these are wrapped in pygsl already.

arnd> but more in the conceptual issues of
arnd> a) having a quite interesting library as gsl around
arnd> and the pygsl project to provide the python wrappers for this
arnd> and how these two might work together ...

Me too:))

arnd> b) the question of the automatic wrapping and documentation
arnd> generation for such type of library

This would make life much easier in the long run.  But as we discussed
on this list before the design of GSL definitely wasn't made with
Python in mind...
Maybe we'll see an OO implementation of GSL at some point, but even
then it remains to be seen whether that transfers well into Python.

Nevertheless a GPL'ed numerics library in C is really something that
should be around the free software landscape.  The ability of using it
from Pyhon is obvious then too, although I agree that initially a
single effort (ala scipy) is as good of an approach as splitting
efforts.  The latter happened already, though.  And some people might
prefer to use GSL from C and Python in the same project.  (Not saying
you cannot do that with cephes...)

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E



From adamrossbarker at hotmail.com  Tue May  7 11:53:00 2002
From: adamrossbarker at hotmail.com (Adam Barker)
Date: Tue, 07 May 2002 10:53:00 -0500
Subject: [SciPy-dev] Please excuse our dust.
Message-ID: <B8FD628C.20%adamrossbarker@hotmail.com>

Hello All,

First, an introduction:

My name is Adam Barker, and I recently started working with Enthought on the
Scipy project.  I'll be taking care of most of the system administration
tasks for the Scipy website and mailing lists, so if you have any questions,
I'll do my best to answer them in a timely manner.

Second, we're doing a bit of work on the websites and the mailing lists.
Specifically, we're moving them to a different set of machines and a
different service provider this week.  Hopefully the move will be
transparent, but there might be a few hiccups this week as everything gets
finished.  We're going to be conservative with the switchover to avoid
interruption of service if possible.

If you have any questions or comments, or if you find something radically
incorrect with the Scipy websites or mailing lists, please feel free to
contact me at:

adam at enthought.com

Thanks!

Adam



From pearu at cens.ioc.ee  Tue May  7 12:12:50 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 7 May 2002 19:12:50 +0300 (EEST)
Subject: [SciPy-dev] Re: [SciPy-user] Please excuse our dust.
In-Reply-To: <B8FD628C.20%adamrossbarker@hotmail.com>
Message-ID: <Pine.LNX.4.21.0205071854390.28502-100000@cens.ioc.ee>

Hi Adam,

Some time ago I wished to have a scipy-cvs mailing list that recieves
messages when committing stuff to the SciPy CVS repository. See the
thread in
  http://www.scipy.net/pipermail/scipy-dev/2002-February/000577.html

So, do you have plans create such a list? 
Why am I asking all the time for this mailing list is that I have used it
in other projects and found it is extremely useful if more than one person
is working with the CVS repository.

I have sent the information how to do that (the CVS repository part) to
Eric some months ago and if it is lost, I can re-send it to you.

Thanks,
	Pearu

On Tue, 7 May 2002, Adam Barker wrote:

> 
> Hello All,
> 
> First, an introduction:
> 
> My name is Adam Barker, and I recently started working with Enthought on the
> Scipy project.  I'll be taking care of most of the system administration
> tasks for the Scipy website and mailing lists, so if you have any questions,
> I'll do my best to answer them in a timely manner.
> 
> Second, we're doing a bit of work on the websites and the mailing lists.
> Specifically, we're moving them to a different set of machines and a
> different service provider this week.  Hopefully the move will be
> transparent, but there might be a few hiccups this week as everything gets
> finished.  We're going to be conservative with the switchover to avoid
> interruption of service if possible.
> 
> If you have any questions or comments, or if you find something radically
> incorrect with the Scipy websites or mailing lists, please feel free to
> contact me at:
> 
> adam at enthought.com
> 
> Thanks!
> 
> Adam
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
> 




From lluang at yahoo.com  Tue May  7 18:10:18 2002
From: lluang at yahoo.com (Louis Luangkesorn)
Date: Tue, 7 May 2002 15:10:18 -0700 (PDT)
Subject: [SciPy-dev] Re: test_stats.py
In-Reply-To: <033c01c1f250$01d44ac0$6b01a8c0@ericlaptop>
Message-ID: <20020507221018.31713.qmail@web12105.mail.yahoo.com>

Eric

I have a document that I think you ended up making my index page on
the scipy site.  (I forgot just what words you use to describe
that)  I will need to update my version of scipy (do I get it off
of CVS or is there a tarball shapshot or something like that I can
use).  All the errors I get currently involve regression.  The
problem is the test cases I used were actually designed to find
numerical instability, in particular when the numbers involved are
very large or very small.  From looking at the code (I'm not that
good of a stats or numerical person) I think there are a couple of
constants in the stats.py regression code that work when the
numbers are the type used in psychology or survey analysis (i.e.
counting people) but not for large or small numbers.

Could you send the unittest output?  If I knew which tests failed I
can help you some more.

Louis
--- eric <eric at enthought.com> wrote:
> There were a few import failures in Loius' stats tests due to the
> scipy_base
> rearrangement of modules.  I fixed those so that the tests run
> again.  The bad
> news is that it results in tons of testing errors and 1 or 2
> failures on my
> Linux box.  Louis, do you have time to look at what is going on?
> 
> thanks,
> eric
> 
> --
> Eric Jones <eric at enthought.com>
> Enthought, Inc. [www.enthought.com and www.scipy.org]
> (512) 536-1057
> 
> 
> 


=====
When I consider your heavens, the work of your fingers,
the moon and the stars, which you have set in place,
what is man that you are mindful of him, the son of man that you care for him?    Psalm 8:3-4
Y!M, AOL, jabber.com: lluang

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com


From ej at ee.duke.edu  Tue May 14 02:46:18 2002
From: ej at ee.duke.edu (Eric A. Jones)
Date: Tue, 14 May 2002 02:46:18 -0400 (EDT)
Subject: [SciPy-dev] test -- please ignore
Message-ID: <Pine.LNX.4.44.0205140245540.22082-100000@beowulf1.ee.duke.edu>



From adam at enthought.com  Tue May 14 12:13:50 2002
From: adam at enthought.com (Adam Barker)
Date: Tue, 14 May 2002 10:13:50 -0600
Subject: [SciPy-dev] Testing, please ignore.  <EOM>
Message-ID: <002b01c1fb62$593cd410$7501a8c0@drklahn>

Testing.

Adam



From nwagner at mecha.uni-stuttgart.de  Thu May 16 10:46:11 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 16 May 2002 16:46:11 +0200
Subject: [SciPy-dev] [Fwd: quadpack.error: Supplied function does not return a valid float.]
Message-ID: <3CE3C633.2783FF22@mecha.uni-stuttgart.de>

 
-------------- next part --------------
An embedded message was scrubbed...
From: Nils Wagner <nwagner at mecha.uni-stuttgart.de>
Subject: quadpack.error: Supplied function does not return a valid float.
Date: Thu, 16 May 2002 16:14:12 +0200
Size: 1410
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20020516/b7bc42d2/attachment.mht>

From oliphant.travis at ieee.org  Thu May 16 14:34:34 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 16 May 2002 12:34:34 -0600
Subject: [SciPy-dev] [Fwd: quadpack.error: Supplied function does not
	return a valid float.]
In-Reply-To: <3CE3C633.2783FF22@mecha.uni-stuttgart.de>
References: <3CE3C633.2783FF22@mecha.uni-stuttgart.de>
Message-ID: <1021574076.2548.11.camel@travis>

On Thu, 2002-05-16 at 08:46, Nils Wagner wrote:
> From: Nils Wagner <nwagner at mecha.uni-stuttgart.de>
> To: scipy-user at scipy.net <scipy-user at scipy.net>
> Subject: quadpack.error: Supplied function does not return a valid float.
> Date: 16 May 2002 16:14:12 +0200
> 
> Hi,
> 
> I have experienced a problem while using quad
> 
> Traceback (most recent call last):
>   File "quad.py", line 9, in ?
>     print m,n,sinint(m,n,1)
>   File "quad.py", line 6, in sinint
>     return quad(integrand,0.,pi,args=(m,n,x))
>   File
> "/usr/local/lib/python2.1/site-packages/scipy/integrate/quadpack.py",
> line 180, in quad
>     retval = _quad(func,a,b,args,full_output,epsabs,epsrel,limit,points)
>   File
> "/usr/local/lib/python2.1/site-packages/scipy/integrate/quadpack.py",
> line 244, in _quad
>     return
> _quadpack._qagse(func,a,b,args,full_output,epsabs,epsrel,limit)
> quadpack.error: Supplied function does not return a valid float.
> 
> from scipy import *
> from scipy.integrate import quad
> def integrand(t,m,n,x):
>    return sin(m*x*t)*sin(n*x*t)
> def sinint(m,n,x):
>    return quad(integrand,0.,pi,args=(m,n,x))
> for m in arange(0,9):
>    for n in arange(0,9):
>       print m,n,sinint(m,n,1)
> 
> Any idea ?
>

This is a strange  error.  I get it sporadically too.  I'll look into
it.

-Travis







From eric at enthought.com  Fri May 17 10:18:53 2002
From: eric at enthought.com (eric)
Date: Fri, 17 May 2002 10:18:53 -0400
Subject: [SciPy-dev] [ANN] Chaco: A 2D scientific graphics library
Message-ID: <03e501c1fdad$c668c8d0$6b01a8c0@ericlaptop>

I'm happy to announce that Enthought is developing a platform independent
plotting library for Python. The Chaco project, as it is named, is funded by
the Space Telescope Science Institute (STScI) and licensed under a BSD style
open source license. Chaco is designed for presentation quality scientific 2D
graphics on a variety of output devices. The initial targets are wxPython,
TkInter, Mac OS X, and PDF for hard copy output. It's design is extensible so
that other backends, such as OpenGL, can be added. Currently, the low-level API
for wxPython, Mac OS X, and PDF are operational.  The high level graphics
objects will be developed over the coming months.  Chaco is hosted at the SciPy
site. For more information visit:

        http://www.scipy.org/site_content/chaco

People are invited to comment on and contribute to the project.  Chaco's
discussion
list is:

    scipy-chaco at scipy.org

To subscribe, go to the mailing list's info page:

    http://scipy.net/mailman/listinfo/scipy-chaco

thanks,
eric jones

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057





From pearu at cens.ioc.ee  Sun May 19 05:06:04 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 19 May 2002 12:06:04 +0300 (EEST)
Subject: [SciPy-dev] CVS login problems
In-Reply-To: <1021739546.13534.4.camel@travis>
Message-ID: <Pine.LNX.4.21.0205191159440.2198-100000@cens.ioc.ee>

On 18 May 2002, Travis Oliphant wrote:

> I've noticed that my password seems not to work on the cvs server
> today.  It worked just a couple of days ago but now seems to not let me
> update the cvs tree.  Any idea what's wrong?

Same here. I cannot use the scipy cvs server nor login to scipy.org
anymore. Though I followed the instructions to change my password before
17th May..

Pearu



From adam at scipy.com  Sun May 19 19:13:08 2002
From: adam at scipy.com (Adam Barker)
Date: Sun, 19 May 2002 18:13:08 -0500
Subject: [SciPy-dev] Scipy.org login problems
Message-ID: <B90D9BB4.1DD%adam@scipy.com>

Hi all,

Apparently there was a bit of a bungle on my part last week with the account
expiration setup.  I inadvertently locked out everyone's account as of
Friday or Saturday.  Anyway, the problem should be fixed now, and everyone
should be able to log in.

If you have any trouble, let me know and I'll try to get it fixed as quickly
as possible.

Sorry for any inconvenience,

Adam



From dmorrill at enthought.com  Mon May 20 11:31:03 2002
From: dmorrill at enthought.com (David C. Morrill)
Date: Mon, 20 May 2002 10:31:03 -0500
Subject: [SciPy-dev] SciPy.org web site improvements
References: <B90D9BB4.1DD%adam@scipy.com>
Message-ID: <026401c20013$5ad803c0$6501a8c0@Dave>

Over the last few days, there have been a number of improvements made to the
http://www.scipy.org web site. Some of the changes worth mentioning are:

- We now have a nightly build/test/update process in place that builds and
tests over 30 different platform and subcomponent configurations for SciPy.
Right now we are testing on Linux (Red Hat 7.2), Windows 2000 (cygwin) and
Windows 2000 (mingw), with various versions of Python, Numeric and f2py. The
latest CVS version of SciPy is used for each test. Some of the test
configurations also include the latest CVS versions of Python, Numeric and
f2py.

The results of each build/test process are automatically uploaded to the
SciPy.org web site and are made visible through the new "Downloads"
(http://www.scipy.org/site_content/download_list) and "Build/Test
Scoreboard" (http://www.scipy.org/site_content/scoreboard) pages.

- The new "Downloads" page (link is at the top of the site menu on the left
side of the page) provides links to all the latest SciPy source and binary
tarballs that are built nightly for each platform.

- The new "Build/Test Scoreboard" page (link is in the site navigation menu
on the left of each page) shows the latest build/test results for each
configuration tested, including whether or not it "built" successfully, the
number of tests that failed or had errors, as well as a link to the detailed
log generated by the build/test process.

- There have also been a number of "cosmetic" changes made to the site,
including streamlining and reorganizing of the site menus, which hopefully
will make the site easier to navigate.

Dave Morrill
---
David Morrill <dmorrill at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057




From adam at enthought.com  Mon May 20 13:16:18 2002
From: adam at enthought.com (Adam Barker)
Date: Mon, 20 May 2002 11:16:18 -0600
Subject: [SciPy-dev] New CVS commit mailing list
Message-ID: <000d01c20022$11c7ccb0$7501a8c0@drklahn>

Hello all,

I'm pleased to announce that we now have a CVS commit log mailing list.
The new mailing list is called scipy-cvs, and is accessible at:

	http://www.scipy.net/mailman/listinfo/scipy-cvs

This list receives automatic updates on every commit to our repository.
Enjoy!

Let me know if you have any questions.

Thanks,

Adam



From prabhu at aero.iitm.ernet.in  Mon May 20 12:54:55 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Mon, 20 May 2002 22:24:55 +0530
Subject: [SciPy-dev] SciPy.org web site improvements
In-Reply-To: <026401c20013$5ad803c0$6501a8c0@Dave>
References: <B90D9BB4.1DD%adam@scipy.com>
	<026401c20013$5ad803c0$6501a8c0@Dave>
Message-ID: <15593.10847.396777.336031@monster.linux.in>

>>>>> "DCM" == David C Morrill <dmorrill at enthought.com> writes:

    DCM> Over the last few days, there have been a number of
    DCM> improvements made to the http://www.scipy.org web site. Some
    DCM> of the changes worth mentioning are:

I'm no web design Guru or anything but still I'd like to say you've
done a great job on the site.  I'm sure we users/developers will bug
you if there are things we'd like to see.  I believe that Fernando had
a useful suggestion about members being able to quickly/easily put up
pages on their sites that are related to scipy.  I cant remember what
exactly he said and couldnt dig up his email either.

Anyway for now things look great.  Thanks!

cheers,
prabhu


From pearu at cens.ioc.ee  Tue May 21 16:32:44 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 23:32:44 +0300 (EEST)
Subject: [SciPy-dev] New CVS commit mailing list
In-Reply-To: <000d01c20022$11c7ccb0$7501a8c0@drklahn>
Message-ID: <Pine.LNX.4.21.0205212328580.12941-100000@cens.ioc.ee>

On Mon, 20 May 2002, Adam Barker wrote:

> I'm pleased to announce that we now have a CVS commit log mailing list.
> The new mailing list is called scipy-cvs, and is accessible at:
> 
> 	http://www.scipy.net/mailman/listinfo/scipy-cvs
> 
> This list receives automatic updates on every commit to our repository.
> Enjoy!
> 
> Let me know if you have any questions.

Great!

Can you make default

  Reply-To: scipy-dev at scipy.net

for scipy-cvs mailing list messages?

Thanks,
	Pearu




From dmorrill at enthought.com  Wed May 22 12:33:50 2002
From: dmorrill at enthought.com (David C. Morrill)
Date: Wed, 22 May 2002 11:33:50 -0500
Subject: [SciPy-dev] FYI on meaning of 'Test Completed' on Download/Scoreboard pages of SciPy.org
Message-ID: <011201c201ae$747e0b70$6501a8c0@Dave>

Just a quick note on the meaning of 'Test Completed' in the 'Test Results'
column of the new Download and Scoreboard pages on the scipy.org web site.

'Test Completed' means that the test phase of the build process completed
successfully, but the build process was not able to locate the result
information (i.e. number of tests run, failures, errors) in the build log.
It currently locates the result information using a regular expression, so
unexpected changes in the message format may cause it to break (which is
what is happening now).

I'm looking into a fix for this (both short term and long term) right now.

In the meantime, you can still examine the build logs via the web pages to
see the actual test results.

So the bad news is that the 'Test Results' fields is currently partially
'broken'.

The good news is that what broke it appears to be a number of CVS check-ins
by Travis Oliphant that eliminated all of the test failures that were
occuring. So, all-in-all, a big net positive I think. Thanks Travis!.

Dave Morrill
---
David Morrill <dmorrill at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057



From eric at enthought.com  Wed May 22 11:46:45 2002
From: eric at enthought.com (eric)
Date: Wed, 22 May 2002 11:46:45 -0400
Subject: [SciPy-dev] CVS mailing list
Message-ID: <037d01c201a7$e0ad3890$6b01a8c0@ericlaptop>

By the way Pearu,

We've only had the CVS mailing list for a few days, and I already like it *very*
much.  Thanks for suggesting it.  And thanks, Adam, for setting it up.

eric

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057





From pearu at cens.ioc.ee  Wed May 22 17:18:15 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 23 May 2002 00:18:15 +0300 (EEST)
Subject: [SciPy-dev] FYI on meaning of 'Test Completed' on Download/Scoreboard
 pages of SciPy.org
In-Reply-To: <011201c201ae$747e0b70$6501a8c0@Dave>
Message-ID: <Pine.LNX.4.21.0205222341040.15667-100000@cens.ioc.ee>

Hi,

I like very much the new outlook and features of scipy.org pages. Thanks
to all who worked these things out!

Here is a small feature request to Scoreboard pages: 

Would it make sense to add also more detailed version information
(and configuration flags if applicable) about C/C++/Fortran
compilers used to run these builds and tests?
May be it would be possible to add this information into the header of
automatically generated logs? What do you think?

Notice that soon people start to use gcc-3.1 so that the compiler 
information becomes really relevant. For instance, weave has
problems with gcc-3.0.4 but not with gcc-2.95.4 (well, I get only one
seeminly random compilation failure with 2.95.4). I haven't tried
gcc-3.1, though.

Thanks,
	Pearu

PS: Also I would like to remind that CVS version calculation is not
working :-(
Please let me know if you don't care about this feature, then I'll
just stop bothering you about this.



From eric at enthought.com  Wed May 22 16:32:41 2002
From: eric at enthought.com (eric)
Date: Wed, 22 May 2002 16:32:41 -0400
Subject: [SciPy-dev] FYI on meaning of 'Test Completed' on Download/Scoreboard pages of SciPy.org
References: <Pine.LNX.4.21.0205222341040.15667-100000@cens.ioc.ee>
Message-ID: <049701c201cf$d21ae070$6b01a8c0@ericlaptop>

>
> I like very much the new outlook and features of scipy.org pages. Thanks
> to all who worked these things out!

Dave did a great job at this.

>
> Here is a small feature request to Scoreboard pages:
>
> Would it make sense to add also more detailed version information
> (and configuration flags if applicable) about C/C++/Fortran
> compilers used to run these builds and tests?
> May be it would be possible to add this information into the header of
> automatically generated logs? What do you think?

I think it is possible, but I have no idea how easy it would be to extract that
information.  If someone knows how to do it easily, send it our way, and we'll
add it to the script.

>
> Notice that soon people start to use gcc-3.1 so that the compiler
> information becomes really relevant. For instance, weave has
> problems with gcc-3.0.4 but not with gcc-2.95.4 (well, I get only one
> seeminly random compilation failure with 2.95.4). I haven't tried
> gcc-3.1, though.

Right.  Sometime I'd like to get gcc-3.0 setup on a machine where I can play
with it.  I doubt the weave errors on it are hard to fix.  I think it is mainly
a blitz issue.

>
> Thanks,
> Pearu
>
> PS: Also I would like to remind that CVS version calculation is not
> working :-(

This is an oversight on our part.  Either Adam or I will look into it again.  I
think you posted all the relevant information on setting it up in a previous
post, so we'll work from that.  If we have any troubles, we'll let you know.

eric

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




From cookedm at physics.mcmaster.ca  Thu May 23 18:57:28 2002
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Thu, 23 May 2002 18:57:28 -0400
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
Message-ID: <qnkvg9eiiav.fsf@arbutus.physics.mcmaster.ca>

Ok, I've taken another look at the system_info.py code. The attached
patch does the following:

- The wrong things were being set for static and shared libraries.
  Static libraries should be linked as 'extra_objects', and shared
  libraries using 'libraries' and 'library_dirs'.

- X11 is only linked statically if static_first=1 is set in the x11
  section of the site.cfg file (i.e., only when you explicitly ask for
  it, which you probably won't)

- The environment variables ATLAS and FFTW can now be set to a list of
  directories, if you don't want to use the site.cfg method.

- The doc strings for {Atlas,FFTW}NotFoundError now mention site.cfg
  as a method of setting paths

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm at mcmaster.ca
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: s.diff
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20020523/0c78042a/attachment.ksh>

From pearu at cens.ioc.ee  Fri May 24 18:02:14 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 25 May 2002 01:02:14 +0300 (EEST)
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <qnkvg9eiiav.fsf@arbutus.physics.mcmaster.ca>
Message-ID: <Pine.LNX.4.21.0205250026150.12590-100000@cens.ioc.ee>

On Thu, 23 May 2002, David M. Cooke wrote:

> Ok, I've taken another look at the system_info.py code. The attached
> patch does the following:

Thanks for the patch!

> - The wrong things were being set for static and shared libraries.
>   Static libraries should be linked as 'extra_objects', and shared
>   libraries using 'libraries' and 'library_dirs'.

Are you sure about this? What is your situation that static libraries
should not be in 'libraries'?

I found this

http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.html

very useful, e.g. see the last section. 

In fact, I am not sure anymore why we need to be specific about static
libraries. Also, we shouldn't use 'extra_objects' at all.

Pearu



From cookedm at physics.mcmaster.ca  Fri May 24 18:55:56 2002
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Fri, 24 May 2002 18:55:56 -0400
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <Pine.LNX.4.21.0205250026150.12590-100000@cens.ioc.ee> (Pearu
 Peterson's message of "Sat, 25 May 2002 01:02:14 +0300 (EEST)")
References: <Pine.LNX.4.21.0205250026150.12590-100000@cens.ioc.ee>
Message-ID: <qnk661d2m0z.fsf@arbutus.physics.mcmaster.ca>

At some point, Pearu Peterson <pearu at cens.ioc.ee> wrote:

> On Thu, 23 May 2002, David M. Cooke wrote:
>
>> Ok, I've taken another look at the system_info.py code. The attached
>> patch does the following:
>
> Thanks for the patch!
>
>> - The wrong things were being set for static and shared libraries.
>>   Static libraries should be linked as 'extra_objects', and shared
>>   libraries using 'libraries' and 'library_dirs'.
>
> Are you sure about this? What is your situation that static libraries
> should not be in 'libraries'?

This is what I get from system_info.py (before my patch) with
static_first = 1:

atlas_info:
  FOUND:
    include_dirs = ['/usr/local/include']
    library_dirs = ['/usr/lib/3dnow/atlas', '/usr/lib/3dnow']
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']

fftw_info:
  FOUND:
    include_dirs = ['/usr/include']
    define_macros = [('SCIPY_FFTW_H', 1)]
    library_dirs = ['/usr/lib']
    extra_objects = ['/usr/lib/libsfftw.so.2', '/usr/lib/libsrfftw.so.2', '/usr/lib/libsfftw_threads.so.2', '/usr/lib/libsrfftw_threads.so.2']
    libraries = ['fftw', 'rfftw', 'fftw_threads', 'rfftw_threads']

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

This is what I get with static_first = 0:

atlas_info:
  FOUND:
    include_dirs = ['/usr/local/include']
    extra_objects = ['/usr/lib/3dnow/atlas/liblapack.so', '/usr/lib/3dnow/libf77blas.so', '/usr/lib/3dnow/libcblas.so', '/usr/lib/3dnow/libatlas.so']

fftw_info:
  FOUND:
    include_dirs = ['/usr/include']
    extra_objects = ['/usr/lib/libfftw.so', '/usr/lib/librfftw.so', '/usr/lib/libfftw_threads.so', '/usr/lib/librfftw_threads.so', '/usr/lib/libsfftw.so.2', '/usr/lib/libsrfftw.so.2', '/usr/lib/libsfftw_threads.so.2', '/usr/lib/libsrfftw_threads.so.2']
    define_macros = [('SCIPY_FFTW_H', 1)]

x11_info:
  FOUND:
    include_dirs = ['/usr/X11R6/include']
    extra_objects = ['/usr/X11R6/lib/libX11.so']

Note that the static_first=1 (which should be 'static libraries are
preferred') would generate a link line like '-L/usr/lib/3dnow
-L/usr/lib/3dnow/atlas -llapack -lf77blas -lcblas -latlas'. However,
this will link in the *shared* versions of these libraries, as the
linker, if there are static and shared libraries available that
satisfy the link line, will preferentially select the shared library.

The static_first=0 situation will have a link line like
'/usr/lib/3dnow/atlas/liblapack.so /usr/lib/3dnow/libf77blas.so ...'
which (I just tried it out) works for linking in shared libraries, but
looks weird and isn't the way it's usually done.

Now, with my patch, static_first=1 will use for the link line
'/usr/lib/3dnow/atlas/liblapack.a /usr/lib/3dnow/libf77blas.a ...'
which links in static versions, and static_first=0 will use
'-L/usr/lib/3dnow/atlas -L/usr/lib/3dnow -llapack -lf77blas -lcblas
-latlas'
which will link in shared versions (or static versions, if the shared
versions don't exist).

> I found this
>
> http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.html
>
> very useful, e.g. see the last section. 
>
> In fact, I am not sure anymore why we need to be specific about static
> libraries. Also, we shouldn't use 'extra_objects' at all.

If you want to use a static library instead of a shared one (for speed
reasons, maybe), you will need to specify the filename of the static
library as an 'extra object file', so it will have to go in
'extra_objects'. Either that or specify an option to the linker to
prefer static to shared libraries.

Be as it may, I prefer to use shared libraries, as only one copy of
the library is in memory at one time, and my python modules don't
suddenly become 5 megs in size...

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm at mcmaster.ca


From pearu at cens.ioc.ee  Sat May 25 05:21:55 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 25 May 2002 12:21:55 +0300 (EEST)
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <qnk661d2m0z.fsf@arbutus.physics.mcmaster.ca>
Message-ID: <Pine.LNX.4.21.0205251132060.12590-100000@cens.ioc.ee>

David,

On Fri, 24 May 2002, David M. Cooke wrote:

<snip>

> Note that the static_first=1 (which should be 'static libraries are
> preferred') would generate a link line like '-L/usr/lib/3dnow
> -L/usr/lib/3dnow/atlas -llapack -lf77blas -lcblas -latlas'. However,
> this will link in the *shared* versions of these libraries, as the
> linker, if there are static and shared libraries available that
> satisfy the link line, will preferentially select the shared library.
> 
> The static_first=0 situation will have a link line like
> '/usr/lib/3dnow/atlas/liblapack.so /usr/lib/3dnow/libf77blas.so ...'
> which (I just tried it out) works for linking in shared libraries, but
> looks weird and isn't the way it's usually done.

I agree that static_first=1 did not work as expected but it worked as
designed (see below).

> Now, with my patch, static_first=1 will use for the link line
> '/usr/lib/3dnow/atlas/liblapack.a /usr/lib/3dnow/libf77blas.a ...'
> which links in static versions, and static_first=0 will use
> '-L/usr/lib/3dnow/atlas -L/usr/lib/3dnow -llapack -lf77blas -lcblas
> -latlas'
> which will link in shared versions (or static versions, if the shared
> versions don't exist).

Since I don't have shared versions of atlas libraries (in fact, ATLAS
provides no support for that and users are in their own in building shared
versions of atlas), I get with static_first=0 and your patch:

atlas_info:
  FOUND:
    extra_objects = ['/usr/local/lib/atlas/liblapack.a',
'/usr/local/lib/atlas/libf77blas.a', '/usr/local/lib/atlas/libcblas.a',
'/usr/local/lib/atlas/libatlas.a']
    include_dirs = ['/usr/include']

which is not desired either because blas and lapack extension modules will
be very large, they will contain symbols that they do not need. Even if
there are no .so libraries, the proper inclusion of .a libraries would be
to use '-llapack -lf77blas -lcblas  -latlas' so that only needed
symbols get into extension modules.

> If you want to use a static library instead of a shared one (for speed
> reasons, maybe), you will need to specify the filename of the static
> library as an 'extra object file', so it will have to go in
> 'extra_objects'. Either that or specify an option to the linker to
> prefer static to shared libraries.
> 
> Be as it may, I prefer to use shared libraries, as only one copy of
> the library is in memory at one time, and my python modules don't
> suddenly become 5 megs in size...

I agree with you completely.

Initially static_first hooks were meant to be used only to affect the
search path of libraries when static and shared libriaries are in
different directories. Obviously this is not always the case and then
the use of 'extra_objects' was introduced. IMO this was a mistake because
1) it is hackish and 2) it does not work neither with or without the
patch. Note also that one cannot use linker flags to force using static
libraries because python extension modules _must_ be shared.

My suggestion is to stop using 'extra_objects' in static_first hooks and
even if static_first=1 is specified, the shared libraries are preferred
(by the system, not by scipy_distutils [*]) in the case .so and .a files
are in the same directory. If people really want to force static
libraries, they can collect (the links of) static libraries into a
separate directory and add it to site.cfg. I don't think that scipy should
do that for users that do not like default behaviour of their system. What
do you think?

[*] Fighting with the default behaviours of systems that cannot be tested
directly is difficult. IMHO, by default scipy_distutils should use default
settings of the system and let the users fight with the system if they
insist, scipy_distutils can only provide some weapons (mainly site.cfg) to
ease their task.

Pearu



From pearu at cens.ioc.ee  Sun May 26 13:14:35 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 26 May 2002 20:14:35 +0300 (EEST)
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <qnkvg9eiiav.fsf@arbutus.physics.mcmaster.ca>
Message-ID: <Pine.LNX.4.21.0205261959250.8693-100000@cens.ioc.ee>

Hi,

Regarding this patch I have made the following changes.

On Thu, 23 May 2002, David M. Cooke wrote:

> Ok, I've taken another look at the system_info.py code. The attached
> patch does the following:
> 
> - The wrong things were being set for static and shared libraries.
>   Static libraries should be linked as 'extra_objects', and shared
>   libraries using 'libraries' and 'library_dirs'.

Dropped using 'extra_objects' as it was buggy from the start and unified
hooks for static (.a) and dynamic (.so) libriaries.

> - X11 is only linked statically if static_first=1 is set in the x11
>   section of the site.cfg file (i.e., only when you explicitly ask for
>   it, which you probably won't)

Renamed static_first to search_static_first and set its default value to
0. If someone really needs it, let me know. Otherwise search_static_first
hooks will be removed in future. I find it quite useless because systems
prefer shared libraries to static libraries (if they are in the same
directory) and Python extension modules are always shared libraries
anyway and I don't believe in speed improvement when linking against
static libraries in this situation.

> - The environment variables ATLAS and FFTW can now be set to a list of
>   directories, if you don't want to use the site.cfg method.

Applied. In addition, one can use also LAPACK and BLAS environment
variables.

> - The doc strings for {Atlas,FFTW}NotFoundError now mention site.cfg
>   as a method of setting paths

Applied. In addition, updated comments in sample_site.cfg.

I'll look forward to scoreboard to see if my changes broke something,
especially in win32 platform.

Pearu



From cookedm at physics.mcmaster.ca  Mon May 27 15:24:03 2002
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Mon, 27 May 2002 15:24:03 -0400
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <Pine.LNX.4.21.0205261959250.8693-100000@cens.ioc.ee> (Pearu
 Peterson's message of "Sun, 26 May 2002 20:14:35 +0300 (EEST)")
References: <Pine.LNX.4.21.0205261959250.8693-100000@cens.ioc.ee>
Message-ID: <qnk1ybx2y3w.fsf@arbutus.physics.mcmaster.ca>

At some point, Pearu Peterson <pearu at cens.ioc.ee> wrote:

> Hi,
>
> Regarding this patch I have made the following changes.
>
[...]
> Dropped using 'extra_objects' as it was buggy from the start and unified
> hooks for static (.a) and dynamic (.so) libriaries.
[...]
> Renamed static_first to search_static_first and set its default value to
> 0. If someone really needs it, let me know. Otherwise search_static_first
> hooks will be removed in future. I find it quite useless because systems
> prefer shared libraries to static libraries (if they are in the same
> directory) and Python extension modules are always shared libraries
> anyway and I don't believe in speed improvement when linking against
> static libraries in this situation.

Ok, I looked over your changes and they look ok. But I have one
quibble: the use of shortest_path(). If there are two copies of a
library 'libx.so' in different directories, say /usr/local/lib and
/opt/lib, and the search paths have been specified so that
/usr/local/lib comes before /opt/lib (as it does in default_lib_dirs),
then shortest_path() will select '/opt/lib/libx.so' instead of the
preferred '/usr/local/lib/libx.so'. But here's a replacement that
should choose the right one, preferring '/usr/local/lib/libx.so' over
'/opt/lib/libx.so' and '/usr/local/lib/libx.so.6'

def shortest_path(pths):
    if not pths:
        return None
    dir = os.path.dirname(pths[0])
    pths = [(len(p), p) for p in pths if os.path.dirname(p) == dir]
    return min(pths)[1]

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm at physics.mcmaster.ca


From pearu at cens.ioc.ee  Mon May 27 15:42:34 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 27 May 2002 22:42:34 +0300 (EEST)
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <qnk1ybx2y3w.fsf@arbutus.physics.mcmaster.ca>
Message-ID: <Pine.LNX.4.21.0205272231370.17569-100000@cens.ioc.ee>

On Mon, 27 May 2002, David M. Cooke wrote:

> At some point, Pearu Peterson <pearu at cens.ioc.ee> wrote:
> 
> > Hi,
> >
> > Regarding this patch I have made the following changes.
> >
> [...]
> > Dropped using 'extra_objects' as it was buggy from the start and unified
> > hooks for static (.a) and dynamic (.so) libriaries.
> [...]
> > Renamed static_first to search_static_first and set its default value to
> > 0. If someone really needs it, let me know. Otherwise search_static_first
> > hooks will be removed in future. I find it quite useless because systems
> > prefer shared libraries to static libraries (if they are in the same
> > directory) and Python extension modules are always shared libraries
> > anyway and I don't believe in speed improvement when linking against
> > static libraries in this situation.
> 
> Ok, I looked over your changes and they look ok. But I have one
> quibble: the use of shortest_path(). If there are two copies of a
> library 'libx.so' in different directories, say /usr/local/lib and
> /opt/lib,

Note that this situation is not possible because lib_dir in self._lib_list
is always a string containing the name of a directory. So, shortest_path
is used to return actually the shortest basename as the directory is
always the same. To avoid breaking these conditions in future, I have
added
  assert type(lib_dir) is type('')
to self._lib_list method. Is that ok now?

Pearu



From cookedm at physics.mcmaster.ca  Mon May 27 15:52:24 2002
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Mon, 27 May 2002 15:52:24 -0400
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <Pine.LNX.4.21.0205272231370.17569-100000@cens.ioc.ee> (Pearu
 Peterson's message of "Mon, 27 May 2002 22:42:34 +0300 (EEST)")
References: <Pine.LNX.4.21.0205272231370.17569-100000@cens.ioc.ee>
Message-ID: <qnkr8jx1i87.fsf@arbutus.physics.mcmaster.ca>

At some point, Pearu Peterson <pearu at cens.ioc.ee> wrote:

> On Mon, 27 May 2002, David M. Cooke wrote:
>
>> At some point, Pearu Peterson <pearu at cens.ioc.ee> wrote:
>> 
>> > Hi,
>> >
>> > Regarding this patch I have made the following changes.
>> >
>> [...]
>> > Dropped using 'extra_objects' as it was buggy from the start and unified
>> > hooks for static (.a) and dynamic (.so) libriaries.
>> [...]
>> > Renamed static_first to search_static_first and set its default value to
>> > 0. If someone really needs it, let me know. Otherwise search_static_first
>> > hooks will be removed in future. I find it quite useless because systems
>> > prefer shared libraries to static libraries (if they are in the same
>> > directory) and Python extension modules are always shared libraries
>> > anyway and I don't believe in speed improvement when linking against
>> > static libraries in this situation.
>> 
>> Ok, I looked over your changes and they look ok. But I have one
>> quibble: the use of shortest_path(). If there are two copies of a
>> library 'libx.so' in different directories, say /usr/local/lib and
>> /opt/lib,
>
> Note that this situation is not possible because lib_dir in self._lib_list
> is always a string containing the name of a directory. So, shortest_path
> is used to return actually the shortest basename as the directory is
> always the same. To avoid breaking these conditions in future, I have
> added
>   assert type(lib_dir) is type('')
> to self._lib_list method. Is that ok now?

All right. It's just that it's somewhat deceptive to call
shortest_path(), which (as written) doesn't take into account the
preferred ordering. I suppose now I worried more about the look of the
code :-)

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm at physics.mcmaster.ca


From pearu at cens.ioc.ee  Mon May 27 15:56:57 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 27 May 2002 22:56:57 +0300 (EEST)
Subject: [SciPy-dev] PATCH: scipy_distutils/system_info.py
In-Reply-To: <Pine.LNX.4.21.0205272231370.17569-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.21.0205272247140.17569-100000@cens.ioc.ee>


On Mon, 27 May 2002, Pearu Peterson wrote:

> Note that this situation is not possible because lib_dir in self._lib_list
> is always a string containing the name of a directory. So, shortest_path
> is used to return actually the shortest basename as the directory is
> always the same. To avoid breaking these conditions in future, I have
> added
>   assert type(lib_dir) is type('')
> to self._lib_list method. Is that ok now?

hmm, now I look that there is no need for shortest_path as  
e.g. p==[libx.so.6, libx.so] never occurs. Earlier it was possible because

  exts = ['.a',so_ext+'*']

equivalent was used. But now, detecting e.g. libx.so.6 is senseless as
linking -lx looks always for libx.so. Earlier it made sense only because
libx.so.6 was used in extra_objects list.

So, I am considering not using the shortest_path at all and the code will
hopefully look good for you :-)

Pearu




From hoel at germanlloyd.org  Tue May 28 11:05:18 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 28 May 2002 17:05:18 +0200
Subject: [SciPy-dev] patch to build_flib to support digital fortran compiler
Message-ID: <sen0ukgvo1.fsf@pc970145.GermanLloyd.de>

I have added a class "digital_fortran_compiler" to build_flib.py which
adds support for the Digital Fortran Comiler under WinNT to the
scipy_distutils.
Please find the class attached (no diffs because or the recent changes
to build_flib.py did not allow a good diff).



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_fortran_compiler.cls
Type: application/octet-stream
Size: 2930 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20020528/9cd99929/attachment.obj>
-------------- next part --------------

This works at least for me if digital_fortran_compiler is added to the
list of compiler list.

Greetings

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg

From pearu at cens.ioc.ee  Tue May 28 18:52:23 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 29 May 2002 01:52:23 +0300 (EEST)
Subject: [SciPy-dev] patch to build_flib to support digital fortran
 compiler
In-Reply-To: <sen0ukgvo1.fsf@pc970145.GermanLloyd.de>
Message-ID: <Pine.LNX.4.21.0205290139400.21085-100000@cens.ioc.ee>

Hi Berthold,

On 28 May 2002, [iso-8859-15] Berthold H?llmann wrote:

> I have added a class "digital_fortran_compiler" to build_flib.py which
> adds support for the Digital Fortran Comiler under WinNT to the
> scipy_distutils.
> Please find the class attached (no diffs because or the recent changes
> to build_flib.py did not allow a good diff).

Thanks for the patch!

I have applied your patch to scipy_distutils but made some
re-factoring modifications to reduce the code size. In addition, I used

  DF

as a compiler name instead of f90. This I learned from

  http://www.compaq.com/fortran/docs/vf-html/vf_frame.htm

Is it OK?

Thanks,
	Pearu



From hoel at germanlloyd.org  Wed May 29 04:19:05 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 29 May 2002 10:19:05 +0200
Subject: [SciPy-dev] Re: patch to build_flib to support digital fortran compiler
In-Reply-To: <Pine.LNX.4.21.0205290139400.21085-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205290139400.21085-100000@cens.ioc.ee>
Message-ID: <se8z635pty.fsf@pc970145.GermanLloyd.de>

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

> Hi Berthold,
> 
> On 28 May 2002, [iso-8859-15] Berthold H?llmann wrote:
> 
> > I have added a class "digital_fortran_compiler" to build_flib.py
which
> > adds support for the Digital Fortran Comiler under WinNT to the
> > scipy_distutils.
> > Please find the class attached (no diffs because or the recent
changes
> > to build_flib.py did not allow a good diff).
> 
> Thanks for the patch!
> 
> I have applied your patch to scipy_distutils but made some
> re-factoring modifications to reduce the code size. In addition, I
used
> 
>   DF
> 
> as a compiler name instead of f90. This I learned from
> 
>   http://www.compaq.com/fortran/docs/vf-html/vf_frame.htm
> 
> Is it OK?
> 

Hi Pearu,

I just downloaded SciPy-0.2.0_alpha_101.3442.win32-py2.2.exe with date
tag for today. I was able to compile my project, so it seems, it is OK
for me.

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 


From pearu at cens.ioc.ee  Wed May 29 11:41:10 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 29 May 2002 18:41:10 +0300 (EEST)
Subject: [SciPy-dev] blas/lapack interfaces
In-Reply-To: <077401c206c1$a1fdba10$d2566a42@ericlaptop>
Message-ID: <Pine.LNX.4.21.0205291731000.6624-100000@cens.ioc.ee>

On Tue, 28 May 2002, eric wrote:

> > Pearu wrote:

> > I agree. Having the C interfaces around is useful only if there is a
> > memory issue.
> 
> Lets keep them.  Your packaging in linalg makes the fail over to
> flapack completely transparent, so the only cost is maintaining the
> code.  That may not be a small cost though -- these wrappers
> definitions are pretty dang complex now.  I saw that you split the
> Fortran and C wrappers files at some point.  I had really wanted to
> avoid this to help with maintainability but assume it was done to
> handle the callstatement() stuff.  I do wish they were still unified.
> Do you think it might be possible to introduce a <c_section> and
> <f_section> tag to our interface_gen generic scripts to include
> specific sections in the generated interface files depending on the
> target language?

I did that split in order to avoid complexity when it was not really clear
how these signatures will look like (in this process new features to f2py 
were added). However, the signatures to Fortran and C routines were
created in parallel to ensure the compability. Also, you'll see that
signatures to the same Fortran or C routine are in some cases quite
different (because C and Fortran routines require a bit different
strategies for wrapping and managing memory of temporaries, also
BLAS?LAPACK interfaces of the same routine but for complex or real
input data may differ etc.) but their apparence in Python is
(almost) identical (some wrappers to C routines have extra optional
arguments to handle data ordering issues with additional flexibility).

But now, when the most important BLAS/LAPACK routines are exposed and we
have basic unittests (and need more), I agree, that the next step would be
to merge the signatures of Fortran and C routines to ease the
maintainability. And yes, introducing <c|f_section> tags are possible when
doing that.

In addition, I would like to suggest splitting the current generic
signature files into smaller files, each containing signatures to one
particular routine. Having different routine signatures in separate files
(collected in some subdirectory of scipy/linalg), IMHO, they will be 
easier to maintain and discuss compared to its current form where the
generic files, containing a large number of different signatures, are
quite longish and difficult to handle.

And we need to document the blas and lapack functions. I hope we can do
that while reviewing-testing-freezing the signatures.

Pearu



From Chuck.Harris at sdl.usu.edu  Wed May 29 16:58:07 2002
From: Chuck.Harris at sdl.usu.edu (Chuck Harris)
Date: Wed, 29 May 2002 14:58:07 -0600
Subject: [SciPy-dev] RE:[PATCH] zeros.c
Message-ID: <A55D0D8A70975D4FBE9441512E9CF8BC7A3A88@cobra.usurf.usu.edu>

This patch does the following:

1) If the passed function raises an exception, that is the exception reported.
2) If the passed function does not return a valid value, the report is made clearer.
3) Small formatting cleanup
4) Documentation strings are added for the module functions.
5) A reference counting bug is fixed

The reference counting bug is easy to trigger by passing the extra argument. Say

def f(x): return x - .5

foo = 'fubar'
for i in range(1000) : bisect(f,0,1,args=foo)

at some point foo will be garbage collected and disappears. I must admit that
I haven't tried precisely this example and no longer have the original installed
to check, but it should work. Oddly enough, Idle also seems to suffer from a 
reference counting bug, so using sys.getrefcount may return unexpected results.

The reason this bug shows up is that PyTuple_GetItem borrows a reference and
PyTuple_SET_ITEM steals it, so when the tuple is destroyed the reference count
of the item is decremented instead of being left in its original state.

The lines all seem to end in ^M, as reported by emacs. It is not visible here,
but there may be some sort of line end problem. I got the source from CVS using 
http to download the files. Is this as it should be?

Chuck
==================PATCH==================
--- zeros-old.c	Wed May 29 13:40:50 2002
+++ zeros.c	Wed May 29 11:39:09 2002
@@ -40,11 +40,18 @@
     args = myparams->args;
     f = myparams->function;
     PyTuple_SetItem(args,0,Py_BuildValue("d",x));
-    val = PyFloat_AsDouble(retval=PyObject_CallObject(f,args));
-    Py_XDECREF(retval);
+    retval = PyObject_CallObject(f,args); 
+    if (PyErr_Occurred()) {
+        Py_XDECREF(retval);
+        longjmp(myparams->env, 1);
+    }
+    val = PyFloat_AsDouble(retval);
     if (PyErr_Occurred()) {
+        PyErr_SetString(PyExc_RuntimeError,"Could not convert function value to double");
+        Py_XDECREF(retval);
         longjmp(myparams->env, 1);
     }
+    Py_XDECREF(retval);
     return val;    
 }
 
@@ -62,11 +69,10 @@
     PyObject *f,*xargs,*item,*fargs=NULL;
 
     
-    if (!PyArg_ParseTuple(args,"OdddiOi|i",&f,&a,&b,&xtol,&iter,&xargs,&fulloutput,&disp)) 
-        {
-            PyErr_SetString(PyExc_RuntimeError,"Unable to parse arguments");
-            return NULL;
-        }
+    if (!PyArg_ParseTuple(args,"OdddiOi|i",&f,&a,&b,&xtol,&iter,&xargs,&fulloutput,&disp)) {
+        PyErr_SetString(PyExc_RuntimeError,"Unable to parse arguments");
+        return NULL;
+    }
     if (xtol < 0) {
         PyErr_SetString(PyExc_ValueError,"xtol must be >= 0");
         return NULL;
@@ -87,6 +93,7 @@
     for (i = 0; i < len; i++) {
         item = PyTuple_GetItem(xargs, i);
         if (item == NULL) { Py_DECREF(fargs); return NULL;}
+	Py_INCREF(item);
         PyTuple_SET_ITEM(fargs,i+1,item);
     }
 
@@ -154,10 +161,10 @@
 
 static PyMethodDef 
 Zerosmethods[] = {
-	{"_bisect", _bisect, METH_VARARGS, "a"},
-	{"_ridder", _ridder, METH_VARARGS, "a"},
-	{"_brenth", _brenth, METH_VARARGS, "a"},
-	{"_brentq", _brentq, METH_VARARGS, "a"},
+	{"_bisect", _bisect, METH_VARARGS, "bisect(f,a,b)"},
+	{"_ridder", _ridder, METH_VARARGS, "ridder(f,a,b)"},
+	{"_brenth", _brenth, METH_VARARGS, "brenth(f,a,b)"},
+	{"_brentq", _brentq, METH_VARARGS, "brentq(f,a,b)"},
 	{NULL, NULL}
 };
 


From jsw at cdc.noaa.gov  Thu May 30 08:35:41 2002
From: jsw at cdc.noaa.gov (Jeff Whitaker)
Date: Thu, 30 May 2002 06:35:41 -0600 (MDT)
Subject: [SciPy-dev] cvs change broke macos x compatibility
Message-ID: <Pine.OSX.4.44.0205300616450.708-100000@localhost.cdc.noaa.gov>

Yesterday's cvs snapshot won't compile on OS X.  The error is:

ar -curs build/temp.darwin-5.4-PowerMacintosh-2.2/libcalc_lwork.a
build/temp.darwin-5.4-PowerMacintosh-2.2/calc_lwork.o
ar: illegal option -- s

It worked a week ago - someone must have just added the "s" option to ar.
This is not supported on OS X.


-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : jsw at cdc.noaa.gov
325 Broadway                Web    : www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124





From pearu at cens.ioc.ee  Thu May 30 08:52:21 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 30 May 2002 15:52:21 +0300 (EEST)
Subject: [SciPy-dev] cvs change broke macos x compatibility
In-Reply-To: <Pine.OSX.4.44.0205300616450.708-100000@localhost.cdc.noaa.gov>
Message-ID: <Pine.LNX.4.21.0205301550390.7416-100000@cens.ioc.ee>

On Thu, 30 May 2002, Jeff Whitaker wrote:

> Yesterday's cvs snapshot won't compile on OS X.  The error is:
> 
> ar -curs build/temp.darwin-5.4-PowerMacintosh-2.2/libcalc_lwork.a
> build/temp.darwin-5.4-PowerMacintosh-2.2/calc_lwork.o
> ar: illegal option -- s
> 
> It worked a week ago - someone must have just added the "s" option to ar.
> This is not supported on OS X.

That was me. Sorry about that. It is fixed in CVS now.

Pearu



From jsw at cdc.noaa.gov  Fri May 31 08:49:31 2002
From: jsw at cdc.noaa.gov (Jeff Whitaker)
Date: Fri, 31 May 2002 06:49:31 -0600 (MDT)
Subject: [SciPy-dev] cvs change broke macos x compatibility
Message-ID: <Pine.OSX.4.44.0205310619191.838-100000@localhost.cdc.noaa.gov>

> That was me. Sorry about that. It is fixed in CVS now.

Pearu:  Thanks!  Seems to be working now.  Here are my test results on OS
X:

>>> scipy.test_all()

...

Ran 586 tests in 534.560s

FAILED (errors=1)
>>>

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : jsw at cdc.noaa.gov
325 Broadway                Web    : www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124