Mailman 3 January 2001 - NumPy-Discussion

Questions about organization
by Tony Seward 22 Jan '01

22 Jan '01

I've been trying to get the setup.py scripts in the Numeric distribution to build binary distributions. I have tried several things but what always ends up being a problem is the current Numeric organization, specifically LALITE and RANLIB. They just don't fit well with the distutils paradigm. If they were packaged as part of the Numeric core but were a build-time option, I think that I could get things to work much more easily. The configuration part of distutils is still a bit imature but overcomming that would just require a slightly more involved setup.py. I don't want to go ahead if there is no chance of it being accepted. Tony

3 5

multipack
by Arne Keller 19 Jan '01

19 Jan '01

I'm looking for the Multipack and cephes python modules by Travis Oliphant. The Multipack Home page link on numpy.sourceforge gives a 404... -- Arne Keller Laboratoire de Photophysique Moleculaire du CNRS, Bat. 213. Universite de Paris-Sud, 91405 Orsay Cedex, France. tel.: (33) 1 69 15 82 83 -- fax. : (33) 1 69 15 67 77

6 7

strange underflows
by Jean-Bernard Addor 16 Jan '01

16 Jan '01

Hey Numpy people! I just compiled the last NumPy. Underflows don't give zero but generate OverflowError: Python 2.0 (#2, Dec 15 2000, 15:04:31) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. Hello from .pythonrc.py >>> import Numeric >>> Numeric.__version__ '17.2.0' >>> Numeric.exp(-1.42676746e+12) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: math range error >>> How to suppress these? Any hint? Jean-Bernard

1 0

Another CXX question
by pfenn＠mmm.com 11 Jan '01

11 Jan '01

This is probably a stupid coding error, but the following code generates the error: C:\Program Files\Microsoft Visual Studio\MyProjects\Xrawdatafile\Xrawdatafile.cpp(32) : error C2065: 'FromAPI' : undeclared identifier I've marked the line in the listing that causes the error. It occurs in the function that creates a new datafile_type object to return to the interpreter. Right now the datafile_type object is very simple, and has but one method that prints a hardcoded string. I'm using CXX-4.?? with Visual C++ 6.0 and SP3. I'm going to download SP4 tonight and see if that helps, but any hints would be appreciated. I haven't been doing C++ for very long, so I'm probably mising something obvious. //**************************************************************************************************************** // Xrawdatafile.cpp : Defines the entry point for the DLL application. // #include "stdafx.h" #include <CXX/CXX_Objects.h> #include <CXX/CXX_Extensions.h> #include "Xrawdatafile.h" #include "datafile_type.h" BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } class datafile_module : Py::ExtensionModule<datafile_module> { public: datafile_module() : Py::ExtensionModule<datafile_module>("datafile") { datafile_type::init(); add_varargs_method("datafile", &datafile_module::new_datafile,"datafile(filename)"); initialize("interface to ThermoFinnigan XRaw data files."); } virtual ~datafile_module() { }; private: Py::Object new_datafile(const Py::Tuple& args) { return Py::asObject((new datafile_type())); // THIS LINE CAUSES THE ERROR } }; extern "C" __declspec(dllexport) void initdatafile(void) { static datafile_module *dfm = new datafile_module; } //****************************************************************************************************************************

1 0

Re: STL wrapper for PyArrayObject
by Phlip TheProgrammer 11 Jan '01

11 Jan '01

On Friday 05 January 2001 06:24, pfenn(a)mmm.com wrote: > Be sure to look at the CXX on sourceforge. Ja! This is a sweet combination. The Joy of Swig is we can declare some parameters as basic types, but others as raw PyObjects. Then we can have our way with these. And using CXX, we wrap these objects in high-level C++ methods. Not the low-level fragile C. The effect compares favorably to ATL for VC++ and ActiveX. But there's just one little question here. (Hence the buckshot of list servers.) If we pass a multiarray into a function expecting a PyArrayObject, how then do we add new elements to it? I tried things like 'push_back()' and 'setItem()', but they either did not exist or did not extend the array. Am I going to have to generate a new array and copy the old one into the new? --Phlip -- Phlip ======= http://users.deltanet.com/~tegan/home.html ======= ------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/

3 2

Need help fixing NumPy links on www.python.org
by Guido van Rossum 09 Jan '01

09 Jan '01

It appears that all the links to NumPy for Download and Documentation on www.python.org are broken. This looks bad for www.python.org and for Numerical Python! In particular the links on these pages are all broken: http://www.python.org/topics/scicomp/numpy_download.html link to ftp://ftp-icf.llnl.gov/pub/python/README.html http://www.python.org/topics/scicomp/documentation.html links to ftp://ftp-icf.llnl.gov/pub/python/numericalpython.pdf, ftp://ftp-icf.llnl.gov/pub/python/NumTut.tgz, and the FAQ (http://www.python.org/cgi-bin/numpy-faq) Can anybody "in the know" mail me updated links? If you have updated HTML for the pages containign the links that would be even better! Please mail directly to guido(a)python.org; I'm not subscribed to this list. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

RE: [Numpy-developers] [Bug #128025] MA seems to leak memory
by Paul F. Dubois 08 Jan '01

08 Jan '01

The helpful person who submitted this report asks for a reply but does not give their name. Thank you for finding this problem. It turns out that this is and this isn't a problem. On the whole, it is. I have a fix but need to warn people that it will break any existing code that takes advantage of a feature I did not advertise. (:-> Here's the story: class MA inherits from a class ActiveAttributes, supplied with MA as an announced module in the package. ActiveAttributes is designed to encapsulate the behavior that Numeric has, of having attributes that are not really attributes but are trios of functions. For an example of what I mean by this, consider the .shape attribute. print x.shape x.shape = (3, 9) del x.shape shape appears to be the name of an attribute but in fact it is not. There are actually a trio of handlers, so that the above actually execute more like they were print x.__getshape() x.__setshape((3,9)) x.__delattr('shape') Now for the problem. In implementing ActiveAttributes, I set up an indirect system of handlers for each "active" attribute like 'shape', and in remembering what handlers to use I carelessly used *bound* methods rather than *unbound* methods. This meant that each instance contained a reference cycle. However, Python 2.0 has a cyclic garbage collector that runs periodically so over the course of a long routine like my test routine, the garbage was in fact being collected. The bug-poster's patch reveals the problem by doing it a lot of memory operations in a very few statements. The fix is to change ActiveAttributes to save unbound rather than bound methods. This works and prevents the observed growth. I will check it in to CVS with a new release number 4.0 when I have finished testing another idea that may also be an improvement. Current users may wish to invoke the facilities of the "gc" module in 2.0 to increase the frequency of collection if they are currently experiencing a problem. To anyone out there who had noticed the activeattr.py module and used it, this change will require an incompatible change to your code when you switch to the new version. -----Original Message----- From: numpy-developers-admin(a)lists.sourceforge.net [mailto:numpy-developers-admin@lists.sourceforge.net]On Behalf Of noreply(a)sourceforge.net Sent: Monday, January 08, 2001 4:27 AM To: noreply(a)sourceforge.net; noreply(a)sourceforge.net; numpy-developers(a)sourceforge.net Subject: [Numpy-developers] [Bug #128025] MA seems to leak memory Bug #128025, was updated on 2001-Jan-08 04:26 Here is a current snapshot of the bug. Project: Numerical Python Category: Fatal Error Status: Open Resolution: None Bug Group: Robustness lacking Priority: 5 Submitted by: nobody Assigned to : nobody Summary: MA seems to leak memory Details: I executed the following code in the interpreter: >>> import MA >>> a = MA.arange(10000000) >>> b = a[:5000000] >>> b = a[:5000000] >>> b = a[:5000000] >>> b = a[:5000000] >>> b = a[:5000000] >>> b = a[:5000000] >>> b = a[:5000000] >>> b = a[:5000000] After array a was created, memory consumption was around 40 MB. After the b slices, it's now 190 MB. Even if MA does make a copy-on-slice, it should IMHO free the slice after there are no more references to it. (I am not a Sourceforge user or anything, so I would appreciate if someone would at least let me know if this is a known problem.) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128025&group_id=1369 _______________________________________________ Numpy-developers mailing list Numpy-developers(a)lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-developers

1 0

Extensions of Numpy
by Nils Wagner 06 Jan '01

06 Jan '01

Hi, I am looking for some functions for the computation of Matrix functions : matrix exponential matrix square root matrix logarithm Eigenvalue problems : generalized eigenvalue problems polynomial eigenvalue problems I am also interested in ODE (ordinary differential equation) solvers. Is there any progress ? Nils

2 1

Re: STL wrapper for PyArrayObject
by phlip 06 Jan '01

06 Jan '01

On Friday 05 January 2001 06:24, pfenn(a)mmm.com wrote: > Be sure to look at the CXX on sourceforge. Ja. This is a sweet combination. The Joy of Swig is we can declare some parameters as basic types, but others as raw PyObjects. Then we can have our way with these. And using CXX, we wrap these objects in high-level C++ methods. Not the low-level fragile C. The effect compares favorably to ATL for VC++ and ActiveX. But there's just one little question here. (Hence the buckshot of list servers.) If we pass a multiarray into a function expecting a PyArrayObject, how then do we add new elements to it? I tried things like 'push_back()' and 'setItem()', but they either did not exist or did not extend the array. Am I going to have to generate a new array and copy the old one into the new? --Phlip

1 0

Multi-distribution distributions
by Paul Prescod 05 Jan '01

05 Jan '01

I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod

2 2