Mailman 3 August 2001 - SciPy-Dev

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

Dec. 23, 2001

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

6 14

AIX isinf, isfinite, etc.
by eric jones Aug. 21, 2001

Aug. 21, 2001

The good news: Almost all of scipy now compiles on AIX 4.x (at least on the SP3) using cc_r and g77. The lone non-ported piece is the vq stuff in cluster. It needs a C++ compiler, and I haven't figured out how to force distutils to use gcc instead of cc_r (or use cc_r for C files and gcc for C++) files. It was good to try this because cc_r found a few portability issues in the C code. (cc_r is the thread-safe standard C compiler on AIX). The bad news: Many of the isinf, isnan, isfinite tests fail on this platform. We new this was gonna be a headache, and it is. No time to explore fixing this now, but will look into the issues as soon as possible. eric

1 0

Re: Splines module
by Tim Lahey Aug. 3, 2001

Aug. 3, 2001

> > Date: Thu, 2 Aug 2001 15:55:24 -0600 (MDT) > From: Travis Oliphant <oliphant(a)ee.byu.edu> > To: <scipy-dev(a)scipy.org> > Subject: [SciPy-dev] Spline module > > > I'm not necessarily opposed to a separate splines module. But, splines do > get used in a number of different ways --- and the algorithms used in each > domain do tend to differ. > > Perhaps your spline code would be better in a finite-element package, > rather than a spline module. > > Love to have more help with scipy... > > I don't mind f77 code (but then again I haven't dealt with the Windows > headaches as much as eric :-) ). > > -Travis Well, I base my code on some general B-spline code (written in F77) from the SLATEC library in Netlib. I only use less than a half dozen functions from the library, but it does include: BINT4 - interpolates with splines of order 4 BINTK - interpolates with splines of order k BSQAD - integrates the B-representation on subintervals PPQAD - integrates the PP-representation BFQAD - integrates the product of a function F and any spline derivative in the B-representation PFQAD - integrates the product of a function F and any spline derivative in the PP-representation BVALU - evaluates the B-representation or a derivative PPVAL - evaluates the PP-representation or a derivative INTRV - gets the largest index of the knot to the left of x BSPPP - converts from B- to PP-representation BSPVD - computes nonzero basis functions and derivatives at x BSPDR - sets up difference array for BSPEV BSPEV - evaluates the B-representation and derivatives BSPVN - called by BSPEV, BSPVD, BSPPP and BINTK for function and derivative evaluations where PP-representation is piecewise polynomial representation, and B-representation is B-spline representation. These are the basic functions the spline toolbox are based off of. From BSPVD one can get the tensor product B-spline form, which is what I do. There are some other routines in Carl de Boor, A Practical Guide to Splines, Applied Mathematics Series 27, Springer-Verlag, New York, 1978. for solving ODEs through co-location. The way I see things is that we can create a base spline module that includes the above functions (save BINT4 and BINTK) and have separate modules for: interpolation, solving ODEs through co-location, and my FEM code (possibly). Thoughts ? Cheers, Tim.

1 0

Spline module
by Travis Oliphant Aug. 2, 2001

Aug. 2, 2001

> > Getting the new version of SciPy from CVS I was happy to see the > inclusion > of splines support. However, it is split between interpolate and > signal. I > personally would prefer a separate splines module. Some of us use splines > for neither of the above. I've been using B-splines as a basis for a > finite > element method. The SLATEC library on Netlib has an set of excellent > spline codes based upon de Boor's code. The only problem is that it > doesn't > support 2-D. I'm not necessarily opposed to a separate splines module. But, splines do get used in a number of different ways --- and the algorithms used in each domain do tend to differ. Perhaps your spline code would be better in a finite-element package, rather than a spline module. > > I've written a set of F90 wrappers around the code to support some stuff > in 2-D and provide a more object-oriented api, but I don't need > interpolation > so, I've been ignoring that part. I've been planning a port to Python > and I'd > be happy to help in the development of the splines part of scipy. > > Thoughts? Love to have more help with scipy... > I just noticed this addition too. Travis Oliphant is the man to talk to > about this. I doubt he > has thought to hard about its location in scipy and will be open to > suggestion. Also, > the SLATEC slant sounds promising. Can you work on it as a side project and > we > can integrate it into SciPy later. Right now we need to work the existing > kinks out > of the code and get a binary release out the door. (It should been out last > week) > > One thing though -- no F90 code. Sorry, but its harder to wrap in Python > and there aren't > any OS compilers around that handle it yet (give th gnu folks another few > years though...) > F77 code is acceptable, but we smile bigger when handed C/C++ and Python. > Then again, Travis O. might not smile at all if its C++... > I don't mind f77 code (but then again I haven't dealt with the Windows headaches as much as eric :-) ). -Travis

2 1

Fw: [SciPy-dev] Splines in SciPy
by eric jones Aug. 2, 2001

Aug. 2, 2001

Hey Tim, I just noticed this addition too. Travis Oliphant is the man to talk to about this. I doubt he has thought to hard about its location in scipy and will be open to suggestion. Also, the SLATEC slant sounds promising. Can you work on it as a side project and we can integrate it into SciPy later. Right now we need to work the existing kinks out of the code and get a binary release out the door. (It should been out last week) One thing though -- no F90 code. Sorry, but its harder to wrap in Python and there aren't any OS compilers around that handle it yet (give th gnu folks another few years though...) F77 code is acceptable, but we smile bigger when handed C/C++ and Python. Then again, Travis O. might not smile at all if its C++... see ya, eric > > ----- Original Message ----- > From: "Tim Lahey" <tjlahey(a)mud.cgl.uwaterloo.ca> > To: <scipy-dev(a)scipy.net> > Sent: Wednesday, August 01, 2001 7:09 PM > Subject: [SciPy-dev] Splines in SciPy > > > > All, > > > > Getting the new version of SciPy from CVS I was happy to see the > > inclusion > > of splines support. However, it is split between interpolate and > > signal. I > > personally would prefer a separate splines module. Some of us use splines > > for neither of the above. I've been using B-splines as a basis for a > > finite > > element method. The SLATEC library on Netlib has an set of excellent > > spline codes based upon de Boor's code. The only problem is that it > > doesn't > > support 2-D. > > > > I've written a set of F90 wrappers around the code to support some stuff > > in 2-D and provide a more object-oriented api, but I don't need > > interpolation > > so, I've been ignoring that part. I've been planning a port to Python > > and I'd > > be happy to help in the development of the splines part of scipy. > > > > Thoughts? > > > > Cheers, > > > > Tim Lahey > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev(a)scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-dev >

1 0

Splines in SciPy
by Tim Lahey Aug. 1, 2001

Aug. 1, 2001

All, Getting the new version of SciPy from CVS I was happy to see the inclusion of splines support. However, it is split between interpolate and signal. I personally would prefer a separate splines module. Some of us use splines for neither of the above. I've been using B-splines as a basis for a finite element method. The SLATEC library on Netlib has an set of excellent spline codes based upon de Boor's code. The only problem is that it doesn't support 2-D. I've written a set of F90 wrappers around the code to support some stuff in 2-D and provide a more object-oriented api, but I don't need interpolation so, I've been ignoring that part. I've been planning a port to Python and I'd be happy to help in the development of the splines part of scipy. Thoughts? Cheers, Tim Lahey

1 0