Mailman 3 December 2002 - NumPy-Discussion

Two bugs in numerictypes.py
by Edward C. Jones 23 Jan '03

23 Jan '03

In "numerictypes.py' it says "This module is designed so 'from numerictypes import *' is safe." When I "import numerictypes", and run dir(), I get: ['Any', 'AnyType', 'Bool', 'BooleanType', 'Byte', 'Complex', 'Complex32', 'Complex64', 'ComplexType', 'Double', 'Float', 'Float32', 'Float64', 'FloatingType', 'Int', 'Int16', 'Int32', 'Int64', 'Int8', 'IntegralType', 'Long', 'MAX_ALIGN', 'NumericType', 'Short', 'SignedIntegralType', 'SignedType', 'UInt16', 'UInt32', 'UInt64', 'UInt8', 'UnsignedIntegralType', 'UnsignedType', '__builtins__', '__doc__', '__name__', 'genericCoercions', 'genericPromotionExclusions', 'genericTypeRank', 'inttype1', 'inttype2', 'kind', 'mapto', 'maptype1', 'maptype2', 'nt1', 'nt2', 'ntypesize1', 'ntypesize2', 'numinclude', 'outtype', 'pythonTypeMap', 'pythonTypeRank', 'rank1', 'rank2', 'scalarTypeMap', 'signedtype1', 'signedtype2', 'typeDict', 'typecode', 'typecodes'] A bunch of leading "_" are needed. ---------------- My code is: #! /usr/bin/env python from numerictypes import UInt8 print UInt8 == "ABC" The message is: Traceback (most recent call last): File "./silly02.py", line 5, in ? print UInt8 == "ABC" File "/usr/lib/python2.2/site-packages/numarray/numerictypes.py", line 101, in __cmp__ other = typeDict[other] KeyError: ABC I would expect that the only object == to UInt8 be itself. Maybe add a function comparetypecodes(x, y) which returns True iff x and y are either NumericType's or strings which represent the same type.

3 4

Bin selection
by Magnus Lie Hetland 16 Jan '03

16 Jan '03

I have a set of limits, e.g. array([0, 35, 45, 55, 75]) and I want to use these to "classify" a set of numbers (another one-dimensional array). The "class" is the number of the first limit that is lower than or equal to the number I want to classify. E.g. I'd classify 17 as 0 and 42 as 1. My current approach is: sum(nums[:,NewAxis] >= lims, dim=-1) It seems a bit unnecessary to compare each number with all the limits when O(log(n)) would suffice (the limits are ordered); or even with O(n) running time, a smarter implementation could get an average of n/2 comparisons... Suggestions? -- Magnus Lie Hetland http://hetland.org

7 15

Re: [Numpy-discussion] argsort on CharArrays?
by Todd Miller 31 Dec '02

31 Dec '02

Magnus Lie Hetland wrote: >Todd Miller <jmiller(a)stsci.edu>: > > >>Magnus Lie Hetland wrote: >> >> >> >>>Is there any way to make argsort work on CharArrays? >>> >>> >>> >>Not yet. >> >> > >OK, thanks. > >(I don't mean to nag -- I'm just eager about numarray :) > > Don't worry about nagging. All this feedback is good. Results, however, may take a little time. >>Todd >> >> Todd

1 0

Lists in fromfile shape?
by Magnus Lie Hetland 31 Dec '02

31 Dec '02

I just noticed that the shape argument in fromfile cannot be an unhashable sequence. I assume tuples are the norm, but still -- it would be nice to accept other sequences? And... I also saw an explicit type check in fromfile, comparing _type(file) with _type("") -- what if I supplied some other string-like object? Perhaps a try/except with file+"" would be appropriate, to check for "string-like-ness" instead of an explicit type check? (I've just grown suspicious of typechecking in general...) Sorry if I'm being a pest, nagging about all these details, but I expect it may be useful to get them resolved? :] -- Magnus Lie Hetland http://hetland.org

1 1

argsort on CharArrays?
by Magnus Lie Hetland 31 Dec '02

31 Dec '02

Is there any way to make argsort work on CharArrays? -- Magnus Lie Hetland http://hetland.org

2 1

PEP 242 Numeric kinds
by Paul F Dubois 30 Dec '02

30 Dec '02

We had put off consideration of PEP 242 Numeric kinds until June 2002 when a meeting of some interested parties was to occur but the meeting didn't occur. I have a draft implementation and users of it but my feeling is that although correct and useful the PEP is not useful enough to put it in the standard library. Since it really only interests scientific programmers I propose simply making it a separate deliverable on the Numeric site and withdrawing the PEP.

6 7

Yet another bug
by Magnus Lie Hetland 30 Dec '02

30 Dec '02

Hi, there... I just found another bug :] from numarray import arange from __future__ import division arange(10) / 10 ... This will give an error. I really think this "real" division should be supported for arrays... -- Magnus Lie Hetland http://hetland.org

2 1

Compiling from CVS?
by Magnus Lie Hetland 30 Dec '02

30 Dec '02

I guess I'm just missing something obvious here: How do I compile numarray from the cvs dist? It seems like files such as numconfig.h etc. are missing -- it seems to have been generated by setup.py in the normal distributions, but I'm not sure how to do that... I just expected "python setup.py build" to work :] -- Magnus Lie Hetland http://hetland.org

2 1

indices with list arg?
by Magnus Lie Hetland 30 Dec '02

30 Dec '02

Why isn't indices([42]) (or foo.setshape([42]), for that matter) allowed? Overzealous type checking, or a necessity of the C code? -- Magnus Lie Hetland http://hetland.org

2 2

average()...?
by Magnus Lie Hetland 29 Dec '02

29 Dec '02

Just a quick question (which I believe I have asked before sometime, but I don't recall the outcome ;) -- why is the average() function from MaskedArray not available in numarray? It seems like a very useful function? It seems that looking through the list of functions in MaskedArray might be useful in finding candidates for numarray, in so far as they differ. (Wouldn't be logical if they supported the same functions, more or less?) For example, MaskedArray has the function count(), which counts the number of elements in an array -- exactly what was asked for yesterday, IIRC. (The use may be more obvious for masked arrays, where it counts non-masked elements, but it works on plain arrays too.) If nothing else, perhaps it would be possible to put from MA import count, average in numarray.py? (And similarly for other functions that may be missing in numarray -- I didn't check that closely.) Of course this wouldn't work if MA isn't available... :/ -- Magnus Lie Hetland http://hetland.org

1 0

Non-numerical info associated with sub-arrays
by Magnus Lie Hetland 28 Dec '02

28 Dec '02

I'm working on some two-dimensional tables of data, where some data are numerical, while other aren't. I'd like to use numarray's numerical capabilities with the numerical parts (columns) while keeping the data in each row together. (I'm sure this generalizes to more dimensions, and to sub-arrays in general, not just rows.) It's not a hard problem, really, but the obvious solution--to keep the other rows in separate arrays/lists and just juggle things around--seems a bit clunky. I was just wondering if anyone had other ideas (would it be practical to include all the data in a single array somehow--I seem to recall that Numeric could have arbitrary object arrays, but I'm not sure whether numarray supports this?) or perhaps some hints on how to organize code around this? I wrote a small class that wraps things up and works a bit lik R/S-plus's data frames; is there some other more standard code out there for this sort of thing? (It's a problem that crops up often in data processing of various kinds...) Thanks, Magnus -- Magnus Lie Hetland http://hetland.org

4 10

Increased polymorphism?
by Magnus Lie Hetland 28 Dec '02

28 Dec '02

I know PyObject arrays aren't supported in numarray yet -- but how about making the functions more polymorphic? Yes, they work on other sequence types such as lists -- but there seems to be quite a bit of type checking going on. I suppose that is necessary for performance reasons, but how about some polymorphic behaviour in the cases where an unknown type is encountered? It would be nice, for example, if sum() worked on general iterators and generators, and if argsort() worked on, e.g., lists of strings... This would make it easier to integrate the purely numeric stuff with other parts of Python programs... It may be that I'm going beyond the scope of numarray here, but this sort of agnostic signature-based polymorphism is very Pythonic. -- Magnus Lie Hetland http://hetland.org

1 0

from RandomArray2 import *?
by Magnus Lie Hetland 28 Dec '02

28 Dec '02

I just tried a starred import from RandomArray2, but it seems that it didn't work properly -- e.g. the uniform function wasn't imported. And I can't see any __all__ attribute; what's going on? -- Magnus Lie Hetland http://hetland.org

2 1

Further comments
by Edward C. Jones 28 Dec '02

28 Dec '02

Should the variable "type" be used in numarray? It is an important function in Python. --------------------------------------- There needs to be a function or method that returns the number of elements in an array. def Elements(array): """Number of elements in an array. This version is slow. """ return numarray.multiply.reduce(array.shape) --------------------------------------- I write code using both PIL and numarray. PIL uses strings for modes and numarray uses (optionally) strings as typecodes. This causes problems. One fix is to emit a DeprecationWarning when string typecodes are used. Two functions are needed: StringTypeWarningOn and StringTypeWarningOff. The default should be to ignore this warning. In my code I use the following workarounds: def SameType(x, y): """Are the two input the same object of NumericType?""" if isinstance(x, NumericType) and isinstance(y, NumericType) \ and x == y: return True return False def IsTypeInList(typecode, seq): """Is a NumericType object in a list of NumericType objects?""" if not isinstance(typecode, NumericType): return False for item in seq: if isinstance(item, NumericType) and typecode == item: return True return False --------------------------------------- The following function is useful for downsizing arrays. I suggest that it should be a ufunc method. This is how I have used reduceat in Numeric. def blockreduce(array, blocksizes, ufunc): """Apply ufunc.reduce to blocks in an array.""" dims = len(array.shape) if type(blocksizes) is IntType: blocksizes = dims * [blocksizes] if len(blocksizes) != dims: raise TypeError, 'blocksizes must be same length as shape' for i in range(dims): if array.shape[i] % blocksizes[i] != 0: raise ValueError, 'blocksizes must exactly divide ' \ 'the corresponding array dimension' for i in range(dims): array = array.copy() newshape = (array.shape[0] / blocksizes[i], blocksizes[i]) + \ array.shape[1:] array.shape = newshape array = ufunc.reduce(array, 1) dims = len(array.shape) # (0,1,2,3) --> (1,2,3,0) perm = tuple(range(1, dims)) + (0,) array = numarray.transpose(array, perm) return array

3 2

"<<", ">>" undocumented
by Edward C. Jones 22 Dec '02

22 Dec '02

The operators "<<" and ">>" seem to be undocumented. Is there a reason for this? Ed Jones

1 0

bug in Numeric, LinearAlgebra
by Cong 21 Dec '02

21 Dec '02

I've just upgraded from Numeric-21.0 to Numeric-22.0 ( python-2.2.2 ) and found a bug. Do anyone use LinearAlgebra too ? Now, I downed it to Numeric 21.0 . This version works very well. Cong $ python Python 2.2.2 (#1, Dec 14 2002, 05:45:37) [GCC 3.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import LinearAlgebra Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.py", line 10, in ? import MLab File "/usr/lib/python2.2/site-packages/Numeric/MLab.py", line 20, in ? import RandomArray File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 30, in ? seed() File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 24, in seed ndigits = int(math.log10(t)) OverflowError: float too large to convert

1 1

howto build numarray 0.4 ? file 'Src/_convmodule.c' does not exist
by Sebastian Haase 19 Dec '02

19 Dec '02

Hi all, I downloaded numarray 0.4 about 5 minutes after I got the announce but my naive 'python2.2 ./setup.py build' gives this haase@baboon:~/numarray-0.4: python2.2 ./setup.py build running build running build_py not copying Lib/ndarray.py (output up-to-date) not copying Lib/numtest.py (output up-to-date) not copying Lib/codegenerator.py (output up-to-date) not copying Lib/ufunc.py (output up-to-date) not copying Lib/testdata.py (output up-to-date) not copying Lib/numarray.py (output up-to-date) not copying Lib/ieeespecial.py (output up-to-date) not copying Lib/recarray.py (output up-to-date) not copying Lib/template.py (output up-to-date) not copying Lib/arrayprint.py (output up-to-date) not copying Lib/typeconv.py (output up-to-date) not copying Lib/numinclude.py (output up-to-date) not copying Lib/numarrayext.py (output up-to-date) not copying Lib/_ufunc.py (output up-to-date) not copying Lib/chararray.py (output up-to-date) not copying Lib/numtestall.py (output up-to-date) not copying Lib/numerictypes.py (output up-to-date) not copying Lib/memmap.py (output up-to-date) running build_ext building '_conv' extension error: file 'Src/_convmodule.c' does not exist What am I missing? I'm running Linux (debian woody) on i386. Thanks, Sebastian

3 4

Comments on numarray - 4
by Edward C. Jones 18 Dec '02

18 Dec '02

The optional shape argument to fromstring is not documented. ----------------- I suggest a documentation section on NumericTypes. "Int8.bytes" and need documenting. ---------------- Table of Automatic Coercions (found by experiment) B I8 U8 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 ------------------------------------------------------------------ B | *I8 I8 U8 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 I8 | I8 *I16 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 U8 | U8 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 I16 | I16 *I32 I32 U32 I64 U64 F32 F64 C32 C64 U16 | U16 I32 U32 I64 U64 F32 F64 C32 C64 I32 | I32 *I64 I64 U64 F32 F64 C32 C64 U32 | U32 I64 U64 F32 F64 C32 C64 I64 | I64 *I64 ?F32 F64 C32 C64 U64 | U64 ?F32 F64 C32 C64 F32 | F32 F64 C32 C64 F64 | F64 ?C32 C64 C32 | C32 C64 C64 | C64 The names are listed in the order used in "numerictypes.py". The "*" cases are exceptions treated there. Are the "?" conversions correct? See "genericPromotionExclusions" in "numerictypes.py".

2 1

Re: [Numpy-discussion] Index array confusion...
by Magnus Lie Hetland 16 Dec '02

16 Dec '02

Todd Miller <jmiller(a)stsci.edu>: > [snip] > What I'm saying is that in the future it will work correctly. :) OK :) > Most likely as you suggest, but I haven't really looked at the code, > just the rather sickening results. Well, what I was asking about was really what you meant by "correct". My interpretation of "correct" here was that only tuples and slices would be allowed as indexes. BTW: I found something else that I think is rather odd: >>> x = [0, 0, 0] >>> y = [1, 1, 1] >>> p = 1 >>> x[p:], y[p:] = y[p:], x[p:] >>> x, y ([0, 1, 1], [1, 0, 0]) >>> x = array([0, 0, 0]) >>> y = array([1, 1, 1]) >>> x[p:], y[p:] = y[p:], x[p:] >>> x, y (array([0, 1, 1]), array([1, 1, 1])) This seems like a bug to me. The assignment ought to swap the tails of the sequences, as is the case with lists, but with numeric arrays, some weird form of overwriting occurs. I guess this may be an optimization (i.e. to avoid making copies), but it is rather confusing. What do you think? > Todd -- Magnus Lie Hetland Practical Python The Anygui Project http://hetland.org http://ppython.com http://anygui.org

3 7

Re: numarray questions
by Todd Miller 16 Dec '02

16 Dec '02

Mika Illouz wrote: >Hi Todd, > > > >>Thanks for the encouragement! numarray-0.4 is coming out today... >> >> > >Finally got around to playing with version 0.4 and the new NA_New (code >attached). Wnen I ran the test, I got the following trace: > > > >>>>import _test_numarray >>>>z = _test_numarray.t1() >>>> >>>> >Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/lib/python2.2/site-packages/numarray/numarray.py", line 432, in __init__ > bytestride=bytestride) > File "/usr/lib/python2.2/site-packages/numarray/ndarray.py", line 173, in __init__ > self._data = memory.new_memory(size) >OverflowError: long int too large to convert to int > >What am I doing wrong? > The parameter order in the call in t1() should be: NA_New(a, tInt32, 1, length) Because it is: NA_New(a, tInt32, length, 1) numarray thinks you're declaring a 5 dimensional array with some bizarre dimensions from "undefined values" on the stack. One of these dimensions appears to be > MAX_INT. >Thanks again, >Mika > > Regards, Todd > > >------------------------------------------------------------------------ > >#include <Python.h> >#include <libnumarray.h> > >static PyObject* t1( PyObject* self, PyObject* args ) >{ > int length = 5; > int* a = new int[ length ]; > for ( int i = 0 ; i < length ; i++ ) { > a[i] = i; > } > > PyArrayObject* vec = NA_New( a, tInt32, length, 1 ); > return (PyObject*)vec; > // return NA_ReturnOutput( NULL, vec ); > >} > >static PyMethodDef TestNumarrayMethods[] = { > {"t1", > t1, > METH_VARARGS, > "first test" > }, > { NULL, NULL, 0, NULL} >}; > >extern "C" void init_test_numarray() >{ > Py_InitModule( "_test_numarray", TestNumarrayMethods ); > import_libnumarray(); >} > >

1 0

"not"
by Magnus Lie Hetland 15 Dec '02

15 Dec '02

Just a quick note: Why does the operator 'not' appear in parentheses beside logical_not in the manual? Isn't that a bit misleading (since it doesn't work the same way, as opposed to 'and' and 'or')? -- Magnus Lie Hetland Practical Python The Anygui Project http://hetland.org http://ppython.com http://anygui.org

1 0

Index array confusion...
by Magnus Lie Hetland 15 Dec '02

15 Dec '02

I can see why this happens, to some degree, but it is a bit confusing still: >>> a = zeros([5,5]) >>> a[[1,2,3]] array([[0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0]]) >>> a[[1,2]] 0 >>> a[[1]] array([[0, 0, 0, 0, 0]]) I was planning to use index arrays to select a subset of the rows in a two-dimensional array, but because of the special-casing for one-dimensional arrays of the same length as the dimensionality of the array being indexed, it seems I can't do that (without using put/take, which may be quite OK, I guess)... Am I right? (I see why this behaviour is needed for tuples and slice objects; and I guess type checking would be sort of "ugly"...) Of course a[[1,2],] works just as expected. This may not be important, but perhaps worth a sentence or example in the manual? I.e. if you are using an index array idx and you don't want to risk having it cast as a single index lookup, you should do a[idx,] Wouldn't that be sound advice in general? -- Magnus Lie Hetland Practical Python The Anygui Project http://hetland.org http://ppython.com http://anygui.org

2 2

Comments on numarray - 3
by Edward C. Jones 13 Dec '02

13 Dec '02

NA_OFFSETDATA is mentioned during the example in 10.2.3. It should be documented in 10.2.1. Should some of the other macros in "nummacro.h" be documented? Also the macros in "arrayobject.h" and "numcomplex.h". ------------------- The "libnumarray_UNIQUE_SYMBOL" trick discussed in "libnumarray.h" has been useful with Numeric and will be useful with numarray. It needs to be in the main documentation. I think it is mentioned somewhere in the Python documentation. I found it very confusing the first time I used it. A detailed example is needed. ------------------- "NA_longsFromIntTuple" works on both tuples and lists. A better name might be "NA_longsFromIntSequence". Functions of this type have proven _very_ useful for me in writing large SWIG wrappers. I generate them using SWIG macros. Here are some of them. On the C side, auxillary information about the lengths of things needs to be dealt with. "list" means "list or tuple". Python C list of ints <--> array of ints list of floats <--> array of doubles list of floats <--> array of floats ... list of strings <--> array of arrays of char list of lists of ints <--> array of arrays of int ... list <--> array of PyObject* Thanks, Ed Jones

1 0

Comments on Documentation - 2
by Edward C. Jones 13 Dec '02

13 Dec '02

I am currently learning about numarray. Here are further comments on the documentation. ---------------------- "libnumarray.h" and "numarray.h" are never mentioned in the docs. ---------------------- 10.2.3 Is "free(result)" needed here? double *result; int m, n; . . . result = func(...); if(NULL == result) return NULL; return NA_New((void *)result, tFloat64, m, n, 2); ---------------------- 10.6 "NA_New", "NA_Empty", and "NA_NewA11" return a "PyArrayObject*", not a "PyObject*".

1 0

3 comments on numarray documentation
by Edward C. Jones 13 Dec '02

13 Dec '02

To access UInt8, etc, from numerictypes import * Maybe mention this in 4.2.1. ------- In 4.7 Only one "..." is expanded in an index expression, so if one has a rank-5 array C, then C[...,0,...] is the same thing as C[:,:,:,0,:]. So an unexpanded "..." is treated as a ':'? ---------- In 5.1.1, >>> a = arange(5, type=Float64) >>> print a[::-1] * 1.2 [ 4.8 3.6 2.4 1.2 0. ] >>> multiply(a[::-1], 1.2, a) >>> a array([ 4.8 , 3.6 , 2.4 , 1.2, 0. ]) doesn't make the desired point. Try: >>> a = arange(5, type=Int32) >>> a [0 1 2 3 4] >>> print a[::-1] * 1.2 [ 4.8 3.6 2.4 1.2 0. ] >>> multiply(a[::-1], 1.2, a) >>> a array([4 3 2 1 0]) Why does Python documentation always use the interpreter? I doubt if it is used much. Why not: a = arange(5, type=Int32) print a.type(), a b = a[::-1] * 1.2 print b.type(), b numarray.multiply(a[::-1], 1.2, a) print a.type(), a

3 2

Some questions about PyArray_As2D.
by Andrea Riciputi 12 Dec '02

12 Dec '02

Hi, I've two question about PyArray_As2D function: 1) Looking at the source code I realized that the prototype given in the manual is different from that of the source: PyArray_As2D(PyObject *op, char **ptr, int *m, int *n, int type) (from manual) PyArray_As2D(PyObject **op, char ***ptr, int *d1, int *d2, int typecode) (from source) As far as I can understand the source version is correct while the manual's one is not. Am I wrong? 2) Next in the source code I've found the following memory allocation: data = (char **)malloc(n*sizeof(char *)); without checking if malloc return NULL or not. As far as I know it's not safe, even if it's very unlikely that this malloc would fail. Anyway in that case the following: ... data[i] = ap->data + i*ap->strides[0]; ... would cause the function to abort. Again am I wrong? Thanks in advance, Andrea. --- Andrea Riciputi <mailto:andrea.riciputi@libero.it> "Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it" -- (Richard Feynman)

2 5

real/imag for non complex numbers [was numarray complex comparisons]
by Travis Oliphant 12 Dec '02

12 Dec '02

In investigating, why Numeric does not allow a.real for non-complex arrays which many have argued that it should, I think I uncovered an old bug in Numeric. In looking at the code, it appears that the intention was to have a.real just return a new array (pointing to the same data as a but having a new header) whenever a was not a complex array. Unfortunately, the code had a bug and did not actually return the newly created array. As a result, the default behavior of raising an "Attribute not found" exception occurred. But, before this happened, the array the reference count on the array occurred, thereby springing a memory leak. Try this out. a = ones((10,10)) print sys.getrefcount(a) a.real # will generate an exception print sys.getrefcount(a) a.real print sys.getrefcount(a) Notice that each time a.real is called the reference count for a goes up by one even though no object is returned. I have fixed the bug in Numeric CVS by returning the created object for a.real. The end result is that a.real works for all arrays (not just complex-valued ones). -Travis O. On Wed, 2002-12-11 at 16:24, Tim Hochberg wrote: > > Here's my latest thinking on this. I'll put this in the form of a proposal > so that it's easier to comment on. Please comment on part I and part II > separately. > > I. Attributes real and imag/imaginary[1] > > All numeric array types (i.e., excluding character and object arrays) would > have both a real and imag/imaginary attribute. For complex types ('F', 'D') > this would behave just as it does now. For non-complex types ('i', 'f', 'd', > etc.), the real attribute would return the object itself, while the > imaginary attribute would return a ReadOnlyZeroArray [2] of the correct > shape and typecode. I think that this would provide behaviour consistent > with the current real and imag attributes on complex arrays without > introducing and spooky corner cases (that statement is asking for trouble!). > Examples: > > >>> a = array([1,2,3]) > >>> a.real[0] = 99 > >>> a.real > array([99, 2, 3]) > >>> a.imag > array([0,0,0]) > >>> a.imag[0] = 99 > TypeError: object is read only. > > II. Functions real and imag > > Two functions real and imag (or imaginary or both) would be provided. The > would behave as if they were defined as shown below, even if item I. is not > adopted. > > def real(a): > return asarray(a).real > > def imag(a): > return asarray(a).imag > > > Comments? > > I'm currently +0 on I. and +1 on II. > > -tim > > > > [1] Numeric arrays haveboth imag and imaginary attributes, but they are > identical. I'm not sure what Numarray's plans are in this regard. > > [2] A ReadOnlyZeroArray(shape, typecode) would behave like an array of zeros > with the given shape and typecode for all non mutating operations. For > mutation operations (a[x] = b, a += c, etc.) it would raise an exception. > This object does not actually allocate any space, so creation is fast and > memory efficient. Implementing this might be the hardest part of the > proposal. > > > _______________________________________________ > SciPy-user mailing list > SciPy-user(a)scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user

1 0

Detecting Numeric.
by Andrea Riciputi 10 Dec '02

10 Dec '02

Hi there, I'm playing with Numeric and even if I've not so much experience with it I'm trying to write a C extention to Python that can use Numeric arrays. The basic idea consists in handling C (dynamically allocated) array as Numeric array (if Numeric is installed) or as simple Python lists if not. How can I detect at compile time if Numeric is installed or not?? I've thought something like: #ifdef NUMERIC_IS_HERE #include "Numeric/arrayobject.h" #endif But I've not found any hints in Numeric manual. Can anyone suggest a solution to me? Thanks in advance, Andrea. --- Andrea Riciputi <mailto:andrea.riciputi@libero.it> "Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it" -- (Richard Feynman)

3 2

Re: [SciPy-user] numarray equality testing
by Robert Kern 09 Dec '02

09 Dec '02

On Mon, Dec 09, 2002 at 09:06:43AM -0700, Tim Hochberg wrote: [snip] > This seems like a good plan. I'm not enthralled by the name though: > array_equal seems equally likely to describethe behaviour of the unfunc > equal as it does the behaviour above. Maybe array_identical or array_same or > equal_arrays or some such (although none of those are great). I'd put in my vote for array_equiv, equiv, or equivalent since I think "equivalence" best expresses the relationship tested here, not "equality." > -tim -- Robert Kern Ruddock House President kern(a)caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

1 0

installation warning on RH 7.3
by Dave Bazell 09 Dec '02

09 Dec '02

I just installed numpy on my RH 7.3 system under python 2.2.2. I get the following messages when I import Numeric. Could someone enlighten me as to what this means and what I should do about it? Thanks, Dave Bazell Python 2.2.2 (#1, Oct 21 2002, 12:22:55) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.2/site-packages/Numeric/Numeric.py", line 93, in ? from Precision import * File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 26, in ? _code_table = _fill_table(typecodes) File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 23, in _fill_table table[key] = _get_precisions(value) File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 18, in _get_precisions lst.append( (zeros( (1,), t ).itemsize()*8, t) ) ValueError: Invalid type for array >>> import Numeric >>>

1 0

numarray rank-0 array issues
by Perry Greenfield 09 Dec '02

09 Dec '02

A little while ago we tackled the issue of whether indexing numarray arrays should return Python scalars or rank-0 arrays. For reasons gone into at great length previously on this list we decided to always return Python scalars when no precision is lost by conversion to Python scalars (Float128 may be an exception to this rule, but we'll deal with that later). We consider this issue closed. But there are some loose ends. There was an opinion that reduction operations (e.g., add.reduce) should always return arrays. However, some desired that the rank-0 arrays returned when reducing a rank-1 array should be indexable and have a length. In particular: >>> x = arange(10) >>> v = add.reduce(x) >>> print v 55 >>> v array(55) >>> len(v) 1 >>> v[0] 55 The great majority objected to len(rank-0) being allowed as well as rank-0[0] working. We agree. We propose that at least one version of the reduction operations always return arrays, but that the array "end-point" always be a rank-1 len-1 array instead of a rank-0 array. This is because a rank-1 len-1 array 1) has a len() = 1 2) can be indexed. 3) because of broadcasting, behaves like a scalar in expressions with arrays (i.e., as was intended for rank-0 arrays) Thus, if one repeatedly reduces an N-dimensional array, one eventually gets a rank-1 len-1 array, and reducing a rank-1 len-1 array simply generates a new rank-1 len-1 array with the same value. >>> x = arange(10) >>> v = add.areduce(x) >>> v array([55]) >>> add.areduce(v) array([55]) Is there any reason why this behavior would not serve the purposes of those that wanted rank-0 arrays returned from reduction operations? Likewise, we could provide a function to wrap scalars as rank-1 len-1 arrays (much like array(5) produces a rank-0 array) for the purposes of more generic functions and routines so that checks for scalars do not need to be made. This function would convert scalars to arrays, but simply return the arrays themselves if passed as arguments. One possibility is that we eliminate rank-0 arrays and use rank-1 len-1 arrays in their place (e.g., array(5) returns a rank-1 len-1 array). The problem is that there may be some who already dependon rank-0 properties and this probably will break existing code. Any opinions? Finally, the default reduction operation (i.e., add.reduce) could be given the behavior described above. We are inclined to leave it as is, i.e., to return scalars when reducing 1-d arrays and provide a different operator method (areduce) to always return arrays. Any disagreements? Perry Greenfield

2 1

numarray equality testing
by Perry Greenfield 09 Dec '02

09 Dec '02

This is a Numeric/numarray compatibility question. Numeric currently allows the equals ufunc to compare arrays of unequal sizes and returns a scalar 0 in such cases. When arrays have consistent shapes, an array of ints is returned. We argue that this is inconsistent with normal ufunc behavior and that it should generate an exception as do all non-equality ufuncs. (numarray currently does not allow comparison of shape-inconsistent arrays including for equality). Instead we propose a function whose purpose is to determine if two arrays are shape consistent (i.e., can be broadcast against each other) and have all values equal to each other. >>> array_equal(arange(2), arange(4)) 0 >>> array_equal(array([1,2,3]), array([1,2,0])) 0 >>> array_equal( arange(2), None ) 0 >>> array_equal( arange(2), not_an_ndarray_instance) 0 >>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3])) 1 Comments? Perry Greenfield

3 3

numarray complex comparisons
by Perry Greenfield 09 Dec '02

09 Dec '02

The questions just keep coming... We need to decide whether or not complex comparisons work. They do not work for Python scalars. Consistency would argue for them not working for numarray arrays. However some argue: 1) not allowing them defeats more generic programming. We agreed until we found that IDL doesn't support them either, and we never noticed. We are skeptical of this claim and would like to see real-life examples. 2) it is useful to allow comparisons since that would result in repeatable, sorting of values (e.g., to find duplicate values) for ordering purposes. Cannot this just be handled by the sort routines themselves? Why must this result in comparison operators working? In the absence of good examples for 1) or good arguments for 2) we propose to make complex comparisons generate exceptions. Perry Greenfield

2 2

ANN: F2PY - Fortran to Python Interface Generator - 6th Release
by Pearu Peterson 08 Dec '02

08 Dec '02

F2PY - Fortran to Python Interface Generator, Version 2.32.225 --------------------------------------------------------------- I am pleased to announce the sixth public release of F2PY. The purpose of the F2PY project is to provide a connection between Python and Fortran programming languages. For more information, see http://cens.ioc.ee/projects/f2py2e/ Download source: http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz What's new? ------------ It has been almost a year from the previous release of F2PY. This release comes with a number of improvements, most important ones are listed as follows: - The issue with a Fortran and C multi-dimensional array storage ordering is finally resolved. F2PY generated wrappers automatically carry out all necessary transformations, trying hard to minimize any performance hits. As a result, the end users of F2PY generated wrappers need not to worry about this issue anymore, multi-dimensional arrays in Python and Fortran have now exactly the same signatures. - Improved wrapping C functions with F2PY. - F2PY Users Guide has been throughly revised to describe and illustrate all latest F2PY features such as wrapping Fortran 77 COMMON blocks, Fortran 90 module data, including Fortran 90 module ALLOCATABLE arrays, etc. The F2PY Users Guide is composed using the Python Docutils tool and is available here: http://cens.ioc.ee/projects/f2py2e/usersguide/ - F2PY has new site for unit testing. - F2PY uses scipy_distutils from SciPy (www.scipy.org) project for compiling Fortran sources and building extension modules. Currently, the following Fortran 77/90 compilers are described by scipy_distutils: Absoft Sun SGI Intel Itanium NAG Compaq Digital Gnu VAST - Finally, F2PY has been extensively used/tested for wrapping large Fortran/C libraries, such as, LAPACK, BLAS, ATLAS, FFTW, FFTPACK, etc. (see SciPy project for more information). This experience has been a very important source for ideas how to make binding Fortran/C codes to Python easier and more robust. Enjoy, Pearu Peterson --------------- <P><A HREF="http://cens.ioc.ee/projects/f2py2e/">F2PY 2.32.225</A> - The Fortran to Python Interface Generator (08-Dec-02)

1 0

Numeric Python EM Project supposed to be in Dec IEEE A & P Magazine
by Rob 07 Dec '02

07 Dec '02

It should be in the educational corner. I've beefed up the intro to the site. Will be interesting to see if I get many new hits. Rob. -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com

1 1

Accessing array members
by Joachim Saul 03 Dec '02

03 Dec '02

Hi there, given the following (simplified) scenario: typedef struct { PyObject_HEAD float bar[10]; } FooObject; I want to be able to set and retrieve the elements of bar from Python using e.g. >>> foo = Foo() >>> foo.bar[4] = 1.23 >>> x = foo.bar[4] I have chosen an approach using 'PyArray_FromDimsAndData'. In fact I programmed it after studying 'arrayobject.c', namely the part in 'array_getattr' where the 'flat' attribute is accessed. foo_getattr(FooObject *self, char *name) { if (!strcmp(name, "bar")) { int n=10; PyObject *bar = PyArray_FromDimsAndData(1, &n, PyArray_FLOAT, (char*)self->bar); if (bar == NULL) return NULL; return bar; } return Py_FindMethod(foo_methods, (PyObject*)self, name); } And it works! :-) BUT how about refcounts here? 'PyArray_FromDimsAndData' will return an array which only contains a reference to foo's original bar array; that's why I can both set and access the latter the way described. And no memory leak is created. But what if I create a reference to foo.bar, and later delete foo, i.e. >>> b = foo.bar >>> del foo Now the data pointer in b refers to freed data! In the mentioned 'array_getattr' this apeears to be solved by increasing the refcount; in the above example this would mean 'Py_INCREF(self)' before returning 'bar'. Then if deleting 'foo', its memory is not freed because the refcount is not zero. But AFAICS in this case (as well as in the Numeric code) the INCREF prevents the object from EVER being freed. Who would DECREF the object? Or am I misunderstanding something here? In my actual code I can perfectly live with the above solution because I only need to access foo's data using 'foo.bar[i]' and probably never need to create a reference to 'bar' which might survive the actual 'foo' object. However, I want to program it the 'clean' way; any hints on how to do it properly would therefore be highly welcome. Cheers, Joachim

4 5

coercion of arrays
by verveer＠embl-heidelberg.de 02 Dec '02

02 Dec '02

Hi, I was looking at the coercion of arrays in the new numarray. The following is not intuitive to me: >>> a = array(1, Int8) >>> b = array(1, UInt16) >>> c = a + b >>> c.type() UInt16 Should the result not be a signed integer type? Also the following result is strange to me: >>> a = array(1, Float64) >>> b = array(1, Complex32) >>> c = a + b >>> c.type() Complex32 Complex64 would seem to be the more apropiate type here for the result. Could somebody comment if these are bugs or not? Cheers, Peter -- Dr. Peter J. Verveer Cell Biology and Cell Biophysics Programme European Molecular Biology Laboratory Meyerhofstrasse 1 D-69117 Heidelberg Germany Tel. : +49 6221 387245 Fax : +49 6221 387242 Email: Peter.Verveer(a)embl-heidelberg.de

2 1