NumPy-Discussion July 2005

numpy-discussion@python.org

38 participants
39 discussions

Trouble installing numarray on Solaris
by Russell E. Owen 07 Jul '05

07 Jul '05

A user of my application reports that installing numarray 1.3.2 on Solaris using Python 2.3.1 has run into trouble: prompt> python Python 2.3.1 (#1, Sep 30 2003, 20:29:58) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import numarray Fatal Python error: Call to API function without first calling import_libnumarray() in Src/_convmodule.c Abort (core dumped) I've seen a one or two recent reports of this error when running extension modules, but I've never heard of it happening when simply trying to import numarray. Any suggestions? -- Russell P.S. I do realize that python 2.3.1 is old and should be updated, and I have already suggested it. But it seems a bit unlikely to fix this particular problem.

5 10

_fastCopyAndTranpose
by Colin J. Williams 06 Jul '05

06 Jul '05

numarray.LinearAlgebra2.py has # _fastCopyAndTranpose is an optimized version of _castCopyAndTranspose. # It assumes the input is 2D (as all the calls in here are). However the following code is commented out. Is this considered a satisactory replacement for _castCopyAndTranspose? Colin W

1 0

patch numarray.fromfuntion with optional type argument
by Sebastian Haase 06 Jul '05

06 Jul '05

Hi, Please tell if this patch is a good idea. (Use: For large image data we always use Float32 and I thought it would be extra overhead if I first create everything in Float64 and then have to convert to Float32 afterwards, myself) haase@gorilla:~: diff -p ~/myCVS/numarray/Lib/generic.py ~/myCVS/numarray/Lib/generic.py.~1.74.~ *** /home/haase/myCVS/numarray/Lib/generic.py Thu Jun 16 11:04:10 2005 --- /home/haase/myCVS/numarray/Lib/generic.py.~1.74.~ Fri Apr 22 13:35:26 2005 *************** def indices(shape, type=None): *** 1167,1179 **** a = a.astype(type) return a ! def fromfunction(function, dimensions, type=None): # from Numeric """fromfunction() returns an array constructed by calling function on a tuple of number grids. The function should accept as many arguments as there are dimensions which is a list of numbers indicating the length of the desired output for each axis. """ ! return apply(function, tuple(indices(dimensions,type))) def _broadcast_or_resize(a, b): try: --- 1167,1179 ---- a = a.astype(type) return a ! def fromfunction(function, dimensions): # from Numeric """fromfunction() returns an array constructed by calling function on a tuple of number grids. The function should accept as many arguments as there are dimensions which is a list of numbers indicating the length of the desired output for each axis. """ ! return apply(function, tuple(indices(dimensions))) def _broadcast_or_resize(a, b): try: Thanks, - Sebastian Haase

2 2

nestedrecords.py module
by Francesc Altet 05 Jul '05

05 Jul '05

Hi, In our company we had the need for an extension of RecArray objects so that they would be able to keep nested fields (that is, fields that can have other subfields). The outcome was a module that is intended to do that. We have tested it quite extensively and we think it is quite free of bugs. The conversation with Les has reminded me about it, and thought that it would interesting for the numarray community. I'm attaching a tarball with the next files: - nestedrecords.py -- Where the NestedRecArray lives - nriterators.py -- A suite of iterator utilities for nestedrecords.py - nestedrecords.txt -- Documentation in restructured text The nestedrecords module is mainly a job of Vicent Mas (vmas(a)carabos.com) and is offered with a BSD license. Of course, we would be glad if this stuff ends in numarray sometime :-) -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"

1 1

numarray: Bug printing an object array after unpickling it
by Edward C. Jones 05 Jul '05

05 Jul '05

#! /usr/bin/env python # I have a PC with up-to-date Debian unstable Linux. I have installed # Python 2.4.1 and numarray 1.3.2 from source (not from a Debian # package). The following program fails for both pickle and cPickle: import pickle import numarray, numarray.objects obj = numarray.objects.array([0,0,0,0], (2,2)) print obj s = pickle.dumps(obj, pickle.HIGHEST_PROTOCOL) open('mess2', 'w').write(s) s = open('mess2', 'r').read() obj = pickle.loads(s) print obj # Fails here

1 0

subclassing RecordArrays
by Les Schaffer 05 Jul '05

05 Jul '05

Is there a simple way to subclass RecordArrays? it seems not. suppose i want to have a class RecArrayD(RecArray) that returns a list of its fields, much like a Dict does: recarrayD.keys() the problem is that the fromXXX functions in records.py know only about the one RecArray. and RecArrayD._copyFrom() seems to be of little help, since the new style RecArray has to be framed out first, so to speak. which leaves me to write a new fromRecArray() function that uses the new class. all to get a list of the fields. is this by design, or am i missing something? yes, i can get the keys like so: recarray._names, but i assume that the '_' in front of '_names' is there for a reason, like maybe don't count on it??? or would the designers be willing to add a keys()-like method in for the next release? les schaffer

2 3

You have successfully added a new email address
by eBay 02 Jul '05

02 Jul '05

1 0

a Numeric.where re-coded for weave.inline: very fast...
by Ray Schumacher 01 Jul '05

01 Jul '05

I tried weave for executing a C routine over a Numeric array. The Numeric data array is c_int16 with 14 significant bits (bit 13 is the sign) and I wanted it as "normal" Int16. So: t1=clock() m = where(greater(dataArray[:1000], 8191), dataArray[:1000]-16383, dataArray[:1000]) t2 = clock() print 'where', round((t2-t1)*1000000, 1), 'us' Usually gives: where 634.3 us PyInline has about the same calling overhead as ctypes (I had tried a DLL and ctypes: http://sourceforge.net/mailarchive/forum.php?thread_id=7630224&forum_id=246… ), apparently, about 240us for a simple C statement. It also requires some extra hoops to digest the pointer to short I need ( void b2int(short *f, int N) ), so I didn't fully try it. weave.inline testing was very good, with different issues. I found I had to patch msvccompiler.py for MS C 7.1 .NET ( http://www.vrplumber.com/programming/mstoolkit/ ). After the free but massive download/install... import weave inline = weave.inline # for speed N = 1000 code="int i; for(i = 0; i < N; i++){if (dataArray[i]>8191){dataArray[i]-=16383;}}" inline(code, ['dataArray', 'N']) # just pass Python object's names This created sc_019a1cf36209cb2dfc688820080541ef0.pyd in C:\Documents and Settings\rays\Local Settings\Temp\rays\python24_compiled\ Using the above code is slow; ~32000 us, as the compiler checks or runs each time. However, after much fiddling and dir()s, I copied the long-name.pyd to C:\Python24\DLLs and just did import sc_019a1cf36209cb2dfc688820080541ef0 b2iw = sc_019a1cf36209cb2dfc688820080541ef0.compiled_func # note the exposed function! N = 1 t1=clock() b2iw({'dataArray':dataArray}, {'N':N}) # note the dicts! t2 = clock() print 'weave', round((t2-t1)*1000000, 1), 'us' 25us! (~300us for N=10000) I think that's as close to C speed as I can expect, although I'm looking at the compiler options in msvccompiler.py for P4 optimization... I still get "Missing compiler_cxx fix for MSVCCompiler" on the initial compile, but apparently to no harm. As a final note, I also found that psyco _slows down_ both ctypes and weave calls. I did psyco.full() at the app's start. Without pysco: b2i 210.8 us weave 53.7 us with: b2i 250.0 us weave 234.7 us Comment/criticism ? Ray

1 0

numarray - silent truncation of complex values
by Colin J. Williams 01 Jul '05

01 Jul '05

Todd, This is to suggest that further consideration be given to this bug. As a minimum, I would suggest that the truncation be clearly documented but it would be better handled in the Python manner. Please see: http://sourceforge.net/tracker/index.php?func=detail&aid=1216688&group_id=1… Regards, Colin W.

6 9

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion July 2005