NumPy-Discussion January 2007

numpy-discussion@python.org

96 participants
115 discussions

by Robert Kern

I made a few minor adjustments to make sure that Pyrex 0.9.5 builds mtrand.pyx cleanly. It's a bit pickier than previous versions. However, it also generates C code that compiles without warnings! Consequently, I recommend that all numpy developers should upgrade to Pyrex 0.9.5 and cease using the generate_mtrand_c.py script which I shall remove shortly. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

14 years, 12 months

kron bug with zero-length dimensions?

by Sven Schreiber

Hi, the kron(a,b) function seems to allow shapes such as (0,x) or (y,0) only for the second argument b, not for the first argument a. (See below for examples.) Maybe it's too harsh to call it a bug because the result is typically not defined mathematically. But then why differentiate between allowing those things for b (very useful), but not for a (thus requiring workarounds.) Thanks for your help, Sven >>> n.kron(n.ones((0,1)), n.ones((1,1))) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/numpy/lib/shape_base.py", line 572, in kron result = concatenate(result, axis=axis) ValueError: concatenation of zero-length sequences is impossible >>> n.kron(n.ones((1,0)), n.ones((1,1))) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/numpy/lib/shape_base.py", line 572, in kron result = concatenate(result, axis=axis) ValueError: concatenation of zero-length sequences is impossible >>> n.kron(n.ones((1,1)), n.ones((0,1))) array([], shape=(0, 1), dtype=float64) >>> n.kron(n.ones((1,1)), n.ones((1,0))) array([], shape=(1, 0), dtype=float64) >>> n.__version__ '1.0.1'

14 years, 12 months

python's random.random() faster than numpy.random.rand() ???

by Mark P. Miller

Greetings: I've recently been working with numpy's random number generators and noticed that python's core random number generator is faster than numpy's for the uniform distribution. In other words, for a in range(1000000): b = random.random() #core python code is substantially faster than for a in range(1000000): b = numpy.random.rand() #numpy code For other distributions that I've worked with, numpy's random number generators are much faster than the core python generators. Any thoughts? Just wanted to mention it to you. Or should I be using some other approach to call numpy's uniform generator? -Mark -- Dr. Mark P. Miller Department of Biology 5305 Old Main Hill Utah State University Logan, UT 84322-5305 USA ><><><><><><><><><><><><><><><>< http://www.biology.usu.edu/people/facultyinfo.asp?username=mpmbio http://www.marksgeneticsoftware.net

14 years, 12 months

added 1.0.1 release notes to wiki

by Martin Spacek

Just a note that I've copied over the 1.0.1 release notes from SourceForge: http://sourceforge.net/project/shownotes.php?group_id=1369&release_id=468153 over to the wiki: http://scipy.org/ReleaseNotes/NumPy_1.0 Should 1.0.1 get its own page, as previous 0.9.x releases did? Martin

14 years, 12 months

inplace operations

by BBands

If I have a NumPy array like so: [[1, 12], [2, 13], [3, 14], [4, 15], [5, 16], [6, 15], [7, 14]] How can I do an inplace diff, ending up with this? [[1, 0], [2, 1], [3, 1], [4, 1], [5, 1], [6, -1], [7, -1]] Also, can I covert to natural logs in place? [[1, 2.4849], [2, 2.5649], [3, 2.6391], [4, 2.7081], [5, 2.7726], [6, 2.7081], [7, 2.5649]] Thanks in advance, jab -- John Bollinger, CFA, CMT www.BollingerBands.com If you advance far enough, you arrive at the beginning.

14 years, 12 months

Arrays of poly1d objects, is this a bug?

by Fernando Perez

Hi all, I'm puzzled by this behavior a colleague ran into: In [38]: p1=N.poly1d([1.]) In [39]: a=N.array([p1],dtype='O') In [40]: a Out[40]: array([], shape=(1, 0), dtype=object) In [42]: print a [] In [43]: N.__version__ Out[43]: '1.0.2.dev3512' He saw it running r3520 as well. This looks like a bug to me, since it seems impossible to make arrays of poly1d objects: In [44]: a=N.array([p1,p1],dtype='O') In [45]: a Out[45]: array([], shape=(2, 0), dtype=object) In [46]: print a [] Any hints? Thanks, f

14 years, 12 months

C-API: deallocating a partially filled object array

by Martin Wiechert

Hi gurus, is it (in C) safe to deallocate an array of type NPY_OBJECT, which carries NULL pointers? TIA, Martin

14 years, 12 months

Build numpy without support of "long double' on OS-X

by Sebastian Haase

Hi! When I try running my code on panther (10.3) with a numpy that was built on tiger (10.4) it can't load numpy because of missing symbols in numpy/core/umath.so The symbols are _acoshl$LDBL128 _acosl$LDBL128 _asinhl$LDBL128 (see my post from 5 oct 2006: http://permalink.gmane.org/gmane.comp.python.numeric.general/8521 ) I traced the problem to the libmx system library. Since I really don't need "long double" (128 bit) operations - I was wondering if there is a flag to just turn them of? Will SciPy built with this ? (Is there an equivalent flag maybe ?) Thanks, Sebastian Haase

14 years, 12 months

Re: [Numpy-discussion] setmember1d memory leak?

by Jan Strube

I would also like to see a method that doesn't have the unique members requirement. If setmember1d cannot be modified to do that, is there another method that doesn't have these restrictions. Or could one be added? Thanks, Jan

14 years, 12 months

average() or mean() errors

by Daniel Smith

When calling the average() or mean() functions on a small array (3 numbers), I am seeing significant numerical errors (on the order of 1% with data to 8 significant digits). The code I am using is essentially: A = zeros(3) A[i] = X B = average(A) Is there something else I need to call to get better accuracy? Writing my own average function has sufficed, but I am curious if I am just calling the function wrong.

14 years, 12 months

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 January 2007