Mailman 3 December 2001 - NumPy-Discussion

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?
by Konrad Hinsen 07 Dec '01

07 Dec '01

"eric" <eric(a)enthought.com> writes: > as a widely used tool. If you require multiple installations, you loose a > huge number of potential users. In the early days of NumPy, I had a similar problem because many people didn't succeed in installing it properly. I ended up preparing a specially packaged Python interpreter with NumPy plus my own scientific modules. With increasingly frequent releases of NumPy and Python itself, this became impossible to keep up. And since we have distutils, installation questions became really rare, being mostly about compatibility of my code with this or that version of NumPy (due to the change in the C API export). On the other hand, I work in a community dominated by Unix users, who come in two varieties: Linux people, who just get RPMs, and others, who typically have a competent systems administrator. The Windows world might have different requirements. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen(a)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 -------------------------------------------------------------------------------

1 0

RE: Rounding errors in add.reduce?
by sag＠hydrosphere.com 06 Dec '01

06 Dec '01

Well, never mind. I figured out that my test variables silently went to double precision, and that this is a case precision issues, not rounding error. So, I guess I will have to force my arrays to double precision. Sorry to bother the list. sue

1 0

Rounding errors in add.reduce?
by sag＠hydrosphere.com 06 Dec '01

06 Dec '01

import MA I have been using add.reduce on some arrays with single precision data in them. At some point, the reduction seems to be producing incorrect values, caused I presume by floating point rounding errors. THe values are correct if the same array is created as double precision. The odd things is that I can do a straight summing of those values into long, single or double variable and get correct answers. Is this a bug or what? If the difference is due to rounding error, I would expect the same errors to show up in the cases of summing the individual values. The output from the following code shows the following. Note that the add.reduce from the single precision array is different from all the others. It doesn't matter the rank or size of array, just so sum of values gets to certain size. accumulated sums float 75151440.0 long 75151440 accumulated from raveled array float 75151440.0 double 75151440.0 add.reduce single 75150288.0 double 75151440.0 --- code --- import MA # this causes same problem if array is 1d of [amax*bmax*cmax] in len amax = 4 bmax = 31 cmax = 12 farr = MA.zeros((amax, bmax, cmax), 'f') # single float darr = MA.zeros((amax, bmax, cmax), 'd') # double float sum = 0.0 lsum = 0 value = 50505 # reducing this can cause all values to agree for a in range (0, amax): for b in range (0, bmax): for c in range (0, cmax): farr[a, b, c] = value darr[a, b, c] = value sum = sum + value lsum = lsum + value fflat = MA.ravel(farr) dflat = MA.ravel(darr) fsum = dsum = 0.0 for value in fflat: fsum = fsum + value for value in dflat: dsum = dsum + value freduce = MA.add.reduce(fflat) dreduce = MA.add.reduce(dflat) print "accumulated sums" print "\tfloat\t", sum, "\tlong ", lsum print "accumulated from raveled array" print "\tfloat\t", fsum, "\tdouble", dsum print "add.reduce" print "\tsingle\t", freduce, "\tdouble", dreduce

1 0

Problem with MacOsX
by oli 06 Dec '01

06 Dec '01

Hi, I have tried to compile Numpy for MacOsX but it doesn't compile the C modules... Have anyone not this problem? Thanks oli

2 1

Using objects in arrays
by sag＠hydrosphere.com 04 Dec '01

04 Dec '01

I am trying to use objects in an array, and still be able to use the various extra functions offered by multiarray. I am finding that some of the functions work and some don't. Is it hopeless to try to use objects in an array and expect <op>.reduce and others to work properly? As a simple example, I have a DataPoint object that consists of a value and flag(s). This object has all the __cmp__, __add_, etc functions implemented. I can do MA.average(m), MA.sum(m), MA.add.reduce(m), (they seem to use __add__) but I can't do MA.minimum.reduce(m) or MA.maximum.reduce(m). I can do MA.maximum(m) and MA.minimum(m), but not MA.maximum(m, 0) or MA.minimum(m, 0) The values returned by MA.argmax(m) makes no sense (wrong index?) but is consistent with results from argsort(). MA.argmin(m) gives an error (I have a __neg__ fn in datapoint) File "C:\Python21\MA\MA.py", line 1977, in argmin return Numeric.argmin(d, axis) File "C:\Python21\Numeric\Numeric.py", line 281, in argmin a = -array(a, copy=0) TypeError: bad operand type for unary - for example: print m # 3 valid, 1 masked print MA.maximum(m) print MA.argmax(m) # gives index to masked value print MA.minimum(m) #print MA.argmin(m) - gives error above print MA.argsort(m) print MA.average(m) print MA.maximum.reduce(m, 0) [1, ] ,[10, a] ,[None, D] ,-- ,] [10, a] 3 [None, D] [2,0,1,3,] [3.66666666667, aD] Traceback (most recent call last): File "C:\Python21\Pythonwin\pywin\framework\scriptutils.py", line 301, in RunScript exec codeObject in __main__.__dict__ File "C:\Python21\HDP\Data\DataPoint.py", line 136, in ? print MA.maximum.reduce(m, 0) File "C:\Python21\MA\MA.py", line 1913, in reduce t = Numeric.maximum.reduce(filled(target, maximum_fill_value(target)), axis) TypeError: function not supported for these types, and can't coerce to supported types

2 2

ANN: F2PY - Fortran to Python Interface Generator
by Pearu Peterson 04 Dec '01

04 Dec '01

F2PY - Fortran to Python Interface Generator I am pleased to announce the third public release of f2py (2nd Edition) (version 2.3.328): http://cens.ioc.ee/projects/f2py2e/ f2py is a command line tool for binding Python and Fortran codes. It scans Fortran 77/90/95 codes and generates a Python C/API module that makes it possible to call Fortran subroutines from Python. No Fortran or C expertise is required for using this tool. Features include: *** All basic Fortran types are supported: integer[ | *1 | *2 | *4 | *8 ], logical[ | *1 | *2 | *4 | *8 ], character[ | *(*) | *1 | *2 | *3 | ... ] real[ | *4 | *8 | *16 ], double precision, complex[ | *8 | *16 | *32 ] *** Multi-dimensional arrays of (almost) all basic types. Dimension specifications: <dim> | <start>:<end> | * | : *** Supported attributes and statements: intent([ in | inout | out | hide | in,out | inout,out ]) dimension(<dimspec>) depend([<names>]) check([<C-booleanexpr>]) note(<LaTeX text>) optional, required, external NEW: intent(c), threadsafe, fortranname *** Calling Fortran 77/90/95 subroutines and functions. Also Fortran 90/95 module subroutines are supported. Internal initialization of optional arguments. *** Accessing COMMON blocks from Python. NEW: Accessing Fortran 90/95 module data. *** Call-back functions: calling Python functions from Fortran with very flexible hooks. *** In Python, arguments of the interfaced functions may be of different type - necessary type conversations are done internally in C level. *** Automatically generates documentation (__doc__,LaTeX) for interfaced functions. *** Automatically generates signature files --- user has full control over the interface constructions. Automatically detects the signatures of call-back functions, solves argument dependencies, etc. NEW: * Automatically generates setup_<modulename>.py for building extension modules using tools from distutils and fortran_support module (from SciPy). *** Automatically generates Makefile for compiling Fortran and C codes and linking them to a shared module. Many compilers are supported: gcc, Compaq Fortran, VAST/f90 Fortran, Absoft F77/F90, MIPSpro 7 Compilers, etc. Platforms: Intel/Alpha Linux, HP-UX, IRIX64. *** Complete User's Guide in various formats (html,ps,pdf,dvi). *** f2py users list is available for support, feedback, etc. NEW: * Installation with distutils. *** And finally, many bugs were fixed. More information about f2py, see http://cens.ioc.ee/projects/f2py2e/ LICENSE: f2py is released under the LGPL. Sincerely, Pearu Peterson <pearu(a)cens.ioc.ee> December 4, 2001 <P><A HREF="http://cens.ioc.ee/projects/f2py2e/">f2py 2.3.328</A> - The Fortran to Python Interface Generator (04-Dec-01)

1 0

question about Windows installer
by Gerard Vermeulen 04 Dec '01

04 Dec '01

Hi, Could somebody tell me if the Numeric executable installer for Windows is made with distutils? Thanks -- Gerard

1 0

limits.py?
by John J. Lee 03 Dec '01

03 Dec '01

Is there some equivalent of limits.h for Numeric? And is there a searchable archive for the numpy-discussion list?? IIRC, the standard sourceforge lists aren't searchable (?!), which is bizarre if true. John

2 1