From faltet at carabos.com Sat Dec 4 06:07:04 2004 From: faltet at carabos.com (Francesc Altet) Date: Sat, 4 Dec 2004 12:07:04 +0100 Subject: [SciPy-user] ANN: PyTables 0.9.1 released Message-ID: <200412041207.04631.faltet@carabos.com> Announcing PyTables 0.9.1 ------------------------- This release is mainly a maintenance version. In it, some bugs has been fixed and a few improvements has been made. One important thing is that chunk sizes in EArrays has been re-tuned to get much better performance and compression rations. Besides, it has been tested against the latest Python 2.4 and all test units seems to pass fine. What it is ---------- PyTables is a solid hierarchical database package designed to efficiently manage extremely large amounts of data (with support for full 64-bit file addressing). It features an object-oriented interface that, combined with C extensions for the performance-critical parts of the code, makes it a very easy-to-use tool for high performance data storage and retrieval. It is built on top of the HDF5 library and the numarray package, and provides containers for both heterogeneous data (Tables) and homogeneous data (Array, EArray) as well as containers for keeping lists of objects of variable length (like Unicode strings or general Python objects) in a very efficient way (VLArray). It also sports a series of filters allowing you to compress your data on-the-fly by using different compressors and compression enablers. But perhaps the more interesting features are its powerful browsing and searching capabilities that allow you to perform data selections over heterogeneous datasets exceeding gigabytes of data in just tenths of second. Besides, all the PyTables I/O is buffered, implemented in C and carefully tuned so that you can reach much better performance with PyTables than with your own home-grown wrappings to the HDF5 library. Changes more in depth --------------------- Improvements: - The chunksize computation for EArrays has been re-tuned to allow better performance and *much* better compression rations. - New --unpackshort and --quantize flags has been added to nctoh5 script. --unpackshort unpack short integer variables to float variables using scale_factor and add_offset netCDF variable attributes. --quantize quantize data to improve compression using least_significant_digit netCDF variable attribute (not active by default). See http://www.cdc.noaa.gov/cdc/conventions/cdc_netcdf_standard.shtml for further explanation of what this attribute means. Thanks to Jeff Whitaker for providing this. - Table.itersequence has received a new parameter called "sort". This allows to disable the sorting of the sequence in case the user wants so. Backward-incompatible changes: - Now, the AttributeSet class throw an AttributeError on __getattr__ for nonexistent attributes in it. Formerly, the routine returned None, which is pretty much against convention in Python and breaks the built-in hasattr() function. Thanks to Norbert Nemec for noting this and offering a patch. - VLArray.read() has changed its behaviour. Now, it always returns a list, as stated in documentation, even when the number of elements to return is 0 or 1. This is much more consistent when representing the actual number of elements on a certain VLArray row. API additions: - A Row.getTable() has been added. It is an accessor for the associated Table object. - A File.copyAttrs() has been added. It allows copying attributes from one leaf to other. Properly speaking, this was already there, but not documented :-/ Bug fixes: - Now, the copy of hierarchies works even when there are scalar Arrays (i.e. Arrays which shape is ()) on it. Thanks to Norbert Nemec for providing a patch. - Solved a memory leak regarding the Filters instance associated with the File object, that was not released after closing the file. Now, there are no known leaks on PyTables itself. - Fixed a bug in Table.append() when the table was indexed. The problem was that if table was in auto-indexing mode, some rows were lost in the indexation process and hence, not indexed correctly. - Improved security of nodes name checking. Closes #1074335 Important note for Python 2.4 and Windows users ----------------------------------------------- If you are willing to use PyTables with Python 2.4 in Windows platforms, you will need to get the HDF5 library compiled for MSVC 7.1, aka .NET (and possible LZO and UCL as well, if you want support for LZO and UCL at all). It can be found at: ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/bin/windows/5-163-winxp-net2003.zip Where can PyTables be applied? ------------------------------ PyTables is not designed to work as a relational database competitor, but rather as a teammate. If you want to work with large datasets of multidimensional data (for example, for multidimensional analysis), or just provide a categorized structure for some portions of your cluttered RDBS, then give PyTables a try. It works well for storing data from data acquisition systems (DAS), simulation software, network data monitoring systems (for example, traffic measurements of IP packets on routers), very large XML files, or for creating a centralized repository for system logs, to name only a few possible uses. What is a table? ---------------- A table is defined as a collection of records whose values are stored in fixed-length fields. All records have the same structure and all values in each field have the same data type. The terms "fixed-length" and "strict data types" seem to be quite a strange requirement for a language like Python that supports dynamic data types, but they serve a useful function if the goal is to save very large quantities of data (such as is generated by many scientific applications, for example) in an efficient manner that reduces demand on CPU time and I/O resources. What is HDF5? ------------- For those people who know nothing about HDF5, it is a general purpose library and file format for storing scientific data made at NCSA. HDF5 can store two primary objects: datasets and groups. A dataset is essentially a multidimensional array of data elements, and a group is a structure for organizing objects in an HDF5 file. Using these two basic constructs, one can create and store almost any kind of scientific data structure, such as images, arrays of vectors, and structured and unstructured grids. You can also mix and match them in HDF5 files according to your needs. Platforms --------- I'm using Linux (Intel 32-bit) as the main development platform, but PyTables should be easy to compile/install on many other UNIX machines. This package has also passed all the tests on a UltraSparc platform with Solaris 7 and Solaris 8. It also compiles and passes all the tests on a SGI Origin2000 with MIPS R12000 processors, with the MIPSPro compiler and running IRIX 6.5. It also runs fine on Linux 64-bit platforms, like AMD Opteron running GNU/Linux 2.4.21 Server, Intel Itanium (IA64) running GNU/Linux 2.4.21 or PowerPC G5 with Linux 2.6.x in 64bit mode. It has also been tested in MacOSX platforms (10.2 but should also work on newer versions). Regarding Windows platforms, PyTables has been tested with Windows 2000 and Windows XP (using the Microsoft Visual C compiler), but it should also work with other flavors as well. Web site -------- Go to the PyTables web site for more details: http://pytables.sourceforge.net/ To know more about the company behind the PyTables development, see: http://www.carabos.com/ Share your experience --------------------- Let me know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy data! -- Francesc Altet Who's your data daddy? ?PyTables From reikhboerger at gmx.de Sun Dec 5 12:28:43 2004 From: reikhboerger at gmx.de (=?ISO-8859-1?Q?Reik_H._B=F6rger?=) Date: Sun, 5 Dec 2004 18:28:43 +0100 Subject: [SciPy-user] linalg.eigenvalues In-Reply-To: <20041204110806.BF9963EB6E@www.scipy.com> References: <20041204110806.BF9963EB6E@www.scipy.com> Message-ID: <1C5A3678-46E3-11D9-9D0E-000A959A0E34@gmx.de> Hi, Tiziano, thanks for the link, I will check it soon. Robert, thanks for the link about floating-point arithmetics. What you say about 1e-15 being zero for practical purposes, I am aware of that. My problem is, that other routines in python rely on linalg.eig or similar procedures, for example in generating mutlivariate normal random variates. When I give my covariance matrix to the routine and it comes back to me, saying that my matrix is not positive definite, though I can prove it, then it is a problem. There are some easy ways to check, if a matrix is positive without using a eigenvalue decomposition. I think, this should be included in either the linalg.eig-routine or the stats.rv.multinormal-routine. You say, that Maple is basically rounding the imaginary part. Are you sure or do you guess? How does Maple know, that this matrix has no complex eigenvalues? Does it perform the checks mentioned above? Thanks, Reik > You may want to have a look at: > http://mdp-toolkit.sourceforge.net/symeig.html > > The symeig module contains a Python wrapper for the LAPACK functions > to solve the standard and generalized eigenvalue problems for > symmetric (hermitian) positive definite matrices. Those specialized > algorithms give an important speed-up with repect to the generic > LAPACK eigenvalue problem solver used by SciPy (scipy.linalg.eig). > > hth, > tiziano > > You are running into the problems of finite-precision floating point > arithmetic. Values around 1e-15 *are* zero for practical purposes. > Since > you know that the output values should be real (up to numerical > precision), you can just take the real part. That is more or less what > Maple is doing. > > I also recommend reading "What Every Computer Scientist Should Know > About Floating-Point Arithmetic": > > http://docs.sun.com/source/806-3568/ncg_goldberg.html > > -- > Robert Kern > rkern at ucsd.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > From nwagner at mecha.uni-stuttgart.de Wed Dec 8 03:06:51 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 08 Dec 2004 09:06:51 +0100 Subject: [SciPy-user] Sparse matrix formats Message-ID: <41B6B61B.8060508@mecha.uni-stuttgart.de> Hi all, Where can I find some useful information (tutorial) concerning the different sparse matrix formats used in scipy ? Any pointer would be appreciated. Nils From reikhboerger at gmx.de Wed Dec 8 05:48:43 2004 From: reikhboerger at gmx.de (=?ISO-8859-1?Q?Reik_H._B=F6rger?=) Date: Wed, 8 Dec 2004 11:48:43 +0100 Subject: [SciPy-user] eigenvalue In-Reply-To: <20041204110806.BF9963EB6E@www.scipy.com> References: <20041204110806.BF9963EB6E@www.scipy.com> Message-ID: Hi Tiziano, I looked at the symeig-routines and I am surprised - they are working better than scipy's. I don't know, which algorithms are used, but it doesn't look like cutting off the imaginary parts. It is good enough for me :-) thanks alot Reik > You may want to have a look at: > http://mdp-toolkit.sourceforge.net/symeig.html > > The symeig module contains a Python wrapper for the LAPACK functions > to solve the standard and generalized eigenvalue problems for > symmetric (hermitian) positive definite matrices. Those specialized > algorithms give an important speed-up with repect to the generic > LAPACK eigenvalue problem solver used by SciPy (scipy.linalg.eig). > > hth, > tiziano From pearu at scipy.org Wed Dec 8 06:31:53 2004 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 8 Dec 2004 05:31:53 -0600 (CST) Subject: [SciPy-user] eigenvalue In-Reply-To: References: <20041204110806.BF9963EB6E@www.scipy.com> Message-ID: Hi, The state of including symeig to scipy is the following: lib.lapack contains all wrappers in symeig except for sygvx,hegvx lapack routines (that enable to compute only a range of eigenvalues of generalized eigenvalue problem). When these get wrapped, I'll patch scipy.eig so that it'll use more efficient lapack routines to solve eigenvalue problems of symmetric/hermitian matrices. However, one can use lib.lapack routines already to solve eigenproblems as quick as symeig. Pearu From t.zito at biologie.hu-berlin.de Wed Dec 8 06:56:18 2004 From: t.zito at biologie.hu-berlin.de (Tiziano Zito) Date: Wed, 8 Dec 2004 12:56:18 +0100 Subject: [SciPy-user] eigenvalue In-Reply-To: References: <20041204110806.BF9963EB6E@www.scipy.com> Message-ID: <20041208115618.GA26993@itb.biologie.hu-berlin.de> On Wed 08 Dec, 05:31, Pearu Peterson wrote: > > The state of including symeig to scipy is the following: lib.lapack > contains all wrappers in symeig except for sygvx,hegvx lapack routines > (that enable to compute only a range of eigenvalues of generalized > eigenvalue problem). > When these get wrapped, I'll patch scipy.eig so that > it'll use more efficient lapack routines to solve eigenvalue problems of > symmetric/hermitian matrices. However, one can use lib.lapack routines > already to solve eigenproblems as quick as symeig. How do you plan to patch scipy.linalg.eig? I suppose you are going to add a switch keyword argument. If otherwise you plan to automatically check if the matrices are symmetric (hermitian), note that the generalized symmetric eigenvalue problem Az=lBz requires B to be not only symmetric (hermitian) but also positive definite (see for example: http://www.netlib.org/lapack/lug/node34.html ). To check for positive definitiveness however would require the solution of another eigenvalue problem :)) Thank you and greetings, Tiziano and Pietro From nwagner at mecha.uni-stuttgart.de Wed Dec 8 07:00:58 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 08 Dec 2004 13:00:58 +0100 Subject: [SciPy-user] eigenvalue In-Reply-To: <20041208115618.GA26993@itb.biologie.hu-berlin.de> References: <20041204110806.BF9963EB6E@www.scipy.com> <20041208115618.GA26993@itb.biologie.hu-berlin.de> Message-ID: <41B6ECFA.2020304@mecha.uni-stuttgart.de> Tiziano Zito wrote: >On Wed 08 Dec, 05:31, Pearu Peterson wrote: > > >>The state of including symeig to scipy is the following: lib.lapack >>contains all wrappers in symeig except for sygvx,hegvx lapack routines >>(that enable to compute only a range of eigenvalues of generalized >>eigenvalue problem). >>When these get wrapped, I'll patch scipy.eig so that >>it'll use more efficient lapack routines to solve eigenvalue problems of >>symmetric/hermitian matrices. However, one can use lib.lapack routines >>already to solve eigenproblems as quick as symeig. >> >> > >How do you plan to patch scipy.linalg.eig? I suppose you are going >to add a switch keyword argument. If otherwise you plan to >automatically check if the matrices are symmetric (hermitian), note >that the generalized symmetric eigenvalue problem Az=lBz requires B >to be not only symmetric (hermitian) but also positive definite (see >for example: http://www.netlib.org/lapack/lug/node34.html ). To >check for positive definitiveness however would require the solution >of another eigenvalue problem :)) > > This is not correct. You may use a Cholesky decomposition of the matrix B, i.e B = C \diag{d_i} C^\top B is spd if all entries d_j > 0. Nils >Thank you and greetings, > >Tiziano and Pietro > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From pearu at scipy.org Wed Dec 8 07:04:54 2004 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 8 Dec 2004 06:04:54 -0600 (CST) Subject: [SciPy-user] eigenvalue In-Reply-To: <20041208115618.GA26993@itb.biologie.hu-berlin.de> References: <20041204110806.BF9963EB6E@www.scipy.com> <20041208115618.GA26993@itb.biologie.hu-berlin.de> Message-ID: On Wed, 8 Dec 2004, Tiziano Zito wrote: > On Wed 08 Dec, 05:31, Pearu Peterson wrote: >> >> The state of including symeig to scipy is the following: lib.lapack >> contains all wrappers in symeig except for sygvx,hegvx lapack routines >> (that enable to compute only a range of eigenvalues of generalized >> eigenvalue problem). >> When these get wrapped, I'll patch scipy.eig so that >> it'll use more efficient lapack routines to solve eigenvalue problems of >> symmetric/hermitian matrices. However, one can use lib.lapack routines >> already to solve eigenproblems as quick as symeig. > > How do you plan to patch scipy.linalg.eig? I suppose you are going > to add a switch keyword argument. Yes. And may be also provide scipy.linalg.symeig function. > If otherwise you plan to automatically check if the matrices are > symmetric (hermitian), No. That will be left to the user to check. I'll assume that users will know what they are doing when using scipy.linalg.symeig, for instance. > note that the generalized symmetric eigenvalue problem Az=lBz requires B > to be not only symmetric (hermitian) but also positive definite (see for > example: http://www.netlib.org/lapack/lug/node34.html ). To check for > positive definitiveness however would require the solution of another > eigenvalue problem :)) Right. Again, it's up to the user to feed correct data to scipy.linalg.symeig. It's too expensive to assume that users may want to abuse scipy.linalg.symeig:) Thanks for your notes, Pearu From janjan at ini.phys.ethz.ch Fri Dec 10 04:16:34 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Fri, 10 Dec 2004 10:16:34 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy Message-ID: <1102670194.14796.5.camel@localhost> Dear SciPy-community, The latest package of SUNDAILS (SUite of Nonlinear and DIfferential/ALgebraic equation Solvers) have just been released (BSD license). Would it make sense to integrate this in SciPy? If not, why not? (The major reason I'm still using Matlab is easy to use ode solvers.) Thanks, Jan-Jan -------- Forwarded Message -------- From: Radu Serban To: Radu Serban Subject: SUNDIALS 2.0 released Date: Thu, 09 Dec 2004 13:30:38 -0800 SUNDIALS (SUite of Nonlinear and DIfferential/ALgebraic equation Solvers) version 2.0 has been released under an open source BSD license. SUNDIALS 2.0 consists of the following four solvers: CVODE v.2.2.0 solves initial value problems for ordinary differential equation (ODE) systems. CVODES v.2.1.0 solves ODE systems and includes sensitivity analysis capabilities (both forward and adjoint). IDA v.2.2.0 solves initial value problems for differential-algebraic equation (DAE) systems. KINSOL v.2.2.0 solves nonlinear algebraic systems. SUNDIALS was implemented with the goal of providing robust time integrators and nonlinear solvers that can easily be incorporated into existing simulation codes. Basic operations on vectors are isolated to a separate module, for which the distributed package includes serial and parallel versions, but the user can supply his/her own version. The SUNDIALS solvers are written in ANSI C, with CVODE and KINSOL also providing a FORTRAN to C interface. All solvers can be built in single, double, or extended precision. More information (description, documentation, changes in the current versions) and download links can be found on the updated SUNDIALS web page: http://www.llnl.gov/CASC/sundials -- Radu Serban for the SUNDIALS team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rkern at ucsd.edu Fri Dec 10 06:03:46 2004 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 10 Dec 2004 03:03:46 -0800 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <1102670194.14796.5.camel@localhost> References: <1102670194.14796.5.camel@localhost> Message-ID: <41B98292.7050907@ucsd.edu> Jan-Jan van der Vyver wrote: > Dear SciPy-community, > > The latest package of SUNDAILS (SUite of Nonlinear and > DIfferential/ALgebraic equation Solvers) have just been released (BSD > license). Would it make sense to integrate this in SciPy? If not, why > not? (The major reason I'm still using Matlab is easy to use ode > solvers.) I don't see any showstopper reason not to. There are a handful of nitpicky reasons, however: It *is* a relatively large package; the source is about 3 MiB unpacked sans-docs. I'm not sure how many large packages Scipy can depend on. This one may be worth it, however, particularly if you can get it to work with sparse arrays. There is a bug in its build process such that "make install" doesn't work as expected on my machine (Mac OS X 10.3). It's easily worked around, however. F77 support (which would be the ideal route to a first pass via f2py) fails to configure with my setup (Fink g77 3.4.2). This is probably an error with my setup. I think this would be a great addition to Scipy. I would suggest getting it running outside of Scipy first (though depending *on* Scipy for scipy_distutils, sparse arrays, etc.). Then, when it's usable, we can integrate it into the Scipy hierarchy. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From janjan at ini.phys.ethz.ch Fri Dec 10 07:57:22 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Fri, 10 Dec 2004 13:57:22 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <41B98292.7050907@ucsd.edu> References: <1102670194.14796.5.camel@localhost> <41B98292.7050907@ucsd.edu> Message-ID: <1102683442.14796.24.camel@localhost> I had no problems with the installation. (That is it compiled and gave no errors). I used the following flags $ ./configure F77=g77 --enable-shared I am on a Gentoo system (I'll create and upload an ebuild if people want one). I also have the lam-mpi package installed, which at the moment has the --without-fc directive (hence no fortran on mpi). I'll see if I can work around that. Jan-Jan On Fri, 2004-12-10 at 03:03 -0800, Robert Kern wrote: > Jan-Jan van der Vyver wrote: > > Dear SciPy-community, > > > > The latest package of SUNDAILS (SUite of Nonlinear and > > DIfferential/ALgebraic equation Solvers) have just been released (BSD > > license). Would it make sense to integrate this in SciPy? If not, why > > not? (The major reason I'm still using Matlab is easy to use ode > > solvers.) > > I don't see any showstopper reason not to. There are a handful of > nitpicky reasons, however: > > It *is* a relatively large package; the source is about 3 MiB unpacked > sans-docs. I'm not sure how many large packages Scipy can depend on. > This one may be worth it, however, particularly if you can get it to > work with sparse arrays. > > There is a bug in its build process such that "make install" doesn't > work as expected on my machine (Mac OS X 10.3). It's easily worked > around, however. > > F77 support (which would be the ideal route to a first pass via f2py) > fails to configure with my setup (Fink g77 3.4.2). This is probably an > error with my setup. > > I think this would be a great addition to Scipy. I would suggest getting > it running outside of Scipy first (though depending *on* Scipy for > scipy_distutils, sparse arrays, etc.). Then, when it's usable, we can > integrate it into the Scipy hierarchy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From oliphant at ee.byu.edu Fri Dec 10 14:17:22 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 10 Dec 2004 12:17:22 -0700 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <1102670194.14796.5.camel@localhost> References: <1102670194.14796.5.camel@localhost> Message-ID: <41B9F642.7060707@ee.byu.edu> Jan-Jan van der Vyver wrote: >Dear SciPy-community, > >The latest package of SUNDAILS (SUite of Nonlinear and >DIfferential/ALgebraic equation Solvers) have just been released (BSD >license). Would it make sense to integrate this in SciPy? If not, why >not? (The major reason I'm still using Matlab is easy to use ode >solvers.) > >Thanks, > Jan-Jan > > Thanks for the tip, I'm curious about what you find not easy to use about the ODE solvers already in SciPy? See: http://www.scipy.org/livedocs/scipy/integrate/ode http://www.scipy.org/livedocs/scipy/integrate/odeint -Travis From janjan at ini.phys.ethz.ch Mon Dec 13 03:13:03 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Mon, 13 Dec 2004 09:13:03 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <1102683442.14796.24.camel@localhost> References: <1102670194.14796.5.camel@localhost> <41B98292.7050907@ucsd.edu> <1102683442.14796.24.camel@localhost> Message-ID: <1102925583.11682.1.camel@localhost> If you recompile lam-mpi, with the attached ebuild, and fortran keyword enabled, then everything compiles like a dream :-) Jan-Jan On Fri, 2004-12-10 at 13:57 +0100, Jan-Jan van der Vyver wrote: > I had no problems with the installation. (That is it compiled and gave > no errors). > > I used the following flags > $ ./configure F77=g77 --enable-shared > > I am on a Gentoo system (I'll create and upload an ebuild if people want > one). I also have the lam-mpi package installed, which at the moment has > the --without-fc directive (hence no fortran on mpi). I'll see if I can > work around that. > > Jan-Jan > > > > On Fri, 2004-12-10 at 03:03 -0800, Robert Kern wrote: > > Jan-Jan van der Vyver wrote: > > > Dear SciPy-community, > > > > > > The latest package of SUNDAILS (SUite of Nonlinear and > > > DIfferential/ALgebraic equation Solvers) have just been released (BSD > > > license). Would it make sense to integrate this in SciPy? If not, why > > > not? (The major reason I'm still using Matlab is easy to use ode > > > solvers.) > > > > I don't see any showstopper reason not to. There are a handful of > > nitpicky reasons, however: > > > > It *is* a relatively large package; the source is about 3 MiB unpacked > > sans-docs. I'm not sure how many large packages Scipy can depend on. > > This one may be worth it, however, particularly if you can get it to > > work with sparse arrays. > > > > There is a bug in its build process such that "make install" doesn't > > work as expected on my machine (Mac OS X 10.3). It's easily worked > > around, however. > > > > F77 support (which would be the ideal route to a first pass via f2py) > > fails to configure with my setup (Fink g77 3.4.2). This is probably an > > error with my setup. > > > > I think this would be a great addition to Scipy. I would suggest getting > > it running outside of Scipy first (though depending *on* Scipy for > > scipy_distutils, sparse arrays, etc.). Then, when it's usable, we can > > integrate it into the Scipy hierarchy. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- _/_/_/_/_/_/_/_/_/ _/ Jan-Jan van der Vyver _/ _/ _/ _/ Institut fuer Neuroinformatik _/_/_/ _/ _/_/_/_/ Universitaet / ETH Zuerich, Irchel _/ _/ _/ _/ Winterthurerstrasse 190, ZH, CH-8057 _/_/_/_/ _/ _/ _/ tel+41(0)1-6353066 fax+41(0)1-6353053 -------------- next part -------------- # Copyright 1999-2004 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-cluster/lam-mpi/lam-mpi-7.0.6.ebuild,v 1.5 2004/10/04 23:07:18 fmccor Exp $ IUSE="crypt fortran" MY_P=${P/-mpi} S=${WORKDIR}/${MY_P} DESCRIPTION="the LAM MPI parallel computing environment" SRC_URI="http://www.lam-mpi.org/download/files/${MY_P}.tar.bz2" HOMEPAGE="http://www.lam-mpi.org" DEPEND="virtual/libc" # we need ssh if we want to use it instead of rsh RDEPEND="${DEPEND} crypt? ( net-misc/openssh ) !crypt? ( net-misc/netkit-rsh ) !sys-cluster/mpich" SLOT="6" KEYWORDS="x86 ppc sparc" LICENSE="as-is" src_unpack() { unpack ${A} cd ${S}/romio/util/ sed -i "s|docdir=\"\$datadir/lam/doc\"|docdir=\"${D}/usr/share/doc/${PF}\"|" romioinstall.in } src_compile() { local myconf if use crypt; then myconf="--with-rsh=ssh" else myconf="--with-rsh=rsh" fi if use fortran; then fconf="--with-fc=g77" else fconf="--without-fc" fi econf \ --sysconfdir=/etc/lam-mpi \ --enable-shared \ --enable-long-long \ --enable-threads=posix \ --enable-languages=c,c++,f77 \ --disable-checking \ --enable-cstdio=stdio \ --with-system-zlib \ ${fconf} || \ ${myconf} || die # sometimes emake doesn't finish since it gets ahead of itself :) make || die } src_install () { make DESTDIR="${D}" install || die #need to correct the produced absolute symlink cd ${D}/usr/include rm mpi++.h ln -sf mpi2c++/mpi++.h mpi++.h # There are a bunch more tex docs we could make and install too, # but they might be replicated in the pdf. dodoc README HISTORY LICENSE VERSION cd ${S}/doc dodoc {user,install}.pdf } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From janjan at ini.phys.ethz.ch Mon Dec 13 03:13:29 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Mon, 13 Dec 2004 09:13:29 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <1102683442.14796.24.camel@localhost> References: <1102670194.14796.5.camel@localhost> <41B98292.7050907@ucsd.edu> <1102683442.14796.24.camel@localhost> Message-ID: <1102925609.11682.3.camel@localhost> If you recompile lam-mpi, with the attached ebuild, and fortran keyword enabled, then everything compiles like a dream :-) Jan-Jan On Fri, 2004-12-10 at 13:57 +0100, Jan-Jan van der Vyver wrote: > I had no problems with the installation. (That is it compiled and gave > no errors). > > I used the following flags > $ ./configure F77=g77 --enable-shared > > I am on a Gentoo system (I'll create and upload an ebuild if people want > one). I also have the lam-mpi package installed, which at the moment has > the --without-fc directive (hence no fortran on mpi). I'll see if I can > work around that. > > Jan-Jan > > > > On Fri, 2004-12-10 at 03:03 -0800, Robert Kern wrote: > > Jan-Jan van der Vyver wrote: > > > Dear SciPy-community, > > > > > > The latest package of SUNDAILS (SUite of Nonlinear and > > > DIfferential/ALgebraic equation Solvers) have just been released (BSD > > > license). Would it make sense to integrate this in SciPy? If not, why > > > not? (The major reason I'm still using Matlab is easy to use ode > > > solvers.) > > > > I don't see any showstopper reason not to. There are a handful of > > nitpicky reasons, however: > > > > It *is* a relatively large package; the source is about 3 MiB unpacked > > sans-docs. I'm not sure how many large packages Scipy can depend on. > > This one may be worth it, however, particularly if you can get it to > > work with sparse arrays. > > > > There is a bug in its build process such that "make install" doesn't > > work as expected on my machine (Mac OS X 10.3). It's easily worked > > around, however. > > > > F77 support (which would be the ideal route to a first pass via f2py) > > fails to configure with my setup (Fink g77 3.4.2). This is probably an > > error with my setup. > > > > I think this would be a great addition to Scipy. I would suggest getting > > it running outside of Scipy first (though depending *on* Scipy for > > scipy_distutils, sparse arrays, etc.). Then, when it's usable, we can > > integrate it into the Scipy hierarchy. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- # Copyright 1999-2004 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-cluster/lam-mpi/lam-mpi-7.0.6.ebuild,v 1.5 2004/10/04 23:07:18 fmccor Exp $ IUSE="crypt fortran" MY_P=${P/-mpi} S=${WORKDIR}/${MY_P} DESCRIPTION="the LAM MPI parallel computing environment" SRC_URI="http://www.lam-mpi.org/download/files/${MY_P}.tar.bz2" HOMEPAGE="http://www.lam-mpi.org" DEPEND="virtual/libc" # we need ssh if we want to use it instead of rsh RDEPEND="${DEPEND} crypt? ( net-misc/openssh ) !crypt? ( net-misc/netkit-rsh ) !sys-cluster/mpich" SLOT="6" KEYWORDS="x86 ppc sparc" LICENSE="as-is" src_unpack() { unpack ${A} cd ${S}/romio/util/ sed -i "s|docdir=\"\$datadir/lam/doc\"|docdir=\"${D}/usr/share/doc/${PF}\"|" romioinstall.in } src_compile() { local myconf if use crypt; then myconf="--with-rsh=ssh" else myconf="--with-rsh=rsh" fi if use fortran; then fconf="--with-fc=g77" else fconf="--without-fc" fi econf \ --sysconfdir=/etc/lam-mpi \ --enable-shared \ --enable-long-long \ --enable-threads=posix \ --enable-languages=c,c++,f77 \ --disable-checking \ --enable-cstdio=stdio \ --with-system-zlib \ ${fconf} || \ ${myconf} || die # sometimes emake doesn't finish since it gets ahead of itself :) make || die } src_install () { make DESTDIR="${D}" install || die #need to correct the produced absolute symlink cd ${D}/usr/include rm mpi++.h ln -sf mpi2c++/mpi++.h mpi++.h # There are a bunch more tex docs we could make and install too, # but they might be replicated in the pdf. dodoc README HISTORY LICENSE VERSION cd ${S}/doc dodoc {user,install}.pdf } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From janjan at ini.phys.ethz.ch Mon Dec 13 03:35:44 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Mon, 13 Dec 2004 09:35:44 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <41B9F642.7060707@ee.byu.edu> References: <1102670194.14796.5.camel@localhost> <41B9F642.7060707@ee.byu.edu> Message-ID: <1102926944.11682.11.camel@localhost> I apologise, that last statement was misleading (ie, wrong). As I understand the cvode(s) packages are improvements over lsoda. The cvode code (through Matlab) makes a huge difference in the integration times of my equations. It is NOT easier, just better. My bad. Keep up the good work, Jan-Jan On Fri, 2004-12-10 at 12:17 -0700, Travis Oliphant wrote: > Jan-Jan van der Vyver wrote: > > >Dear SciPy-community, > > > >The latest package of SUNDAILS (SUite of Nonlinear and > >DIfferential/ALgebraic equation Solvers) have just been released (BSD > >license). Would it make sense to integrate this in SciPy? If not, why > >not? (The major reason I'm still using Matlab is easy to use ode > >solvers.) > > > >Thanks, > > Jan-Jan > > > > > Thanks for the tip, > > I'm curious about what you find not easy to use about the ODE solvers > already in SciPy? > > See: > > http://www.scipy.org/livedocs/scipy/integrate/ode > http://www.scipy.org/livedocs/scipy/integrate/odeint > > > -Travis > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From janjan at ini.phys.ethz.ch Mon Dec 13 08:01:19 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Mon, 13 Dec 2004 14:01:19 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <41B9F642.7060707@ee.byu.edu> References: <1102670194.14796.5.camel@localhost> <41B9F642.7060707@ee.byu.edu> Message-ID: <1102942879.11682.31.camel@localhost> Dear Travis, What is difficult though is solving nonlinear coupled dfifferential equations (using Simulink at the moment :-/ ). I can write this all in one function, but that requires a rewrite everytime. I would prefer to write function objects I can place on a grid/network/graph, add an external signal, and solve for that. This is not a SciPy problem per se, but more due to my lack of experience with ODE solvers. Thanks for any kind of feedback, Jan-Jan On Fri, 2004-12-10 at 12:17 -0700, Travis Oliphant wrote: > Jan-Jan van der Vyver wrote: > > >Dear SciPy-community, > > > >The latest package of SUNDAILS (SUite of Nonlinear and > >DIfferential/ALgebraic equation Solvers) have just been released (BSD > >license). Would it make sense to integrate this in SciPy? If not, why > >not? (The major reason I'm still using Matlab is easy to use ode > >solvers.) > > > >Thanks, > > Jan-Jan > > > > > Thanks for the tip, > > I'm curious about what you find not easy to use about the ODE solvers > already in SciPy? > > See: > > http://www.scipy.org/livedocs/scipy/integrate/ode > http://www.scipy.org/livedocs/scipy/integrate/odeint > > > -Travis > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nwagner at mecha.uni-stuttgart.de Mon Dec 13 09:55:44 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Dec 2004 15:55:44 +0100 Subject: [SciPy-user] Floating-point summation Message-ID: <41BDAD70.3060203@mecha.uni-stuttgart.de> Hi all, Afaik scipy's sum(x) relies on Numeric's sum implementation. However, the result of the actual implementation of sum(x) may be inaccurate as illustrated in the small example (sum.py). Any comment ? Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: sum.py Type: text/x-python Size: 613 bytes Desc: not available URL: From rkern at ucsd.edu Mon Dec 13 12:03:05 2004 From: rkern at ucsd.edu (Robert Kern) Date: Mon, 13 Dec 2004 09:03:05 -0800 Subject: [SciPy-user] Floating-point summation In-Reply-To: <41BDAD70.3060203@mecha.uni-stuttgart.de> References: <41BDAD70.3060203@mecha.uni-stuttgart.de> Message-ID: <41BDCB49.6050501@ucsd.edu> Nils Wagner wrote: > Hi all, > > Afaik scipy's sum(x) relies on Numeric's sum implementation. > However, the result of the actual implementation of sum(x) may be > inaccurate > as illustrated in the small example (sum.py). > > Any comment ? Implement kahan_sum() in C for all types, and I'll stick it in scipy_base. I'm inclined to leave sum() as it is for performance reasons. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From david at dwavesys.com Mon Dec 13 14:50:14 2004 From: david at dwavesys.com (David Grant) Date: Mon, 13 Dec 2004 11:50:14 -0800 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <1102683442.14796.24.camel@localhost> References: <1102670194.14796.5.camel@localhost> <41B98292.7050907@ucsd.edu> <1102683442.14796.24.camel@localhost> Message-ID: <41BDF276.30001@dwavesys.com> Please upload an ebuild to bugs.gentoo.org if you can, and I'll test Dave Jan-Jan van der Vyver wrote: >I had no problems with the installation. (That is it compiled and gave >no errors). > >I used the following flags >$ ./configure F77=g77 --enable-shared > >I am on a Gentoo system (I'll create and upload an ebuild if people want >one). I also have the lam-mpi package installed, which at the moment has >the --without-fc directive (hence no fortran on mpi). I'll see if I can >work around that. > >Jan-Jan > > > >On Fri, 2004-12-10 at 03:03 -0800, Robert Kern wrote: > > >>Jan-Jan van der Vyver wrote: >> >> >>>Dear SciPy-community, >>> >>>The latest package of SUNDAILS (SUite of Nonlinear and >>>DIfferential/ALgebraic equation Solvers) have just been released (BSD >>>license). Would it make sense to integrate this in SciPy? If not, why >>>not? (The major reason I'm still using Matlab is easy to use ode >>>solvers.) >>> >>> >>I don't see any showstopper reason not to. There are a handful of >>nitpicky reasons, however: >> >>It *is* a relatively large package; the source is about 3 MiB unpacked >>sans-docs. I'm not sure how many large packages Scipy can depend on. >>This one may be worth it, however, particularly if you can get it to >>work with sparse arrays. >> >>There is a bug in its build process such that "make install" doesn't >>work as expected on my machine (Mac OS X 10.3). It's easily worked >>around, however. >> >>F77 support (which would be the ideal route to a first pass via f2py) >>fails to configure with my setup (Fink g77 3.4.2). This is probably an >>error with my setup. >> >>I think this would be a great addition to Scipy. I would suggest getting >>it running outside of Scipy first (though depending *on* Scipy for >>scipy_distutils, sparse arrays, etc.). Then, when it's usable, we can >>integrate it into the Scipy hierarchy. >> >> > > > >------------------------------------------------------------------------ > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > -- David J. Grant Scientific Officer Intellectual Property D-Wave Systems Inc. tel: 604.732.6604 fax: 604.732.6614 ************************** CONFIDENTIAL COMMUNICATION This electronic transmission, and any documents attached hereto, is confidential. The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: david.vcf Type: text/x-vcard Size: 334 bytes Desc: not available URL: From oliphant at ee.byu.edu Mon Dec 13 15:02:49 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 13 Dec 2004 13:02:49 -0700 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <1102942879.11682.31.camel@localhost> References: <1102670194.14796.5.camel@localhost> <41B9F642.7060707@ee.byu.edu> <1102942879.11682.31.camel@localhost> Message-ID: <41BDF569.2080401@ee.byu.edu> Jan-Jan van der Vyver wrote: >Dear Travis, > >What is difficult though is solving nonlinear coupled dfifferential >equations (using Simulink at the moment :-/ ). I can write this all in >one function, but that requires a rewrite everytime. I would prefer to >write function objects I can place on a grid/network/graph, add an >external signal, and solve for that. This is not a SciPy problem per se, >but more due to my lack of experience with ODE solvers. > > > Thanks for this good feedback. Does SUNDAILS code help in constructing modular solvers like this? It is certainly desireable to create tools that allow solutions that are easier and faster for the user, but I was not sure exactly what direction was wanted. The only real hindrance to incorporating code from SUNDAILS is time and issues of "code-bloat" (i.e. making sure we just grab pieces that are really solving new problems, or solving them differently). I'm also not opposed to replacing solvers in SciPy with better solvers if functionality is not lost. -Travis From giovanni.samaey at cs.kuleuven.ac.be Mon Dec 13 15:09:37 2004 From: giovanni.samaey at cs.kuleuven.ac.be (Giovanni Samaey) Date: Mon, 13 Dec 2004 21:09:37 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <41BDF569.2080401@ee.byu.edu> References: <1102670194.14796.5.camel@localhost> <41B9F642.7060707@ee.byu.edu> <1102942879.11682.31.camel@localhost> <41BDF569.2080401@ee.byu.edu> Message-ID: <41BDF701.6040300@cs.kuleuven.ac.be> > I'm also not opposed to replacing solvers in SciPy with better solvers > if functionality is not lost. > As long as the scipy interface remains the same. I suppose this can be done in a way that people using the solvers aren't forced to change all their codes that build on scipy... Giovanni From Fernando.Perez at colorado.edu Mon Dec 13 16:38:57 2004 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Mon, 13 Dec 2004 14:38:57 -0700 Subject: [SciPy-user] ANN: IPython 0.6.5 is out. Message-ID: <41BE0BF1.4060505@colorado.edu> Hi all, [I'm taking the liberty to announce this here, as many scipy/matplotlib users are also ipython users, and this release includes changes coordinated with the new matplotlib release, coming very soon. Sorry for those getting duplicates if you are on all these lists.] I'm glad to announce the release of IPython 0.6.6. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs (Py2.2 and 2.3), plus source downloads (.tar.gz and .zip). Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. Release notes ------------- This release was made to fix a few crashes recently found by users, and also to keep compatibility with matplotlib, whose internal namespace structure was recently changed. * Adapt to matplotlib's new name convention, where the matlab-compatible module is called pylab instead of matlab. The change should be transparent to all users, so ipython 0.6.6 will work both with existing matplotlib versions (which use the matlab name) and the new versions (which will use pylab instead). * Don't crash if pylab users have a non-threaded pygtk and they attempt to use the GTK backends. Instead, print a decent error message and suggest a few alternatives. * Improved printing of docstrings for classes and instances. Now, class, constructor and instance-specific docstrings are properly distinguished and all printed. This should provide better functionality for matplotlib.pylab users, since matplotlib relies heavily on class/instance docstrings for end-user information. * New timing functionality added to %run. '%run -t prog' will time the execution of prog.py. Not as fancy as python's timeit.py, but quick and easy to use. You can optionally ask for multiple runs. * Improved (and faster) verbose exeptions, with proper reporting of dotted variable names (this had been broken since ipython's beginnings). * The IPython.genutils.timing() interface changed, now the repetition number is not a parameter anymore, fixed to 1 (the most common case). timings() remains unchanged for multiple repetitions. * Added ipalias() similar to ipmagic(), and simplified their interface. They now take a single string argument, identical to what you'd type at the ipython command line. These provide access to aliases and magics through a python function call, for use in nested python code (the special alias/magic syntax only works on single lines of input). * Fix an obscure crash with recursively embedded ipythons at the command line. * Other minor fixes and cleanups, both to code and documentation. The NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. Enjoy, and as usual please report any problems. Regards, Fernando. _______________________________________________ IPython-dev mailing list IPython-dev at scipy.net http://scipy.net/mailman/listinfo/ipython-dev From nwagner at mecha.uni-stuttgart.de Tue Dec 14 06:42:55 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 14 Dec 2004 12:42:55 +0100 Subject: [SciPy-user] Floating-point summation In-Reply-To: <41BDCB49.6050501@ucsd.edu> References: <41BDAD70.3060203@mecha.uni-stuttgart.de> <41BDCB49.6050501@ucsd.edu> Message-ID: <41BED1BF.1030008@mecha.uni-stuttgart.de> Robert Kern wrote: > Nils Wagner wrote: > >> Hi all, >> >> Afaik scipy's sum(x) relies on Numeric's sum implementation. >> However, the result of the actual implementation of sum(x) may be >> inaccurate >> as illustrated in the small example (sum.py). >> >> Any comment ? > > > Implement kahan_sum() in C for all types, and I'll stick it in > scipy_base. I'm inclined to leave sum() as it is for performance reasons. > Unfortunately, I am not familiar with C, but I found a paper by Evan Manning *Manning, Evan, /Floating Point Summation/. C/C++ Users Journal , September 1996. * http://alumnus.caltech.edu/~manning/ http://www.cuj.com/ Nils From janjan at ini.phys.ethz.ch Tue Dec 14 06:44:44 2004 From: janjan at ini.phys.ethz.ch (Jan-Jan van der Vyver) Date: Tue, 14 Dec 2004 12:44:44 +0100 Subject: [SciPy-user] Incorporating SUNDIALS in SciPy In-Reply-To: <41BDF276.30001@dwavesys.com> References: <1102670194.14796.5.camel@localhost> <41B98292.7050907@ucsd.edu> <1102683442.14796.24.camel@localhost> <41BDF276.30001@dwavesys.com> Message-ID: <1103024684.22081.14.camel@localhost> Filed under Bug 74356, also see lam-mpi Bug 62561. (Needs the updated lam-mpi ebuild to build with fortran support, also compile your gcc with fortran flag set. I don't know how to enforce this in an ebuild) Any feedback on how to write better ebuilds are welcomed, Jan-Jan On Mon, 2004-12-13 at 11:50 -0800, David Grant wrote: > Please upload an ebuild to bugs.gentoo.org if you can, and I'll test > > Dave > > > Jan-Jan van der Vyver wrote: > > >I had no problems with the installation. (That is it compiled and gave > >no errors). > > > >I used the following flags > >$ ./configure F77=g77 --enable-shared > > > >I am on a Gentoo system (I'll create and upload an ebuild if people want > >one). I also have the lam-mpi package installed, which at the moment has > >the --without-fc directive (hence no fortran on mpi). I'll see if I can > >work around that. > > > >Jan-Jan > > > > > > > >On Fri, 2004-12-10 at 03:03 -0800, Robert Kern wrote: > > > > > >>Jan-Jan van der Vyver wrote: > >> > >> > >>>Dear SciPy-community, > >>> > >>>The latest package of SUNDAILS (SUite of Nonlinear and > >>>DIfferential/ALgebraic equation Solvers) have just been released (BSD > >>>license). Would it make sense to integrate this in SciPy? If not, why > >>>not? (The major reason I'm still using Matlab is easy to use ode > >>>solvers.) > >>> > >>> > >>I don't see any showstopper reason not to. There are a handful of > >>nitpicky reasons, however: > >> > >>It *is* a relatively large package; the source is about 3 MiB unpacked > >>sans-docs. I'm not sure how many large packages Scipy can depend on. > >>This one may be worth it, however, particularly if you can get it to > >>work with sparse arrays. > >> > >>There is a bug in its build process such that "make install" doesn't > >>work as expected on my machine (Mac OS X 10.3). It's easily worked > >>around, however. > >> > >>F77 support (which would be the ideal route to a first pass via f2py) > >>fails to configure with my setup (Fink g77 3.4.2). This is probably an > >>error with my setup. > >> > >>I think this would be a great addition to Scipy. I would suggest getting > >>it running outside of Scipy first (though depending *on* Scipy for > >>scipy_distutils, sparse arrays, etc.). Then, when it's usable, we can > >>integrate it into the Scipy hierarchy. > >> > >> > > > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >SciPy-user mailing list > >SciPy-user at scipy.net > >http://www.scipy.net/mailman/listinfo/scipy-user > > > > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From yichunwe at usc.edu Tue Dec 14 17:24:24 2004 From: yichunwe at usc.edu (Yichun Wei) Date: Tue, 14 Dec 2004 14:24:24 -0800 Subject: [SciPy-user] io.loadmat: TypeError Array can not be safely cast to required type Message-ID: <41BF6818.3040609@usc.edu> Hi, Sorry if you received multiple messages about this. I do not know if this is a perticular case. I was fine with io.loadmat about 1 week ago. It persuaded me to make a switch to scipy. However, when I updated my python to active python 2.3.4, the following happened: >>> import scipy.io >>> scipy.io.loadmat("test") Traceback (most recent call last): File "", line 1, in ? File "C:\Python23\Lib\site-packages\scipy\io\mio.py", line 692, in loadmat thisdict = _loadv5(fid,basename) File "C:\Python23\Lib\site-packages\scipy\io\mio.py", line 631, in _loadv5 el, varname = _get_element(fid) File "C:\Python23\Lib\site-packages\scipy\io\mio.py", line 619, in _get_element el, name = _parse_mimatrix(fid,numbytes) File "C:\Python23\Lib\site-packages\scipy\io\mio.py", line 510, in _parse_mimatrix result = squeeze(transpose(reshape(result,dims[::-1]))) TypeError: Array can not be safely cast to required type Scipy 0.3.2_266.4242 Numeric tried with 23.5 and 23.6, with the same problem Python 2.3.4 and 2.3.2 from activepython anyone can help me out? - yichun From yichunwe at usc.edu Tue Dec 14 17:35:10 2004 From: yichunwe at usc.edu (Yichun Wei) Date: Tue, 14 Dec 2004 14:35:10 -0800 Subject: [SciPy-user] io.loadmat: TypeError Array can not be safely cast to required type Message-ID: <41BF6A9E.7040806@usc.edu> I'm sorry. This is only for v6 .mat file. - yichun From nwagner at mecha.uni-stuttgart.de Wed Dec 15 10:14:44 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 15 Dec 2004 16:14:44 +0100 Subject: [SciPy-user] xplt.legend Message-ID: <41C054E4.3020406@mecha.uni-stuttgart.de> Hi all, Is it somehow possible to position the legend in a more convenient arrangement (see legend.eps for details). xplt.plot(betar,lp[:,0],betar,lp[:,1],betar,lp[:,2],betar,lp[:,3],betar,lp[:,4],betar,lp[:,5],betar,lp[:,6],betar,lp[:,7],betar,lp[:,8],betar,lp[:,9]) xplt.xlabel('!b_0') xplt.ylabel('!m_1') xplt.legend(['!a=8','!a=2','!a=0.5','!a=0.125','!a=0','!a=-0.05','!a=-0.1','!a=-0.2','!a=-0.4','!a=-2']) xplt.limits(0.,30.,0.,4.) xplt.eps('legend') Any comment or suggestion ? Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: legend.eps Type: application/postscript Size: 34862 bytes Desc: not available URL: From ronbondy at telus.net Wed Dec 15 15:37:54 2004 From: ronbondy at telus.net (Ron Bondy) Date: Wed, 15 Dec 2004 13:37:54 -0700 Subject: [SciPy-user] linalg mat - init from string? Message-ID: <002401c4e2e6$00bdca10$c77ba8c0@RONBO7AC> I'm new to scipy and am trying to use it to do some tests on a 67X67 unsymmetric matrix. The matrix is a jacobian calculated in another program and I'm looking for a way to write it out as a python script so that I can import the python script and then manually invert the matrix, calc eigenvalues etc. I'm having trouble finding a format that I can write the matrix out in. >From the scipy docs this is how to init a mat: A = mat('[1 3 5; 2 5 1; 2 3 8]') As a simple example, suppose that this is the python source: from scipy import * bstr = '[ 1 3 5; 2 3 1 ; 3.1 5.1 8.0]' A = mat(bstr) when I run this as a python script I get this error: Traceback (most recent call last): File "bb.py", line 8, in ? A = mat(bstr) File "C:\Python23\Lib\site-packages\scipy_base\ppimport.py", line 115, in __call__ return self._ppimport_attr(*args,**kwds) File "C:\Python23\Lib\site-packages\Numeric\Matrix.py", line 69, in __init__ data = _convert_from_string(data) File "C:\Python23\Lib\site-packages\Numeric\Matrix.py", line 36, in _convert_from_string newrow.extend(map(_eval,temp)) File "C:\Python23\Lib\site-packages\Numeric\Matrix.py", line 24, in _eval return eval(astr.translate(_table,_todelete)) File "", line 0 ^ SyntaxError: unexpected EOF while parsing why is the parser seeing an EOF? If someone can explain to me what the problem here is I would appreciate it. I was hoping to write out the larger matrix as a string and then construct a mat object from the string. Thanks, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From pearu at scipy.org Wed Dec 15 16:15:17 2004 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 15 Dec 2004 15:15:17 -0600 (CST) Subject: [SciPy-user] linalg mat - init from string? In-Reply-To: <002401c4e2e6$00bdca10$c77ba8c0@RONBO7AC> References: <002401c4e2e6$00bdca10$c77ba8c0@RONBO7AC> Message-ID: On Wed, 15 Dec 2004, Ron Bondy wrote: > I'm new to scipy and am trying to use it to do some tests on a 67X67 unsymmetric matrix. The matrix is a jacobian calculated in another program and I'm looking for a way to write it out as a python script so that I can import the python script and then manually invert the matrix, calc eigenvalues etc. > > I'm having trouble finding a format that I can write the matrix out in. > >> From the scipy docs this is how to init a mat: > A = mat('[1 3 5; 2 5 1; 2 3 8]') > > > As a simple example, suppose that this is the python source: > > from scipy import * > > bstr = '[ 1 3 5; 2 3 1 ; 3.1 5.1 8.0]' > A = mat(bstr) > > when I run this as a python script I get this error: > > Traceback (most recent call last): > File "bb.py", line 8, in ? > A = mat(bstr) > File "C:\Python23\Lib\site-packages\scipy_base\ppimport.py", line 115, in __call__ > return self._ppimport_attr(*args,**kwds) > File "C:\Python23\Lib\site-packages\Numeric\Matrix.py", line 69, in __init__ > data = _convert_from_string(data) > File "C:\Python23\Lib\site-packages\Numeric\Matrix.py", line 36, in _convert_from_string > newrow.extend(map(_eval,temp)) > File "C:\Python23\Lib\site-packages\Numeric\Matrix.py", line 24, in _eval > return eval(astr.translate(_table,_todelete)) > File "", line 0 > > ^ > SyntaxError: unexpected EOF while parsing > > why is the parser seeing an EOF? > > If someone can explain to me what the problem here is I would appreciate > it. I was hoping to write out the larger matrix as a string and then > construct a mat object from the string. The problem is that you have one extra space after `[' in bstr. So, try bstr = '[1 3 5; 2 3 1 ; 3.1 5.1 8.0]' mat(bstr) Similar EOF problem will occur when there would be space before `]`. I'd say its a Numeric bug. Pearu From ronbondy at telus.net Wed Dec 15 17:57:59 2004 From: ronbondy at telus.net (Ron Bondy) Date: Wed, 15 Dec 2004 15:57:59 -0700 Subject: [SciPy-user] linalg mat - init from string? References: <002401c4e2e6$00bdca10$c77ba8c0@RONBO7AC> Message-ID: <006401c4e2f9$861cb960$c77ba8c0@RONBO7AC> > > The problem is that you have one extra space after `[' in bstr. > So, try > > bstr = '[1 3 5; 2 3 1 ; 3.1 5.1 8.0]' > mat(bstr) > > Similar EOF problem will occur when there would be space before `]`. > I'd say its a Numeric bug. > > Pearu Thanks, that fixed the problem. Ron From oliphant at ee.byu.edu Thu Dec 16 00:06:59 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 15 Dec 2004 22:06:59 -0700 Subject: [SciPy-user] xplt.legend In-Reply-To: <41C054E4.3020406@mecha.uni-stuttgart.de> References: <41C054E4.3020406@mecha.uni-stuttgart.de> Message-ID: <41C117F3.7030109@ee.byu.edu> Nils Wagner wrote: > Hi all, > > Is it somehow possible to position the legend in a more convenient > arrangement (see legend.eps for details). > > xplt.plot(betar,lp[:,0],betar,lp[:,1],betar,lp[:,2],betar,lp[:,3],betar,lp[:,4],betar,lp[:,5],betar,lp[:,6],betar,lp[:,7],betar,lp[:,8],betar,lp[:,9]) > > xplt.xlabel('!b_0') > xplt.ylabel('!m_1') > xplt.legend(['!a=8','!a=2','!a=0.5','!a=0.125','!a=0','!a=-0.05','!a=-0.1','!a=-0.2','!a=-0.4','!a=-2']) > The legend is placed depending on where you click in the window (yes, some defaults should be added --- but haven't yet). You are probably clicking near the top, causing the legend to be placed there. -Travis From nwagner at mecha.uni-stuttgart.de Thu Dec 16 03:39:05 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 16 Dec 2004 09:39:05 +0100 Subject: [SciPy-user] xplt.legend In-Reply-To: <41C117F3.7030109@ee.byu.edu> References: <41C054E4.3020406@mecha.uni-stuttgart.de> <41C117F3.7030109@ee.byu.edu> Message-ID: <41C149A9.9020108@mecha.uni-stuttgart.de> Travis Oliphant wrote: > Nils Wagner wrote: > >> Hi all, >> >> Is it somehow possible to position the legend in a more convenient >> arrangement (see legend.eps for details). >> >> xplt.plot(betar,lp[:,0],betar,lp[:,1],betar,lp[:,2],betar,lp[:,3],betar,lp[:,4],betar,lp[:,5],betar,lp[:,6],betar,lp[:,7],betar,lp[:,8],betar,lp[:,9]) >> >> xplt.xlabel('!b_0') >> xplt.ylabel('!m_1') >> xplt.legend(['!a=8','!a=2','!a=0.5','!a=0.125','!a=0','!a=-0.05','!a=-0.1','!a=-0.2','!a=-0.4','!a=-2']) >> > > > The legend is placed depending on where you click in the window (yes, > some defaults should be added --- but haven't yet). > It would be nice if the legend could be placed outside the plot. (to the left or the right as default). Nils > You are probably clicking near the top, causing the legend to be > placed there. > > -Travis > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From narnett at mccmedia.com Tue Dec 21 12:22:37 2004 From: narnett at mccmedia.com (Nick Arnett) Date: Tue, 21 Dec 2004 09:22:37 -0800 Subject: [SciPy-user] Can't allocate memory for array Message-ID: <41C85BDD.8000100@mccmedia.com> I'm wondering if there's anything other than simple lack of physical memory that I should consider to deal with "Can't allocate memory for array" in \scipy\linalg\decomp.py? (Other than reducing the array size, of course!) This is on a Windows 2K machine with 2GB of physical memory and 1.5GB of swap. Nick From narnett at mccmedia.com Tue Dec 21 14:03:13 2004 From: narnett at mccmedia.com (Nick Arnett) Date: Tue, 21 Dec 2004 11:03:13 -0800 Subject: [SciPy-user] Can't allocate memory for array In-Reply-To: <41C85BDD.8000100@mccmedia.com> References: <41C85BDD.8000100@mccmedia.com> Message-ID: <41C87371.5080803@mccmedia.com> Nick Arnett wrote: > I'm wondering if there's anything other than simple lack of physical > memory that I should consider to deal with "Can't allocate memory for > array" in \scipy\linalg\decomp.py? (Other than reducing the array size, > of course!) > > This is on a Windows 2K machine with 2GB of physical memory and 1.5GB of > swap. I see in various archives that this problem has cropped up elsewhere, and like the folks who also reported it, I see that my machine is nowhere near using all the available memory when it throws the error. Nick From zhangyunfeng at gmail.com Wed Dec 22 09:32:00 2004 From: zhangyunfeng at gmail.com (zhang yunfeng) Date: Wed, 22 Dec 2004 22:32:00 +0800 Subject: [SciPy-user] wite array with 'C' or 'Fortran' format Message-ID: <4ff46d8f04122206324840786d@mail.gmail.com> hi,all I have tried to use write_array() to write a float type array, some elements are "%f" type and some are "%e" type. Because the file should be read in another program which use "%e" as format, so .. it does wrong. Is it possible to write an array with exactly "C" or "Fortran" format to a file? I have tried ScientificPython, which offers Scientific.IO.FotranFormat(). but it seems doesn't work in python 2.3.4. help please Zhang yunfeng From grante at visi.com Wed Dec 22 12:43:22 2004 From: grante at visi.com (Grant Edwards) Date: Wed, 22 Dec 2004 11:43:22 -0600 Subject: [SciPy-user] Can't get interpolate.bisplrep() to work Message-ID: <20041222174319.GA23308@grante.dsl.visi.com> I just can't figure out how to get the spline surface fitting routine interpolate.bisplrep to work. Specifically, it only seems to work for very particular grid sizes, and gives useless results for most others. In the tutorial, a 20x20 grid is used, but there is no explination how 20x20 is chosen. Most of the other grid sizes I've tried dont' work (e.g 15x15, 16x16, 20x25, 25x20, 25x25). I bought a copy of Dierckx's book, but it contains no practical information on the usage of the FITPACK library. Nor does the web site for FITPACK [http://www.netlib.org/dierckx/index.html] contain any usage information. AFAICT, the FITPACK library (upon which the interpolate module is based) spline surface fitting routine is useless for real-world problems and only suitable for tutorial purposes. Of the 11 grids tried, only 4 produced reasonable results: 13x13, 17x17, 17x19, 20x20. If the goal were to pick a grid by hand to produce a nice graph, it wouldn't be an issue, but I need to be able to fit a surface to a set of points in an automated manner without requiring a human to adjust the grid sizes to get reasonable surface fit. In my application the grid points represent physical data points and it won't be possible to "add more points" to make the library happy, and discarding points is throwing away valuable data. Here's a web page with surface plots for various grid sizes: http://www.visi.com/~grante/scipy/interpolate.html -- Grant Edwards grante at visi.com From ben.bob at gmail.com Thu Dec 23 01:28:02 2004 From: ben.bob at gmail.com (Bo Peng) Date: Thu, 23 Dec 2004 00:28:02 -0600 Subject: [SciPy-user] small problem about scipy.gplt Message-ID: <6ea7b543041222222843fe5636@mail.gmail.com> Dear list, I am using scipy.gplt to display a series of plots using repeated calls like 'plot, xtitle, ytitle, title' etc. Everything works fine except that each command will re-plot the whole figure. I mean, plot will remove all titles and xtitle etc will add them one by one. The main figure will then shrink/enlarge in a circular manner. Is there a way to tell gplt to stop drawing until I finish a sequence of commands? Many thank in advance. Bo From rspringuel at smcvt.edu Wed Dec 29 23:13:54 2004 From: rspringuel at smcvt.edu (R. Padraic Springuel) Date: Wed, 29 Dec 2004 23:13:54 -0500 Subject: [SciPy-user] Error Bars using scipy.gplt Message-ID: <41D38082.7030607@smcvt.edu> I'd like to get gnuplot to plot error bars on a graph through the scipy.gplt interface. I note that within new_plot.py in the gplt folder of scipy, there is a function for this purpose. However, I can't seem to get the correct syntax to call this function and use it. Has this routine been fully implemented yet, or is its presence an indication of a feature still in development? If it has been fully implemented, how do I go about using it? -- R. Padraic Springuel From gazzar at email.com Thu Dec 30 22:01:59 2004 From: gazzar at email.com (Gary Ruben) Date: Fri, 31 Dec 2004 13:01:59 +1000 Subject: [SciPy-user] Error Bars using scipy.gplt Message-ID: <20041231030200.6843B164002@ws1-4.us4.outblaze.com> Since no-one appears to have responded - I haven't looked for a while, but I'm not sure how complete the gnuplot via gplt errorbar support is. I never persevered enough to work it out. I agree that it would be good to see some examples in the documentation. If you decide to use either gnuplot.py or matplotlib for errorbars, then I can help, but I'll defer to others for gplt. FYI, there are a couple of examples on my site of how to do errorbars via gnuplot.py and matplotlib: http://users.bigpond.net.au/gazzar/python.html Gary R. ----- Original Message ----- From: "R. Padraic Springuel" To: scipy-user at scipy.net Subject: [SciPy-user] Error Bars using scipy.gplt Date: Wed, 29 Dec 2004 23:13:54 -0500 > > I'd like to get gnuplot to plot error bars on a graph through the > scipy.gplt interface. I note that within new_plot.py in the gplt > folder of scipy, there is a function for this purpose. However, I > can't seem to get the correct syntax to call this function and use > it. Has this routine been fully implemented yet, or is its > presence an indication of a feature still in development? If it > has been fully implemented, how do I go about using it? > > -- R. Padraic Springuel > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jdhunter at ace.bsd.uchicago.edu Fri Dec 31 08:41:43 2004 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri, 31 Dec 2004 07:41:43 -0600 Subject: [SciPy-user] ANN: matplotlib-0.70 Message-ID: matplotlib is a 2D graphics package that produces plots from python scripts, the python shell, or embeds them in your favorite python GUI -- wx, gtk, tk, fltk currently supported with qt in the works. Unlike many python plotting alternatives is written in python, so it is easy to extend. matplotlib is used in the finance industry, web application servers, and many scientific and enginneering disciplines. With a large community of users and developers, matplotlib is approaching the goal of having a full featured, high quality, 2D plotting library for python. A lot of development has gone into matplotlib since the last major release, which I'll summarize here. For details, see the notes for the incremental releases at http://matplotlib.sf.net/whats_new.html. Major changes since matplotlib-0.60 - The alpha version of the users guide - http://matplotlib.sf.net/users_guide.pdf. There are still a number of sections to be completed, but it's a start! - The matlab namespace renamed pylab - if you are upgrading from a version older than 0.64, please remove site-packages/matplotlib before upgrading. See http://matplotlib.sourceforge.net/matlab_to_pylab.py - New plot types: contour plots (contour), polar charts (polar), horizontal bar charts (barh), pie charts (pie), sparse matrix visualization (spy and spy2). Eg, http://matplotlib.sf.net/screenshots.html#polar_demo - Full ipython http://ipython.scipy.org integration in the "pylab" mode for interactive control of matplotlib plots from the python shell. - A significantly improved interactive toolbar for panning, zooming, zoom to rect - see http://matplotlib.sf.net/tutorial.html#toolbar2. - New backends: FLTK, Cairo, GTKCairo - Text - rotated mathtext, mathtext for postscript, text bounding boxes - Colormaps - 14 colormaps built-in http://matplotlib.sf.net/screenshots.html#pcolor_demo - Images - performance optimizations for 4x faster large image handling, PIL support, interpolation and colorbar improvements, imread - Event handling for capturing mouse clicks, movements, keypresses, etc. - same pylab interface works across GUIs. See examples/keypress_demo.py, examples/picker_demo.py, examples/coords_demo.py - set and get matlab style property introspection - http://matplotlib.sf.net/examples/set_and_get.py - improved dates handling for dates and date string formatting from 0000-9999, eg http://matplotlib.sf.net/screenshots.html#finance_work - Be sure to check out the 120 examples at http://matplotlib.sf.net/examples Home page : http://matplotlib.sourceforge.net Downloads : http://sourceforge.net/projects/matplotlib Screenshots : http://matplotlib.sourceforge.net/screenshots.html Tutorial : http://matplotlib.sourceforge.net/tutorial.html Credits : http://matplotlib.sourceforge.net/credits.html John Hunter