Mailman 3 December 2005 - NumPy-Discussion

numarray: how to make sinc(x) function - "divide by zero" !
by Sebastian Haase 05 Dec '05

05 Dec '05

Hi, The best I could come up with was: def sinc(r): na.Error.pushMode(all="ignore") a = na.where(r, na.divide(na.sin(r),r), 1) na.Error.popMode() return a but I still seem to get a warning... >>> F.sinc(0) Warning: Encountered invalid numeric result(s) in divide 1.0 Thanks, Sebastian Haase

1 0

scipy cygwin compilation error
by Jordan Dawe 04 Dec '05

04 Dec '05

I just tried to install scipy under cygwin using both 0.61 and the current svn. I get this: gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o -L/usr/lib/python2.4/config -lpython2.4 -o build/lib.cygwin-1.5.18-i686-2.4/scipy/base/umath.dll build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UBYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2215: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `USHORT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2233: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UINT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2251: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `ULONG_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2269: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `BYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2305: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o:/usr/local/core/build/src/scipy/base/src/umathmodule.c:2325: more undefined references to `_feraiseexcept' follow build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_checkfperr': /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_clearfperr': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_GenericFunction': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `construct_reduce': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' collect2: ld returned 1 exit status build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UBYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2215: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `USHORT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2233: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UINT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2251: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `ULONG_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2269: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `BYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2305: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o:/usr/local/core/build/src/scipy/base/src/umathmodule.c:2325: more undefined references to `_feraiseexcept' follow build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_checkfperr': /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_clearfperr': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_GenericFunction': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `construct_reduce': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' collect2: ld returned 1 exit status error: Command "gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o -L/usr/lib/python2.4/config -lpython2.4 -o build/lib.cygwin-1.5.18-i686-2.4/scipy/base/umath.dll" failed with exit status 1 Any suggestions? Jordan

2 1

Numeric3.0 - Currently available under scipy/base as version 0.4.1 (Windows)
by Colin J. Williams 04 Dec '05

04 Dec '05

I have a package based on subclassing numarray, which is working satisfactorily, and am looking at the possibility of transferring the package to work under the revised Numeric. My feeling is that the transfer is probably feasible but that it would be premature to work on it at this time. One of the problems is the cluttered namespace, through the use of "from X import *". This is a style which is deprecated, see page 401 of Alex Martelli's /Python in a Nutshell/. Another problem, at this stage, is that many doc strings are missing and that some which exist are a little cryptic. I would like to take another look when the next win32 binaries are available. Some further thoughts on the present state of Numeric3.0 are available here <http://www3.sympatico.ca/cjw/scipy1/>. Colin W,

2 3

py2exe compliance
by Antony Kummel 03 Dec '05

03 Dec '05

Hi! I have used a trick to make py2exe recognize all of numarray's modules, which I suggest be incorporated into the numarray CVS. It can be a real pain to solve this problem the first time you're py2exe-ing a script using numarray and find out that it simply doesn't work. I just added this to numarray's __init__.py: # this is needed for py2exe to be able to include numarray def _give_py2exe_hints(): # pyd's import numarray.libnumarray import numarray.libnumeric import numarray.memory import numarray._bytes import numarray._chararray import numarray._conv import numarray._converter import numarray._ndarray import numarray._numarray import numarray._objectarray import numarray._operator import numarray._sort import numarray._ufunc import numarray._ufuncBool import numarray._ufuncComplex32 import numarray._ufuncComplex64 import numarray._ufuncFloat32 import numarray._ufuncFloat64 import numarray._ufuncInt16 import numarray._ufuncInt32 import numarray._ufuncInt64 import numarray._ufuncInt8 import numarray._ufuncUInt16 import numarray._ufuncUInt32 import numarray._ufuncUInt8 # py's import numarray.arrayprint import numarray.array_persist import numarray.dotblas import numarray.generic import numarray.ieeespecial import numarray.memmap import numarray.memorytest import numarray.numarrayall import numarray.numarraycore import numarray.numarrayext import numarray.numeric import numarray.numerictypes import numarray.numinclude import numarray.numtest import numarray.objects import numarray.readonly import numarray.records import numarray.safethread import numarray.strings import numarray.teacup import numarray.testall import numarray.testdata import numarray.typeconv import numarray.ufunc import numarray._ufuncall # subpackages import numarray.convolve import numarray.convolve.lineshape import numarray.fft import numarray.image import numarray.linear_algebra import numarray.ma import numarray.matrix import numarray.mlab import numarray.nd_image import numarray.random_array --------------------------------- Yahoo! Personals Single? There's someone we'd like you to meet. Lots of someones, actually. Yahoo! Personals

1 0

Records in scipy core
by Travis Oliphant 02 Dec '05

02 Dec '05

Christopher Hanley wrote: >Hi Travis, > >About a year ago (summer 2004) on the numpy distribution list there was >a lot of discussion of the records interface. I will dig through my >notes and put together a summary. > > Thanks for the pointers. I had forgotten about that discussion. I went back and re-read the thread. Here's a good link for others to re-read (the end of) this thread: http://news.gmane.org/find-root.php?message_id=%3cBD22BAC0.E9EB%25perry%40s… I think some very good points were made. These points should be addressed from the context of scipy arrays which now support records in a very basic way. Because of this, we can support nested records of records --- but how is this to be presented to the user is still an open question (i.e. how do you build one...) I've finally been converted to believe that the notion of records is very important because it speaks of how to do the basic (typeless, mathless) array object that will go into Python correctly If we can get the general records type done right, then all the other types are examples of it. Thus, I would like to revive discussion of the record object for inclusion in scipy core. I pretty much agree with the semantics that Perry described in his final email (is this all implemented in numarray, yet?), except I would agree with Francesc Alted that a titles or labels concept should be allowed. I'm more enthusiastic about code than discussion, so I'm hoping for a short-lived discussion followed by actual code. I'm ready to do the implementation this week (I've already borrowed lots of great code from numarray which makes it easier), but feel free to chime in even if you read this later. In my mind, the discussion about the records array is primarily a discussion about the records data-type. The way I'm thinking, the scipy ndarray is a homogeneous collection of the same "thing." The big change in scipy core is that Numeric used to allow only certain data types, but now the ndarray can contain an arbitrary "void" data type. You can also add data-types to scipy core. These data-types are "almost" full members of the scipy data-type community. The "almost" is because the N*N casting matrix is not updated (this would require a re-design of how casting is considered). At some point, I'd like to fix this wart and make it so that data-types can be added at will -- I think if we get the record type right, I'll be able to figure out how to do this. We need to add a "record" data-type to scipy. Then, any array can be of "record" type, and there will be an additional "array scalar" that is what is returned when selecting a single element from the array. So, a record array would simply be an array of "records" plus some extra stuff for dealing with the mapping from field names to actual segments of the array element (we may decide that this mapping is general enough that all scipy arrays should have the capability of assigning names to sub-bytes of its main data-type and means of accessing those sub-bytes in which case the subclass is unnecessary). Let me explain further: Right now, the machinery is in place in scipy_core to get and set in any ndarray (regardless of its data-type) an arbitrary "field". A "field" in this context is defined as a sub-section of the basic element making up the array. Generically the sub-section is defined by an offset and a data-type or a tuple of a data type and a shape (to allow sub-arrays in a record). What I understand the user to want is the binding of a name to this generic sub-section descriptor. 1) Should we allow that for every scipy ndarray: complex data types have an obvious binding, would anybody want to name the first two bytes of their int32 array? I suggest holding off on this one until a records array is working.... 2) Supposing we don't go with number 1, we need to design a record data type that has this name-binding capability. The recarray class in scipy core SVN essentially just does this. Question: How important is backwards compatibility with old numarray specification. In particular, I would go with the .fields access described by Perry, and eliminate the .field() approach? Thanks for reading and any comments you can make. -Travis

6 10

new scipyCore features in numarray - indexing...
by Sebastian Haase 01 Dec '05

01 Dec '05

(this was posted to SciPy on 2005-11-16 16:37 - maybe I got lost ;-) Todd, I'm just thinking of a nice feature that I think is now part of new scipyCore: Mixing index ranges in one axis with index lists in another. Example: I have index 4,7,9 that I'm intrested in: use a[ [4,7,9] ] If I want all section I obviously just say a[ : ] But what do I do in the 2d case where I want 4,7,9 in one axis and all in the other ? I understood that the new scipyCore allows a[:, [4,7,9]] whereas numarray gives an error !? Thanks, Sebastian Haase On Friday 04 November 2005 14:57, Todd Miller wrote: > Sebastian Haase wrote: > >Also I always need to thank Todd et al. for numarray which we are using > > for about 4 years now. > > I'm glad you found numarray useful. > > >I was following - I thought - all the postings here, but I don't remember > > when and what the reason was when a.type() changed to a.dtype (also > > there is a "dtypecode" somewhere !?). Any reference or explanation would > > be great. I have to say that the (old) parenthesis where always quite > > "annoying" ! ;-) > > > >Question: does the way allow assignments like "a.dtype = Float32". > >What does it do ? If not, is it raising an error (I had 2 different people > >yesterday who tried to assign to a.type here in our lab ...) > > > >Also is this now completely supported/tested and suggested for numarray ? > > (For the time numarray is still separate) > > I'm adding support for some of newcore's new interface features out of > desire to make it easier to migrate. Our intent is to make it possible > to write newcore code and run it on numarray now as newcore matures. > Not every newcore feature is going to be supported, but we'll make an > effort to support those which are easy to implement. Let me know is > there's some newcore idiom you want to use that numarray doesn't have yet. > > Regards, > Todd _______________________________________________ SciPy-user mailing list SciPy-user(a)scipy.net http://www.scipy.net/mailman/listinfo/scipy-user

3 2