[Annouce] Numeric Python 20.0.0b2
Numpy has been restructured slightly to enable use of distutils to build: Source .tar.gz Source .zip Windows installer (a real installer, not just a zip you unzip) RPM Source RPM Individual Windows installers for optional packages You can get these from http://sourceforge.net/projects/numpy. Changes are: Version 20.0 Redo setup.py so that binary windows installers for Numeric, FFT, MA, etc. can be made automatically. Packages LALITE and RANLIB merged back to top level. Adjustment for BLAS in setup.py. Documentation of Numeric module made more compatible with pydoc. argmin/argmax/argsort/sort errors with axis specs fixed (bug #233805) -- also made them capable of handling args that can be converted to arrays by adding an array(a, copy=0) at the start. Fixes sum, product, cumsum, cumproduct, alltrue, sometrue to deal with zero shape and to take arguments that can be converted to arrays. MA: See changes.txt file in MA for bug fixes and improvements. New option for average to return sum of weights. Fix bug in putmask so that it handles targets of type object. Because of reference counting issues this is done in Python, not C, and would not be more efficient than doing your own loop, but we include it for completeness. In Packages add draft implementation for PEP 0242, Numerical Kinds. Add PyArray_CopyArray to the API (Thanks to Dave Grote). Add defines for cygwin. In arrayobject.h, add static declaration to importing API pointer. May solve OS X problems. Fix bug in FFT packages, added new test. (Thanks to Warren Focke) -- <a href="http://numpy.sourceforge.net">Numerical Python</a> -- a fast array facility for Python.
Numpy has been restructured slightly to enable use of distutils to build:
wow, you really did turn things around. anyways, sounds great with the option to build all those distributions automatically (guess i'm out of a job there) :] now i'm really keyed to getting something similar for my own project. how are you building the .RPM, i didn't see a spec file anywhere? i was under the impression distutils still needed a SPEC file to do a proper RPM? anyways, i just threw a patch into the sourceforge patch manager. the code compiles and runs great on python2.0 so i thought it would be worthwhile to let the "setup.py" script also work with that version of python. i also cleaned up a couple compiler warnings. (and in the case of blas_lite.c, just turned them off with some pragma) wow, version 20. Numeric must be the highest version numbered project on sourceforge :]
Pete wrote: wow, version 20. Numeric must be the highest version numbered project on sourceforge :] My philosophy is to change the major version number if you do ANYTHING that might require changes in client code. In this case I changed things so that if someone had their own way of building (such as a static build) they might need to change their Makefile. I suppose I overdo it but version numbers are free. I had a project that used an automatic system to up the version number every time we made a build. We got to Basis 499 but then we made the next one 5.00 and stopped that system. Basis is now at a leisurely 12.0 after 16 years. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/numpy-discussion
now i'm really keyed to getting something similar for my own project. how are you building the .RPM, i didn't see a spec file anywhere? i was under the impression distutils still needed a SPEC file to do a proper RPM?
No, it creates one itself from the MANIFEST file plus some optional data given to the setup procedure. It takes some effort to get it to work, but presumably only once, so it looks like worth the effort. I did it for ScientificPython and I am quite happy with the result. However, I am not quite happy with other aspects of Distutils. I tried it on my Molecular Modelling Toolkit as well, but users will kill me if I use this in an official release. Some of the code just needs to be compiled with the highest optimization level, and there is no way I can do that with Distutils. I wonder if that could become a problem for NumPy as well - I wouldn't be surprised if the LAPACK, FFTPACK etc. code needed maximum optimization as well for good results. Did anyone do comparisons? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
On Tue, 24 Apr 2001, Konrad Hinsen wrote: [...]
if I use this in an official release. Some of the code just needs to be compiled with the highest optimization level, and there is no way I can do that with Distutils. [...]
But you can if you're willing to hack things a little bit, surely? Possibly even without hacking -- IIRC there are some things that are supposed to be subclassed in there, aren't there? I don't remember the details now, but I think that subclassing the compiler class will do it, or possibly customize_compiler()...? Neither are the proper ways, if any exist, I'm sure. From the point of view of saving time, of course, this isn't ideal. John
On Tue, 24 Apr 2001, Konrad Hinsen wrote: [...]
if I use this in an official release. Some of the code just needs to be compiled with the highest optimization level, and there is no way I can do that with Distutils. [...]
But you can if you're willing to hack things a little bit, surely? Possibly even without hacking -- IIRC there are some things that are
It would be quite serious hacking. Distutils just calls the compiler exactly as it was called for compiling the Python interpreter. To change the optimization level, I'd have to parse the command to extract any optimization options, remove them, and put my own instead. I can't imagine anything more platform-dependent. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
On Wed, 25 Apr 2001, Konrad Hinsen wrote: [...]
It would be quite serious hacking. Distutils just calls the compiler exactly as it was called for compiling the Python interpreter. To change the optimization level, I'd have to parse the command to extract any optimization options, remove them, and put my own instead. I can't imagine anything more platform-dependent. [...]
Okay, you have higher standards than me. :) I was imagining just sticking in an '-O' somewhere, or similar. John
Okay, you have higher standards than me. :) I was imagining just sticking in an '-O' somewhere, or similar.
For Linux, for example, I need to replace -O2 by -O3, and only for some files, as others don't work with O3 optimization. Not so simple. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (4)
-
John J. Lee -
Konrad Hinsen -
Paul F. Dubois -
Pete Shinners