Mailman 3 January 2006 - NumPy-Discussion

Re: ***[Possible UCE]*** Re: [Numpy-discussion] Speed ups to matrix-vector multiplication
by Travis Oliphant Jan. 17, 2006

Jan. 17, 2006

Paulo J. S. Silva wrote: >Travis, > >It is good that my code was helpful. > >I have just tested your code and it seems to be OK now. I have written a >script to test the dot function. I am sending it attached. Think of the >script as a unit test for dot. (It tests correctness of the computations >and verify the dimensional integrity check). > > Thanks for the tests. I'll make them unit tests and put them in the test suite.. >I am using the svn version of numpy now (revision 1923). I am still >seeing slow matrix times vector multiplications if the matrix is >transposed: > >What is going on? > > Hmm.. I'm not sure. What I expect to get called is the cblas_Xgemv function with Order CblasColMajor if A has been transposed... Perhaps this is a slower operation? -Travis

1 0

Use of numpy, scipy and matplotlib (pylab) together?
by Rudolph van der Merwe Jan. 17, 2006

Jan. 17, 2006

What is the correct importing order if one wants to use the full capabilities of numpy+scipy+matplotlib? I have all three packages installed and all of them import correctly. For Python code that makes use of all of these, should the import order be: from numpy import * from scipy import * from pylab import * ? I assume a certain amount of re-importing will occur since both scipy and matplotlib (pylab) uses numpy. How does one ensure that the correct objects don't get overwritten? -- Rudolph van der Merwe

4 3

Re: [Numpy-discussion] Maximum available dimensions in numpy
by Joe Harrington Jan. 17, 2006

Jan. 17, 2006

For reasons that were laid out when this topic came up a month or so ago (perhaps on another of our infinitude of email lists), I'm opposed to reducing the number of dimensions to even 10. A sizeable chunk of the community does use many dimensions. I routinely use more than 5 dimensions, and I'm pretty good at reducing the number for performance where it's practical. There's an atmospheric sciences tool called vis5d (x,y,z,t,field parameter vector), which shows just how commonly meteorologists use 5 dimensions. I don't think of the atmospheric sciences as being a particularly dimension-heavy group, but you can easily think of adding a few more dimensions that let you choose model runs with varied initial parameters. Try tracking the variables of a complex medical trial in just 5 dimensions. IDL's limit is 7 dimensions, and many don't use it as a result. Having more in our default binary installs is a selling point. This is a pretty limiting change to be suggesting, so if there's a change to be made, it should come only after implementing and benchmarking to see what the actual performance benefits are, and then polling the community. If there is a really big improvement in having 4 or 8 dimensions max, and if "malloc and unlimit everything" isn't fast, then it may be worth supporting low-dim and high-dim versions of the binary installs. But, let's wait until we have more volunteers before doing that. --jh--

1 0

Some inconsistency in numarray.records format support
by Francesc Altet Jan. 17, 2006

Jan. 17, 2006

Hi, When building recarrays in numpy following the numarray convention: In [2]: numpy.zeros((3,), dtype='u1') Out[2]: array([0, 0, 0], dtype=uint8) In [3]: numpy.zeros((3,), dtype='u1,f4') Out[3]: array([(0, 0.0), (0, 0.0), (0, 0.0)], dtype=(void,5)) In [4]: numpy.zeros((3,), dtype='2u1,f4') Out[4]: array([(array([0, 0], dtype=uint8), 0.0), (array([0, 0], dtype=uint8), 0.0), (array([0, 0], dtype=uint8), 0.0)], dtype=(void,6)) In [7]: numpy.zeros((3,), dtype='(2,)u1,f4') Out[7]: array([(array([0, 0], dtype=uint8), 0.0), (array([0, 0], dtype=uint8), 0.0), (array([0, 0], dtype=uint8), 0.0)], dtype=(void,6)) So far so good, but In [5]: numpy.zeros((3,), dtype='2u1') --------------------------------------------------------------------------- exceptions.TypeError Traceback (most recent call last) /home/faltet/python.nobackup/numpy/<ipython console> TypeError: data type not understood Also: In [6]: numpy.zeros((3,), dtype='(2,)u1') --------------------------------------------------------------------------- exceptions.ValueError Traceback (most recent call last) /home/faltet/python.nobackup/numpy/<ipython console> /usr/lib/python2.4/site-packages/numpy/core/_internal.py in _commastring(astr) 296 res = _split(astr) 297 if (len(res)) == 1: --> 298 raise ValueError, "no commas present" 299 result = [] 300 for k,item in enumerate(res): ValueError: no commas present Perhaps this is the same case as defining tables with just one column? -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"

1 0

Probable bug
by Joachim Saul Jan. 17, 2006

Jan. 17, 2006

Hello all, I have observed a weird behaviour with 24.2, which actually can break existing code: >>> import Numeric >>> Numeric.__version__ '23.8' >>> x=Numeric.zeros(5) >>> type(x[0]) <type 'int'> >>> x=Numeric.zeros(5,'f') >>> type(x[0]) <type 'float'> >>> This is what I would expect. However, using 24.2: >>> import Numeric >>> Numeric.__version__ '24.2' >>> x=Numeric.zeros(5) >>> type(x[0]) <type 'int'> >>> x=Numeric.zeros(5, 'f') >>> type(x[0]) <type 'array'> >>> print type(1*x[0]) <type 'float'> Strange, isn't it? Is there any rationale behind this inconsistent behaviour or is it just a bug? Cheers, Joachim

1 0

Inconsistency in dtype.arrdescr?
by Francesc Altet Jan. 16, 2006

Jan. 16, 2006

Hi, I find the next a bit misleading: >>> numpy.array((3,), dtype='u4').dtype.arrdescr [('', '<u4')] but... >>> numpy.zeros((3,), dtype='u4,u2').dtype.arrdescr [('f1', '<u4'), ('f2', '<u2')] I think it would be more consistent if the former expression would give as output: [('f1', '<u4')] Cheers, -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"

3 3

Re: [SciPy-user] numpy.dft.real+fft problem?
by Travis Oliphant Jan. 16, 2006

Jan. 16, 2006

Andrew Jaffe wrote: >Hi All, > >[This has already appeared on python-scientific-devel; apologies to >those of you seeing it twice...] > >There seems to be a problem with the real_fft routine; starting with a >length n array, it should give a length n/2+1 array with real numbers >in the first and last positions (for n even). However, note that the >last entry on the first row has a real part, as opposed to the >complex routine fft, which has it correct. > >The weirdness of the real part seems to imply it's due to uninitialized >memory. > > Thanks for the catch. Yes it was due to uninitalized memory. PyArray_FromDims always initializes the memory to zero (but it uses int * arguments). The new routine was using PyArray_SimpleNew (using intp* arguments) which does not initialize the memory to zero. Changing PyArray_SimpleNew to PyArray_Zeros fixed the problem. -Travis

1 0

Re: [Numpy-discussion] arrayobject.h (and friends) install location
by Sasha Jan. 16, 2006

Jan. 16, 2006

> Wouldn't then a > ~/my_numpy/include/numpy/* > be reasonable? > I've asked the same question before: http://www.scipy.net/pipermail/scipy-dev/2006-January/004952.html I understand that this was done for the benefit of people who have permissions to write to site-packages, but not to the include directory. I don't see why such users cannot just provide --prefix and why would any administrator allow users without administrative privileges to write to the system site-packages directory. For what it's worth, my +1 on keeping includes in include. -- sasha

1 0

buglet in numpy-0.9.4.1915
by Gerard Vermeulen Jan. 16, 2006

Jan. 16, 2006

PyChecker found this: /home/packer/usr/lib/python2.4/site-packages/numpy/core/numeric.py:311: No global (math) found math must be probably replaced by umath. I did not verify all of PyChecker's noise, but this one is obviously a bug. Gerard

1 0

bug in shape()
by Eric Firing Jan. 16, 2006

Jan. 16, 2006

Travis et al., Jeff Whitaker pointed out to me that masked array support in matplotlib contouring does not work with numpy. The problem is that the shape function does not work with masked arrays. One easy solution is to return to the older Numeric version of shape via the attached patch against svn (edited to remove irrelevant chunks). Thanks. Eric

1 0