Mailman 3 January 2003 - NumPy-Discussion

Grepping the source
by Edward C. Jones 03 Jan '03

03 Jan '03

Here is a short program I find useful. #! /usr/bin/env python import os, sys, tempfile """Greps the numarray source code""" command = \ """grep -n "%s" \ /usr/local/src/numarray-0.4/Include/numarray/arrayobject.h \ ... /usr/local/src/numarray-0.4/Lib/_ufunc.py \ ... /usr/local/src/numarray-0.4/Src/libnumarraymodule.c \ > %s """ if len(sys.argv) != 2: raise Exception, 'program requires exactly one argument' temp = tempfile.mktemp() try: os.system(command % (sys.argv[1], temp)) f = file(temp, 'r') lines = f.read().splitlines() f.close() finally: if os.path.exists(temp): os.remove(temp) common = len('/usr/local/src/numarray-0.4/') d = {} names = [] for line in lines: line = line[common:] colonloc = line.index(':') name = line[:colonloc] text = line[colonloc+1:] if not d.has_key(name): d[name] = [] names.append(name) d[name].append(text) for name in names: if len(d[name]) == 0: continue print '%s:' % name for text in d[name]: print ' %s' % text print

2 1

numarray types and PIL modes, revisited
by Edward C. Jones 03 Jan '03

03 Jan '03

Perry Greenfield wrote: > Edward Jones writes: > > 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. > > I'm not sure I understand. Can you give me an example of problem > code or usage? It sounds like you are trying to test the types of > PIL and numarray objects in a generic sense. But I'd understand > better if you could show an example. That's what I was thinking (incorrectly). But I don't need to directly compare PIL modes with numarray types. My code never tries to deduce whether an array is a numarray or a PIL image from just the natype_or_mode. A module name (MODULE.NUMARRY, MODULE.PIL) must also be given. I do things this way because I might want to include other array/image systems. In an earlier version, I had a MODULE.IPL for the Intel Image Processing Library. The code also implements a policy of forbidding string types. So now all I can say is: 1. UInt8 == 'X' should not raise an exception. It should return False. 3. There needs to be a function that returns True iff arg is a numarry type (UInt8, "UInt8", "b", ...). def IsType(rep): from numerictypes import typeDict return isinstance(rep, NumericType) or typeDict.has_key(rep) Here is a typical piece of code. "module" can be MODULE.PIL or MODULE.NUMARRAY. ---- """General image casting function. Changes the C type of the pixels. Information can be lost. The "Convert" functions call C casting functions that clip the values, For example, if the input is a UInt16 and the output is a Int16, any input value greater than 32767 becomes 32767. """ def ArrayToArrayCast(arrin, module, natype_or_mode): """Converts one array into another. Results are clipped.""" pars = Parameters(arrin) if pars.module == module == MODULE.PIL and \ pars.mode == natype_or_mode: return arrin if pars.module == module == MODULE.NUMARRAY and \ NA_SameType(pars.natype, natype_or_mode): return arrin if pars.module == MODULE.NUMARRAY and module == MODULE.NUMARRAY: return NA_To_NA_Convert(arrin, natype_or_mode) if pars.module == MODULE.PIL and module == MODULE.PIL: return PIL_To_PIL_Convert(arrin, natype_or_mode) if pars.module == MODULE.NUMARRAY and module == MODULE.PIL: return NA_To_PIL_Convert(arrin, natype_or_mode) if pars.module == MODULE.PIL and module == MODULE.NUMARRAY: return PIL_To_NA_Convert(arrin, natype_or_mode) ----

2 1

End of Holidays small comments
by Edward C. Jones 03 Jan '03

03 Jan '03

node35.html: >>> print x.type(), x.real.type() D d should be >>> print x.type(), x.real.type() numarray type: Complex64 numarray type: Float64 ------------------------------------------------ Why use both NUM_C_ARRAY and C_ARRAY? ------------------------------------------------ in _ndarraymodule.c: {"_byteoffset", (getter)_ndarray_byteoffset_get, (setter)_ndarray_byteoffset_set, "shortest seperation between elements in bytes"}, {"_bytestride", (getter)_ndarray_bytestride_get, (setter)_ndarray_bytestride_set, "shortest seperation between elements in bytes"}, One of the comments is wrong. Also "separation". ------------------------------------------------ libnumarraymodule.c: /* Create an empty array. */ static PyArrayObject * NA_Empty(int ndim, int *shape, NumarrayType type) node42.html: static PyObject* NA_Empty( NumarrayType type, int ndim, ...) Serious documentation error. ------------------------------------------------ I think NA_New should be NA_New(int ndim, int* shape, NumarrayType type, void* buffer) The current NA_New is useful only when ndim is known at code-writing time. ------------------------------------------------ node39.html: Note: the type parameter for a macro is one of the Numarray Numeric Data Types, not a NumarrayType enumeration value. There should be an example of one of the GET/SET macros. How about unsigned char n; int i; ... n = NA_GET1(arr, UInt8, i); ------------------------------------------------ It seems that the parameters "aligned" and "writeable" are ignored in the source code for NA_NewAll and class NumArray. ------------------------------------------------ I would like to see an "int* strides" parameter added to NA_NewAll, so a non-contiguous "buffer" can be used. ------------------------------------------------ I suggest NA_Copy(PyObject* arr) which is something like static PyObject* NA_Copy(PyObject* arr) { PyArrayObject* arr1 = arr; return NA_NewAll(arr1->nd, (long*) arr1->dimensions, arr1->descr->type_num, arr1->data, arr1->byteoffset, arr1->bytestride, arr1->byteorder, 1, 1); }

2 1

Re: [Numpy-discussion] Slicing API?
by Todd Miller 02 Jan '03

02 Jan '03

Edward C. Jones wrote: > Todd Miller wrote: > >> Edward C. Jones wrote: >> >>> Both in Numeric and now in numarray I have found a need for API >>> functions for slicing. Has anyone thought about this? >>> >> Speaking for myself and the numarray C-API, the answer is no. What >> API do you want? Can you suggest function prototypes? > > > An API version of arrout[slices] = arrin[slices]: > > static int > NA_CopySlice(PyArrayObject* arrin, PyArrayObject* arrout, > int* startin, int* stepin, int* stopin, int* startout, int* stepout); > > I would suggest something more like the following then: typedef struct { int start, stop, step; } NumSlice; static int NA_CopySlice(PyArrayObject* arrin, int indim, NumSlice *slicein, PyArrayObject* arrout, int outdim, NumSlice *sliceout); The differences are: 1. A slice dimension count is added for both input and output arrays. This enables use of partial indices. 2. Slice values are expressed using the NumSlice typedef/struct rather than 3 independent int arrays. 3. The parameter order is shuffled so that input array parameters are kept together, and output array parameters are kept together. But, I still have these comments: 1. It looks like it will be cumbersome to use. 2. We should probably implement it as a callback to Python to avoid introducing another set of assignment semantics. Thus, the implementation would really just be building up and executing the calls for: outarr.__setitem__(outslices, inarr.__getitem__(inslices)). 3. The slicing implementation for numarray objects should be optimized to C this quarter, if not this month. So in terms of efficiency, not to mention comment 2, this won't buy much. 4. Since Numeric doesn't have this already, we're probably missing something obvious. Comments? Still interested? Todd

1 0

Slicing API?
by Edward C. Jones 01 Jan '03

01 Jan '03

Both in Numeric and now in numarray I have found a need for API functions for slicing. Has anyone thought about this?

2 1