Mailman 3 April 2004 - NumPy-Discussion

Numpy-discussion Wanted to try Cialis but thought it was way too expensive for you? numpy-discussion@lists.sourceforge.net Numpy-discussion
by Noori April 3, 2004

April 3, 2004

You can do that now. Cialiis at only $2.00 p/d. Your best deals are here http://smart-pharmacy.com/15/ You have enjoyed Viaggra and wish for a longer effect? Ciaaliss can make it happen. UNBELIEVABLE. CIIALISS AT ONLY $2.00 P/D Say NO. to planning seex for hours in advance and your disappointment after "a missed dose". You don't have to be content with a four hour action of an regular pill. Get CIALIS now to ensure the whole day of joyful sexual intimacy for you and your partner. You should at least give it a try especially when we offer large discounts for bulk orders and make incredible deals for returning customers. NOW http://smart-pharmacy.com/15/

1 0

blitz++ and numarray
by Faheem Mitha April 2, 2004

April 2, 2004

Hi, I'm considering the use of the Blitz++ C++ library (http://www.oonumerics.org/blitz/) along with numarray/Numeric. I want to pass an array down to C++ and then manipulate it using Blitz++. My current thinking is to use the Numeric interface to pass down the array, and then copy it to a blitz++ array object. This seems straightforward except I am a little concerned about those reference counting issues, which I don't properly understand (I'm a Python beginner). I do get the impression that it is mainly an issue if I am working with Python objects in C/C++ code, though, and I am mostly going to try to avoid doing so by declaring C++ objects within the C++ code and working with those as much as possible. Other possibilities include somehow using the Boost.Python package, though I am not sure how. One advantage of this is that it apparently takes care of the reference counting issue. However, I don't want to learn yet another API. Also, weave.blitz() from SciPy looks relevant/useful, but this automatically generates its own C++ code, and I'd prefer to write my own. Can anyone suggested a good basic tutorial which discusses the issues of reference counting in a C/C++ API context? I have tried reading the official documentation and will continue to do so, but something gentler would be useful. Comments, suggestions gratefully appreciated. Please cc me on any reply to faheem(a)email.unc.edu. Thanks in advance. Faheem.

5 10

Re: FW: [Numpy-discussion] Questions about records
by Jin-chung Hsu April 2, 2004

April 2, 2004

> >--> arr1 = num.arange(4, shape=(1,2,2), type=num.Float64) > >--> arr2 = num.arange(4, shape=(1,2,2), type=num.Float64)+10 > >--> a = rec.array([arr1, arr2], names="a,b") > > But is there any advantage to that compared to just using named > arrays of the desired shape: > a = num.arange(4, shape=(2,2), type=num.Float64) > b = num.arange(4, shape=(2,2), type=num.Float64)+10 > Not really, in this particular example. > >I'd be interested in your application as to why a 2x2 table is necessary. > > Here are two different uses I've come up with (both related to image > processing). [snip] You need it because you need to pass it to the C-structure, I think. In any case, you have found a way to get around the problem by using setshape. I'll take a look of the module to get an idea of how much effort is needed to make the 2-D (and higher) record arrays to work more smoothly. JC Hsu

1 0

Re: FW: [Numpy-discussion] Questions about records
by Jin-chung Hsu April 2, 2004

April 2, 2004

> I've been trying to generate a 2-dimensional numarray.records array > and am rather puzzled about some failures: > > I tried a pair of 2x2 arrays for the buffer (one per field). I > thought the record would get its shape from those, but instead of a > 2x2 record I get a 2-length record, each of whose elements is a pair > of 2-length arrays. > > >>> arr1 = num.arange(4, shape=(2,2), type=num.Float64) > >>> arr2 = num.arange(4, shape=(2,2), type=num.Float64) + 10 > >>> a = rec.array([arr1, arr2], names="a,b") > >>> a > array( > [(array([ 0., 1.]), array([ 10., 11.])), > (array([ 2., 3.]), array([ 12., 13.]))], > formats=['(2,)Float64', '(2,)Float64'], > shape=2, > names=['a', 'b']) > > So I tried passing in 4-length arrays while specifying the shape > explicitly, but it failed. Is this a bug?: > > >>> arr1 = num.arange(4, type=num.Float64) > >>> arr2 = num.arange(4, type=num.Float64) + 10 > >>> a = rec.array([arr1, arr2], shape=(2,2), names="a, b") > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/local/lib/python2.3/site-packages/numarray/records.py", > line 384, in array > byteorder=byteorder, aligned=aligned) > File "/usr/local/lib/python2.3/site-packages/numarray/records.py", > line 177, in fromarrays > raise ValueError, "array has different lengths" > ValueError: array has different lengths > > Generating a 4-length record and reshaping it does seem to work, > though there seems to be a bug in __str__ which I'll report: > > >>> arr1 = num.arange(4, type=num.Float64) > >>> arr2 = num.arange(4, type=num.Float64) + 10 > >>> a = rec.array([arr1, arr2], names="a, b") > >>> a.setshape((2,2)) > >>> a > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/local/lib/python2.3/site-packages/numarray/records.py", > line 718, in __repr__ > outlist.append(Record.__str__(i)) > TypeError: unbound method __str__() must be called with Record > instance as first argument (got RecArray instance instead) > >>> a[1,1] > <numarray.records.Record instance at 0x15d2ad0> > >>> str(a[1,1]) > '(1.0, 11.0)' > > I see the str problem again if I don't specify any buffer: > > >>> import numarray as num > >>> import numarray.records as rec > >>> a = rec.array(formats="Float64,Float64", names="a,b", shape=(2,2)) > >>> a > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/local/lib/python2.3/site-packages/numarray/records.py", > line 718, in __repr__ > outlist.append(Record.__str__(i)) > TypeError: unbound method __str__() must be called with Record > instance as first argument (got RecArray instance instead) > > So...comments? Should I report the shape issues as a bug? > > -- Russell First of all, the records module was developed mainly having the 1-D table in mind. Even though it can have higher than one dimension, it is not thoroughly tested, as you have found out. However, I'd argue that in many cases that the need to use a 2-D (or high) table can be substituted by having an array in each cell(element). In your example, instead of creating a 2x2 table with each cell just having one number, you may be able to use a table with just one row and each cell is a 2x2 array. You can create such a record like this: --> arr1 = num.arange(4, shape=(1,2,2), type=num.Float64) --> arr2 = num.arange(4, shape=(1,2,2), type=num.Float64)+10 --> a = rec.array([arr1, arr2], names="a,b") I'd be interested in your application as to why a 2x2 table is necessary. The __str__ method in RecArray is rather primitive but usually works for 1-D tables. Eventually, we'll need a C-implementation of this method for both speed and flexibility. When you use a list for the buffer in the array function, it is using a relatively intuitive (simplistic?) approach. It tries to figure out the (one dimensional) length of each item in the list and use that as the record shape. JC Hsu

2 1

Questions about records
by Russell E Owen April 2, 2004

April 2, 2004

I've been trying to generate a 2-dimensional numarray.records array and am rather puzzled about some failures: I tried a pair of 2x2 arrays for the buffer (one per field). I thought the record would get its shape from those, but instead of a 2x2 record I get a 2-length record, each of whose elements is a pair of 2-length arrays. >>> arr1 = num.arange(4, shape=(2,2), type=num.Float64) >>> arr2 = num.arange(4, shape=(2,2), type=num.Float64) + 10 >>> a = rec.array([arr1, arr2], names="a,b") >>> a array( [(array([ 0., 1.]), array([ 10., 11.])), (array([ 2., 3.]), array([ 12., 13.]))], formats=['(2,)Float64', '(2,)Float64'], shape=2, names=['a', 'b']) So I tried passing in 4-length arrays while specifying the shape explicitly, but it failed. Is this a bug?: >>> arr1 = num.arange(4, type=num.Float64) >>> arr2 = num.arange(4, type=num.Float64) + 10 >>> a = rec.array([arr1, arr2], shape=(2,2), names="a, b") Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/site-packages/numarray/records.py", line 384, in array byteorder=byteorder, aligned=aligned) File "/usr/local/lib/python2.3/site-packages/numarray/records.py", line 177, in fromarrays raise ValueError, "array has different lengths" ValueError: array has different lengths Generating a 4-length record and reshaping it does seem to work, though there seems to be a bug in __str__ which I'll report: >>> arr1 = num.arange(4, type=num.Float64) >>> arr2 = num.arange(4, type=num.Float64) + 10 >>> a = rec.array([arr1, arr2], names="a, b") >>> a.setshape((2,2)) >>> a Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/site-packages/numarray/records.py", line 718, in __repr__ outlist.append(Record.__str__(i)) TypeError: unbound method __str__() must be called with Record instance as first argument (got RecArray instance instead) >>> a[1,1] <numarray.records.Record instance at 0x15d2ad0> >>> str(a[1,1]) '(1.0, 11.0)' I see the str problem again if I don't specify any buffer: >>> import numarray as num >>> import numarray.records as rec >>> a = rec.array(formats="Float64,Float64", names="a,b", shape=(2,2)) >>> a Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/site-packages/numarray/records.py", line 718, in __repr__ outlist.append(Record.__str__(i)) TypeError: unbound method __str__() must be called with Record instance as first argument (got RecArray instance instead) So...comments? Should I report the shape issues as a bug? -- Russell

1 0

RE: [Numpy-discussion] type coercion question
by Nadav Horesh March 31, 2004

March 31, 2004

(3) seems to be reasonable since Int32-precision > Float32-precision Nadav. -----Original Message----- From: Perry Greenfield [mailto:perry@stsci.edu] Sent: Wed 31-Mar-04 17:39 To: David M. Cooke; Todd Miller Cc: Gary Ruben; numpy-discussion Subject: [Numpy-discussion] type coercion question David Cooke wrote: > On Mon, Mar 29, 2004 at 06:55:57AM -0500, Todd Miller wrote: > > On Sun, 2004-03-28 at 22:46, Gary Ruben wrote: > > > > > >>> cos(1) > > > > > 0.54030227661132813 > > > > > > > > > > gives a different result to cos(1.) > > > <snip> > > > > > Do others think precision is being lost unnecessarily? > > > > > > > > No. Do you have any suggestions? > > > > > > Yes. My problem is that numarray is not replicating the behaviour of > > > the Python math module, which presumably coerces immediately to the > > > float precision of the underlying platform. This is probably a > > > float64 in Windows. If you don't explicitly specify that float32 is > > > to be used, shouldn't the default be for a rank-0 value to > > > immediately coerce ints to the same precision as the native Python > > > float type on the underlying platform, since you know it will be > > > coerced to that later and in the meantime you've lost precision > > > because you've applied a function to a value of lower precision? > > > > > > > I see your point and I'll talk it over with Perry unless he chimes in on > > his own. I'm ambivalent: while it would be nice for the numarray > > ufuncs to act as full equivalents to the Python math functions in scalar > > cases, numarray has to strike a balance between managing storage space > > and maintaining precision and these two goals are in conflict. I think > > using an array package you have to be at least a little more aware of > > storage concerns. > > I'll throw in a vote for 'cos(1)' coercing 1 to a (equivalent-to-) > Python float. The reason is that I have 'from numarray import *' for my > interactive interpreter, as I use numarray a lot in that. > I would rather not have to remember to always cast my args to ufuncs to > arrays. This isn't a storage space problem, per se., the question is > whether cos(1) and cos(1.0) should return the same answer. > > Having cos(1) cast 1 to a Float32 makes numarray much less useful as a > calculator -- mistakes are more likely. I'll probably switch my > interpreter back to Numeric so as not to make mistakes, or I'll write a > wrapper (which I'll post if I do). > > Whether cos([1,1,1]) and cos([1.0,1.0,1.0]) are the same I'd say is > different, as there I've taken the conscious decision not to cast to an > array. (And the fact that cos([1,1,1]) will return an array printed out > with 'type=Float32' is a clue to what I've done.) > Let me say that I see the last issue (whether cos([1,1,1]) and cos([1.0,1.0,1.0]) are the same) is important. If cos([1,1,1])[0] != cos(1) I think that is just as bad. So the question is whether ints scalars and arrays should automatically be promoted to double floats when given to unary scientific functions (sqrt, sin, cos, log, etc.). By the way, if an Int32 is so promoted, I don't see why it isn't the same for Int8, Int16, etc. But it appears that Numeric promotes Int32 to Float64 for cos(), but promotes In16 to Float32 for cos(). I believe making this change to numarray is fairly easy (we'd have to check). But is what most people want? Should we retain complete compatibility with Numeric (which, as pointed out, treats different kinds of integers differently) Just to summarize what I see as acceptable choices: 1) ints promote to Float32 (current behavior) 2) ints promote to Float64 3) Int32 promotes to Float64, lesser ints promote to Float32 (Numeric behavior) Perry ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion

1 0