Mailman 3 February 2003 - NumPy-Discussion

Problems with view.py
by Karthikesh Raju 12 Feb '03

12 Feb '03

Hi All, i was using view.py, that comes with NumPy. Somehow view.py slows down the whole ipython shell. Most of the times the program crashes dumping core. The version of my Numeric is 21.3. Is there some new version of view.py? Is there something needed? Or rather is there some better viewer for viewing images in python ( specifically for viewing image processing images). Best regards karthik ----------------------------------------------------------------------- Karthikesh Raju, email: karthik(a)james.hut.fi Researcher, http://www.cis.hut.fi/karthik Helsinki University of Technology, Tel: +358-9-451 5389 Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277 Department of Computer Sc., P.O Box 5400, FIN 02015 HUT, Espoo, FINLAND -----------------------------------------------------------------------

1 0

Fwd: Re: A couple of questions on Pyrex
by Francesc Alted 12 Feb '03

12 Feb '03

Hi, Here is the Greg's reply to my questions. It seems like Pyrex is not going to change in these two issues. Well, at least he considered the first to be an "interesting" idea. Cheers, ---------- Missatge transmès ----------

1 0

Re: [Numpy-discussion] Psyco MA?
by Francesc Alted 10 Feb '03

10 Feb '03

A Dissabte 08 Febrer 2003 11:54, Joachim Saul va escriure: > Please check out the Pyrex doc. It's actually very easy right now, > *if* you can live without "sequence operators" such as slicing, > list comprehensions... but this is going to be supported, again > according to the doc. Why you are saying that slicing is not supported?. I've checked them (as python expressions, of course) and work well. May be you are referring to cdef'd c-typed arrays in Pyrex?. I think this should be a dangerous thing that can make the pointer arithmetic to slow down because of the additional required checks in the slice range. > For example, I may call (C-like) > > arr = PyArray_FromDims(1, &n, PyArray_DOUBLE) > > but could have also used a corresponding Python construct like > > from Numeric import zeros > arr = zeros(n, 'd') > > I expect the latter to be slower (not tested), but one can take > Python code "as is" and "compile" it using Pyrex. I was curious about that and tested it in my Pentium 4 @ 2 GHz laptop and for small n (just to look for overhead). The C-like call takes 26 us and the Python-like takes 52 us. Generally speaking, you can expect an overhead of 20 us (a bit more as you pass more parameters) calling Python functions (or Python-like functions inside Pyrex) from Pyrex, compared to when you use a C-API to call the corresponding C function. In fact, calling a C-function (or a cdef Pyrex function) from Pyrex takes no more time than calling from C to C: on my laptop both scores at 0.5 us. The fact that calling C functions from Pyrex has not a significant overhead (compared with calls from C to C) plus the fact that Pyrex offers a C integer loop makes Pyrex so appealing for linear algebra optimizations, not only as a "glue" language. Another advantage is that with Pyrex you can define classes with a mix of C-type and Python-type attributes. This can be very handy to obtain a compact representation of objects (whenever you do not need to access the C-typed ones from Python, but anyway, you can always use accessors if needed). Cheers, -- Francesc Alted

1 0

average(), again(?)
by Magnus Lie Hetland 10 Feb '03

10 Feb '03

I think perhaps I've asked this before -- but is there any reason why the average() function from MA can't be copied (without the mask stuff) to numarray? Maybe it's too trivial (unlike in the masked case)...? It just seems like a generally useful function to have... -- Magnus Lie Hetland "Nothing shocks me. I'm a scientist." http://hetland.org -- Indiana Jones

1 0

array()? (Bug?)
by Magnus Lie Hetland 10 Feb '03

10 Feb '03

Is this a bug, or is there a motivation behind it? >>> from numarray import array >>> array() >>> IOW: Why is array callable without any arguments when it doesn't return anything? E.g. if I call array(**kwds) with some dictionary, I'd expect an exception (since a default array isn't really possible) if kwds were empty... Or? (I'm using 0.4 -- for some reason I can't get the cvs version to compile on Solaris.) -- Magnus Lie Hetland "Nothing shocks me. I'm a scientist." http://hetland.org -- Indiana Jones

2 2

Plain array performance
by Magnus Lie Hetland 10 Feb '03

10 Feb '03

Just curious: What is the main strength of the array module in the standard library? Is it footprint/memory usage? Is it speed? If so, at what sizes? I ran some simple benchmarks (creating a list/array, iterating over them to sum up their elements, and extracting the slice foo[::2]) and got the following rations (array_time/list_time) for various sizes: Size 100: Creation: 1.13482142857 Sum: 1.54649265905 Slicing: 1.53736654804 Size 1000: Creation: 1.62444133147 Sum: 1.18439932835 Slicing: 1.56350184957 Size 10000: Creation: 1.61642712328 Sum: 1.47768567821 Slicing: 1.45889354599 Size 100000: Creation: 1.72711084285 Sum: 0.952593142445 Slicing: 1.05782341361 Size 1000000: Creation: 1.56617139425 Sum: 0.735687066032 Slicing: 0.773219364465 Size 10000000: Creation: 1.57903195174 Sum: 0.727253180418 Slicing: 0.726005428022 These benchmarks are pretty naïve, but it seems to me that unless you're working with quite large arrays, there is no great advantage to using arrays rather than lists... (I'm not including numarray or Numeric in the equation here -- I just raise the issue because of the use of arrays in Psymeric...) Just curious... -- Magnus Lie Hetland "Nothing shocks me. I'm a scientist." http://hetland.org -- Indiana Jones

2 2

Re: [Numpy-discussion] Plain array performance
by Magnus Lie Hetland 10 Feb '03

10 Feb '03

Tim Hochberg <tim.hochberg(a)ieee.org>: > [snip] In my continued quest, I found this: http://www.penguin.it/pipermail/python/2002-October/001917.html It sums up (in Italian, though) the great memory advantage of arrays. (Might be a good idea to be explicit about this in the docs, perhaps... Hm.) > The reason I'm using arrays in psymeric are twofold. One is memory > usage. Right. > The other reason is that Psyco likes arrays > (http://arigo.tunes.org/psyco-preview/psycoguide/node26.html). I sort of thought that might be a reason... :) > In fact it was this note " The speed of a complex algorithm using an > array as buffer (like manipulating an image pixel-by-pixel) should > be very high; closer to C than plain Python." that led me to start > playing around with psymeric. I see. > Just for grins I disabled psyco and reran some tests on psymeric. > Instead of comporable speed to NumPy, the speed drops to about 25x > slower. Yikes! > I actually would have expected it to be worse, but the drop off is > still pretty steep. Indeed... Hm... If only we could have Psyco for non-x86 platforms... Oh, well. I guess we will, some day. :) > -tim -- Magnus Lie Hetland "Nothing shocks me. I'm a scientist." http://hetland.org -- Indiana Jones

1 0

Some bugs in Numeric fixed today in CVS
by Paul Dubois 07 Feb '03

07 Feb '03

[ 614808 ] Inconsistent use of tabs and spaces Fixed as suggested by Jimmy Retzlaff LinearAlgebra.py Matrix.py RNG/__init__.py RNG/Statistics.py [ 621032 ] needless work in multiarraymodule.c Fixes suggested by Greg Smith applied. Also recoded OBJECT_DotProduct to eliminate a warning error. [ 630584 ] generalized_inverse of complex array Fix suggested by Greg Smith applied. [ 652061 ] PyArray_As2D doesn't check pointer. Fix suggested by Andrea Riciputi applied. [ 655512 ] inverse_real_fft incorrect many sizes Fix given by mbriest applied.

1 0

more than 2-D numarrays in recarray?
by Francesc Alted 04 Feb '03

04 Feb '03

Hi, It seems that recarray doesn't support more than 1-D numarray arrays as fields. Is that a fundamental limitation? If not, do you plan to support arbitrary dimensions in the future?. Thanks, -- Francesc Alted

3 4