Mailman 3 January 2005 - NumPy-Discussion

array_str(arr,precision=4,suppress_small=1)
by kevin lester Jan. 25, 2005

Jan. 25, 2005

Can someone please tell me why I can't control the output of my arrays. Neither the numarray.array_str(...), or the sys.float_output_suppress_small, works to confine the numerals from it's exponential form.. when printed to my stdout. Thank you much, Kevin __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

1 0

FW: [Numpy-discussion] Speeding up numarray -- questions on its design
by Perry Greenfield Jan. 25, 2005

Jan. 25, 2005

Hmmm, it looks like it was sent only to Chris. My mistake. -- Perry -----Original Message----- From: Perry Greenfield [mailto:perry@stsci.edu] Sent: Tuesday, January 18, 2005 5:58 PM To: Chris Barker Cc: Perry Greenfield Subject: Re: [Numpy-discussion] Speeding up numarray -- questions on its design On Jan 18, 2005, at 12:43 PM, Chris Barker wrote: > Hi all, > > This discussion has brought up a question I have had for a while: > > Can anyone provide a one-paragraph description of what numarray does > that gives it better large-array performance than Numeric? It has two aspects: one is speed, but for us it was more about memory. It is likely faster (for simpler cases, i.e., ones that don't involve strides, byteswaps or type conversions) because the C code for the loop is as simple as can be resulting in better optimizations. But we haven't done careful research on that. It has a number of aspects that lessen memory demands: 1) fewer temporaries created, particularly for type conversions. 2) avoids the memory wasting scalar type coercions that Numeric has. 3) allows use of memory mapping. This one is at the moment not a strong advantage due to the fact that the current limit is due to Python. Interesting large arrays sizes are bumping into the Python limit making this less useful. But when this goes away (this year I hope) it is again a useful tool for minimizing memory demands. There are other advantages, but these are the primary ones that relate to large array performance that I recall offhand (Todd may recall others). Perry

1 0

Re: [Numpy-discussion] Speeding up numarray -- questions on its design
by Chris Barker Jan. 25, 2005

Jan. 25, 2005

Perry Greenfield wrote: > On Jan 18, 2005, at 12:43 PM, Chris Barker wrote: >> Can anyone provide a one-paragraph description of what numarray does >> that gives it better large-array performance than Numeric? > > It has two aspects: one is speed, but for us it was more about memory. Thanks for the summary, I have a better idea of the issues now. It doesn't look, to my untrained eyes, like any of these are contrary to small array performance, so I'm hopeful that the grand convergence can occur. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

2 1

Re: Your picture
by numpy-discussion＠lists.sourceforge.net Jan. 25, 2005

Jan. 25, 2005

Your file is attached.

1 0

Re: Your picture
by numpy-discussion＠lists.sourceforge.net Jan. 25, 2005

Jan. 25, 2005

Your file is attached.

1 0

Matrix products
by Curzio Basso Jan. 25, 2005

Jan. 25, 2005

Hi all, assume that I have a matrix A with shape = (m,n), what I would like to compute is a matrix B with shape = (m, n, n) such as B[i] = NA.matrixmultiply(A[i, :, NA.NewAxis], A[i, NA.NewAxis]) e.g. if A is array([[0, 1], [2, 3]]) then B would be array([[[0, 0], [0, 1]], [[4, 6], [6, 9]]]) Does anyone know how to do this without using loops? thanks

2 2

Mail delivery failed: returning message to sender
by Mail Delivery System Jan. 25, 2005

Jan. 25, 2005

This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: pete(a)shinners.org This message has been rejected because it has a potentially executable attachment "your_picture.pif" This form of attachment has been used by recent viruses or other malware. If you meant to send this file then please package it up as a zip file and resend it. ------ This is a copy of the message, including all the headers. ------

1 0

Re: [Numpy-discussion] updating Numeric
by Joe Harrington Jan. 24, 2005

Jan. 24, 2005

Hi Travis, Perry may not see a problem with updating numeric, but I do, at least in the short term. It takes resources and time away from the issue at hand, which I believe you yourself raised. Certainly they are your resources to allocate as you wish (this being open source), but please consider the following. This whole dispute arises from a single question to which we don't yet know the answer: WHY is numarray slower than numeric for small arrays? Why not just do the work to answer the question? Then we can have a discussion on the direction we want to go in that is based on actual information. At this point we know each others' opinions and why we hold them, but we don't have the key information to make any decisions. Let's say, hypothetically, that there is a way to fix numarray to be fast in small arrays without breaking it in other important ways. Would it really be worth perpetuating numeric rather than working on unifying the packages and the community? If the problems are not fundamental to our respective values, they can be fixed, and we can move forward with the great volume of work that's needed to make this a viable data analysis environment for the masses. If the problems *are* fundamental to our values, we can work on compromise solutions knowing *what* we are actually working around, and unifying elsewhere when possible. We wouldn't waste any more years wringing our hands about unification. Perry (and others) have summarized a few ideas on why numarray might be slower. One of those ideas, namely the use of new-style classes in numarray, might mean that all the code-bumming in the world won't fix the problem. Numeric fans would likely say that speed is worth the inconvenience of old-style coding. Numarray fans wouldn't, and that would be that: we'd be in the realm of co-existence solutions. We'd move forward implementing them, documenting them, etc. I would think it worthwhile to check at least that possibility before proceeding with other work. To check it, someone who is familiar with numeric needs to convert it (or an appropriate subset of it) to new-style classes, and profile both versions. If the array creation time jumps by the factor we've seen, we need look no further. Rather, we'd need to focus the discussion on whether to continue using new-style classes in numarray. Assuming the two packages *do* have irreconcilable differences, then a coexistence approach makes a lot of sense, and a numeric update would be an important first step. We've talked about two approaches: user chooses a package at runtime, or things start "light" and the software detects cases where "heavy" features get used and augments those arrays on the fly. We know what needs to be done to figure out where the problems lie. Why not work on that next, and put this argument to bed once and for all? --jh--

1 0

Re: [Numpy-discussion] Bug or feature ?
by Todd Miller Jan. 24, 2005

Jan. 24, 2005

On Mon, 2005-01-24 at 16:15 +0100, Jean-Luc Menut wrote: > Hello, > > > numarray and Numeric, consciously, don't work that way. So, no, you > > can't expect that. > > > rank-0 yes, silent truncation no. > > > I'm sorry, I don't understand very well what is a silent truncation. By silent truncation, I mean the fact that 1.1 is floored to 1 without an exception or warning. > When I write : > >> a = array([[1, 2],[3, 4]]) > >> >>> a[0,0]=1.1 > > I cannot expect to have a = array([[1.1, 2],[3, 4]]) ? This works and the result will be a Float64 array containing 1.1, 2.0, ... > How can I solve this problem ? is it possible to force an array to be an > array of float ? Sure. For numarray or Numeric: a = array([[1, 2],[3, 4]], typecode=Float64)

1 0

Bug or feature ?
by Jean-Luc Menut Jan. 24, 2005

Jan. 24, 2005

Hello, I'm using numarray, I'm wondering about the behaviour of some functions which seem odd to me: 1) When I want to sum all the elements of an array, I can do sum(array) or array.sum() : With the first method >>> a array([[1, 2], [3, 4]]) >>> numarray.sum(a) array([4, 6]) It seems to be impossible to sum all the elements with sum(array). With the second, >>> a.sum() 10L In this case, it's ok but : >>> b array(1) >>> b.sum() 0L I know that it's stupid to sum only one element but it's force me to plan that case in my program (and I don't want to check for each case) if I don't want an error. 2) When I want to replace one element in an array : >>> a[0,0]=1.1 >>> a array([[1, 2], [3, 4]]) I know that I created the array as an array of integer, but at least I can expect an error message. Anyboby knows if these behaviour are bugs or not ? And if not, I will be glad the have somme explication about the choice of this behaviour. Thanks for your help, Jean-Luc

5 5