Re: [Numpy-discussion] sorting -inf, nan, inf

Keith Goodman wrote: > In what order would you like argsort to sort the values -inf, nan, inf? > Ideally, -inf should sort first, inf should sort last and nan should raise an exception if present. -tim > In numpy 1.0b1 nan is always left where it began: > > EXAMPLE 1 > > >>> x >>>

Re: [Numpy-discussion] sorting -inf, nan, inf

A. M. Archibald wrote: > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > >> Keith Goodman wrote: >> >>> In what order would you like argsort to sort the values -inf, nan, inf? >>> >>> >> Ideally, -inf should so

Re: [Numpy-discussion] sorting -inf, nan, inf

Charles R Harris wrote: > > > On 9/19/06, *Tim Hochberg* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > A. M. Archibald wrote: > > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: >

Re: [Numpy-discussion] sorting -inf, nan, inf

A. M. Archibald wrote: > On 19/09/06, Charles R Harris <[EMAIL PROTECTED]> wrote: > > >> If this sort of thing can cause unexpected errors I wonder if it would be >> worth it to have a global debugging flag that essentially causes isnan to >> be called before any function applications. >>

Re: [Numpy-discussion] sorting -inf, nan, inf

A. M. Archibald wrote: > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >> I'm not sure where the breakpoint is, but I was seeing failures for all >> three sort types with N as high as 1. I suspect that they're all >> broken in the prese

Re: [Numpy-discussion] sorting -inf, nan, inf

Travis Oliphant wrote: > Tim Hochberg wrote: > > >> A. M. Archibald wrote: >> >> >> >>> On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>> >>>> I&#

Re: [Numpy-discussion] sorting -inf, nan, inf

Charles R Harris wrote: > > > On 9/19/06, *A. M. Archibald* <[EMAIL PROTECTED] > > wrote: > > On 19/09/06, Charles R Harris <[EMAIL PROTECTED] > > wrote: > > > > > > > > For floats we could use something like: > > >

Re: [Numpy-discussion] please change mean to use dtype=float

Robert Kern wrote: > Sebastian Haase wrote: > >> Robert Kern wrote: >> >>> Sebastian Haase wrote: >>> I know that having too much knowledge of the details often makes one forget what the "newcomers" will do and expect. >>> Please be more careful with such acc

Re: [Numpy-discussion] please change mean to use dtype=float

Robert Kern wrote: > David M. Cooke wrote: > >> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: >> >>> Let me offer a third path: the algorithms used for .mean() and .var() are >>> substandard. There are much better incremental algorithms that entirely >>> avoid >>> the need

Re: [Numpy-discussion] please change mean to use dtype=float

[Sorry, this version should have less munged formatting since I clipped the comments. Oh, and the Kahan sum algorithm was grabbed from wikipedia, not mathworld] Tim Hochberg wrote: > Robert Kern wrote: > >> David M. Cooke wrote: >> >> >>> On Wed,

Re: [Numpy-discussion] please change mean to use dtype=float

Robert Kern wrote: > David M. Cooke wrote: > >> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: >> >>> Let me offer a third path: the algorithms used for .mean() and .var() are >>> substandard. There are much better incremental algorithms that entirely >>> avoid >>> the need

Re: [Numpy-discussion] please change mean to use dtype=float

Robert Kern wrote: > David M. Cooke wrote: > >> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: >> >>> Let me offer a third path: the algorithms used for .mean() and .var() are >>> substandard. There are much better incremental algorithms that entirely >>> avoid >>> the need

Re: [Numpy-discussion] please change mean to use dtype=float

Tim Hochberg wrote: Robert Kern wrote: David M. Cooke wrote: On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: Let me offer a third path: the algorithms used for .mean() and .var() are substandard. There are much better incremental algorithms that entirely

Re: [Numpy-discussion] please change mean to use dtype=float

David M. Cooke wrote: > On Thu, 21 Sep 2006 11:34:42 -0700 > Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >> Tim Hochberg wrote: >> >>> Robert Kern wrote: >>> >>> >>>> David M. Cooke wrote: >>>> &g

Re: [Numpy-discussion] please change mean to use dtype=float

David M. Cooke wrote: > On Thu, 21 Sep 2006 11:34:42 -0700 > Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >> Tim Hochberg wrote: >> >>> Robert Kern wrote: >>> >>> >>>> David M. Cooke wrote: >>>> &g

Re: [Numpy-discussion] please change mean to use dtype=float

Tim Hochberg wrote: > David M. Cooke wrote: > >> On Thu, 21 Sep 2006 11:34:42 -0700 >> Tim Hochberg <[EMAIL PROTECTED]> wrote: >> >> >> >>> Tim Hochberg wrote: >>> >>> >>>>

Re: [Numpy-discussion] please change mean to use dtype=float

Sebastian Haase wrote: > On Thursday 21 September 2006 15:28, Tim Hochberg wrote: > >> David M. Cooke wrote: >> >>> On Thu, 21 Sep 2006 11:34:42 -0700 >>> >>> Tim Hochberg <[EMAIL PROTECTED]> wrote: >>> &g

Re: [Numpy-discussion] please change mean to use dtype=float

Charles R Harris wrote: [CHOP] > On 9/22/06, *Tim Hochberg* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > It sounds like there is some consensus to do something to improve the > precision after 1.0 comes out. I don't think the details

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

3. No problem to compile Python-2.5, but i have some >> troubles with Numpy-1.0rc1 and I didn't find any help in the provided >> setup.py. So, does someone can tell me how to do it? >> >> >> > I don't use VisualStudio2003 on Windows to compile NumPy

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

Tim Hochberg wrote: > Travis Oliphant wrote: >> mg wrote: >> >>> Hello, >>> >>> I just download the newly Python-2.5 and Numpy-1.0rc1 and all work >>> fine on Linux-x86 32 and 64bit platforms. >>> Now, I try to compile the both distr

Re: [Numpy-discussion] return value of negative power

Stefan van der Walt wrote: > Hi all, > > Currently, the power function returns '0' for negative powers of > integers: > > In [1]: N.power(3,-2) > Out[1]: 0 > > (or, more confusingly) > > In [1]: N.power(a,b) > Out[1]: 0 > > which is almost certainly not the answer you want. Two possible > solution

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

Tim Hochberg wrote: > Tim Hochberg wrote: > >> Travis Oliphant wrote: >> >>> mg wrote: >>> >>> >>>> Hello, >>>> >>>> I just download the newly Python-2.5 and Numpy-1.0rc1 and all work >>>>

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

Francesc Altet wrote: > Hello, > > Is the next a bug a feature? > > In [102]: f4=numpy.ndarray(buffer="a\x00b"*4, dtype="f4", shape=3) > > In [103]: f4 > Out[103]: array([ 2.60561966e+20, 8.94319890e-39, 5.92050103e+20], > dtype=float32) > > In [104]: f4[2] = 2 > -

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

Travis Oliphant wrote: > Tim Hochberg wrote: > >> Francesc Altet wrote: >> >> It's not that the it's being built from ndarray, it's that the buffer >> that you are passing it is read only. >> > This is correct. > >> In

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Travis Oliphant wrote: > Albert Strasheim wrote: > > >> In [571]: x1 = N.random.randn(2000,39) >> >> In [572]: y1 = N.random.randn(64,39) >> >> In [574]: %timeit z1=x1[...,N.newaxis,...]-y1 10 loops, best of 3: 703 ms >> per loop >> >> In [575]: z1.shape >> Out[575]: (2000, 64, 39) >> >> As far

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Tim Hochberg wrote: > Travis Oliphant wrote: > >> Albert Strasheim wrote: >> >> >> >>> In [571]: x1 = N.random.randn(2000,39) >>> >>> In [572]: y1 = N.random.randn(64,39) >>> >>> In [574]: %timeit z1=x1[...,N.ne

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Travis Oliphant wrote: > Albert Strasheim wrote: > [1] 12.97% of function time [2] 8.65% of functiont ime [3] 62.14% of function time If statistics from elsewhere in the code would be helpful, let me know, >>> and >>> >>>

Re: [Numpy-discussion] ValueError: object too deep for desired array

[EMAIL PROTECTED] wrote: > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\Documents and Settings\kenny>cd c:\lameness > > C:\lameness>c:\Python24\python.exe templatewindow.py > a = [[ 1.00013175e+00 2.63483019e-05 1.6740e+00 5.22246363e-05 >

Re: [Numpy-discussion] speeding up y[:, i] for y.shape = (big number, small number)

David Cournapeau wrote: > Hi, > > I was wondering if there was any way to speed up the following code: > > y = N.zeros((n, K)) > for i in range(K): > y[:, i] = gauss_den(data, mu[i, :], va[i, :]) > > Where K is of order 1e1, n of order 1e5. Normally, gauss_den is a quite > expensive f

Re: [Numpy-discussion] Fastest way of distinguish a numpy scalar of a python scalar?

Francesc Altet wrote: > Hi, > > I thought that numpy.isscalar was a good way of distinguising a numpy scalar > from a python scalar, but it seems not: > > numpy.isscalar(numpy.string_('3')) > True > numpy.isscalar('3') > True > > Is there an easy (and fa

Re: [Numpy-discussion] complex numbers

Kenny Ortmann wrote: > excuse my laziness for not looking this up, I googled it but could not find > a solution. > matlab has a > isreal(array) > where if the array is full of real numbers the value returned is 1. > I'm translating matlab code and ran across > > if ~isreal(array) > array = abs

Re: [Numpy-discussion] complex numbers

David L Goldsmith wrote: > PS: The Python built in function (i.e., you don't even need numpy for > this) abs(x) is "vectorized" (i.e., accepts a (nested) sequence, incl. > numpy array, argument) and overloaded to give the modulus (i.e., > Pythagorean "length") of a complex number when such is i

Re: [Numpy-discussion] Complex numbers response

Kenny Ortmann wrote: >> There may be a better way, but:: >> >>alltrue(isreal(x)) >> >> Would work. As would: >> >>not sometrue(x.imag) >> >> In the above test you are already negating the test, so you could just >> drop the not. >> >>> and if so is >>> there a way to extract the(a + i

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Ivan Vilata i Balaguer wrote: > It seemed that discontiguous arrays worked OK in Numexpr since r1977 or > so, but I have come across some alignment or striding problems which can > be seen with the following code:: > > import numpy > import numexpr > > array_length = 10 > array_desc

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

ting them back. That's to limit the number of bytecodes that we need to support and keep the switch statement at a manageable size. However, it doesn't look like that ever got implemented, so the answer is probably no. -tim > -Sebastian > > > On Wednesday 04 October 2006 09:

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Ivan Vilata i Balaguer wrote: > It seemed that discontiguous arrays worked OK in Numexpr since r1977 or > so, but I have come across some alignment or striding problems which can > be seen with the following code:: I looked at this just a little bit and clearly this bit from interp_body cannot wor

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

David M. Cooke wrote: > On Wed, 04 Oct 2006 10:19:08 -0700 > Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >> Ivan Vilata i Balaguer wrote: >> >>> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or >>> so, but I have come

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Tim Hochberg wrote: > David M. Cooke wrote: >> On Wed, 04 Oct 2006 10:19:08 -0700 >> Tim Hochberg <[EMAIL PROTECTED]> wrote: >> >> >>> Ivan Vilata i Balaguer wrote: >>> >>>> It seemed that discontiguous arrays worked OK in Nu

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Ivan Vilata i Balaguer wrote: > En/na Tim Hochberg ha escrit:: > > >> Ivan Vilata i Balaguer wrote: >> >>> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or >>> so, but I have come across some alignment or striding problems w

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Travis Oliphant wrote: > Tim Hochberg wrote: > > >>>> >>>> >>>> >>>> >>> That would be easy to do. Right now the opcodes should work correctly >>> on data that is spaced in multiples of the itemsi

Re: [Numpy-discussion] repmat

Bill Baxter wrote: > [There seem to have been some gmail delivery problems that prevented > my previous mail on this subject from being delivered] > > I've proposed that we fix repmat handle arbitrary dimensions before 1.0. > >http://projects.scipy.org/scipy/numpy/ticket/292 > > I don't think t

Re: [Numpy-discussion] tensor product

Charles R Harris wrote: > Hi Nadav, > > On 10/8/06, *Nadav Horesh* <[EMAIL PROTECTED] > > wrote: > > > There is a "tensortdot" function in numpy1.0rc1 > > > > The tensordot is not the same thing as a tensor product. What I want > is the following: > > def tensor(a, b

Re: [Numpy-discussion] vectorized linalg

David Goldsmith wrote: > Tim Hochberg wrote: > >> I periodically need to perform various linalg operations on a large >> number of small matrices. The normal numpy approach of stacking up the >> data into an extra dimension and doing the operations in parallel >

[Numpy-discussion] vectorized linalg

I periodically need to perform various linalg operations on a large number of small matrices. The normal numpy approach of stacking up the data into an extra dimension and doing the operations in parallel doesn't work because the linalg functions are only designed to work on one matrix at a ti

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Travis Oliphant wrote: > Sven Schreiber wrote: > > >>> This is user adjustable. You change the error mode to raise on >>> 'invalid' instead of pass silently which is now the default. >>> >>> -Travis >>> >>> >>> >>> >> Could you please explain how this adjustment is done, or point to

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Travis Oliphant wrote: > Tim Hochberg wrote: > > >> With python 2.5 out now, perhaps it's time to come up with a with >> statement context manager. Something like: >> >>from __future__ import with_statement >>import numpy >> >>

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Greg Willden wrote: > On 10/11/06, *Travis Oliphant* <[EMAIL PROTECTED] > > wrote: > > Stefan van der Walt wrote: > >Further, if I understand correctly, changing sqrt and power to give > >the right answer by default will slow things down somewhat. But > i

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Mark Bakker wrote: > My vote is for consistency in numpy. > But it is unclear what consistency is. > > What is truly confusing for newbie Python users (and a source for > error even after 5 years of Python programming) is that > > >>> 2/3 > 0 I recommend that you slap "from __future__ import divis

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Travis Oliphant wrote: > Travis Oliphant wrote: > >> Now, it would be possible to give ufuncs a dtype keyword argument that >> allowed you to specify which underlying loop was to be used for the >> calculation. That way you wouldn't have to convert inputs to complex >> numbers before calling

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Travis Oliphant wrote: >> Personally I think that the default error mode should be tightened >> up. >> Then people would only see these sort of things if they really care >> about them. Using Python 2.5 and the errstate class I posted earlier: >> >> # This is what I like for

Re: [Numpy-discussion] Please test the SVN branch

Travis Oliphant wrote: > I made some fixes to the "asbuffer" code which let me feel better about > exposing it in NumPy (where it is now named int_asbuffer). > > This code takes a Python integer and a size and returns a buffer object > that points to that memory. A little test is performed by tr

[Numpy-discussion] multiarray tests skipped under py2.5

Is any one else seeing the multiarray tests all get skipped because of an import error when compiling under python 2.5. Everything else seems to work and all the tests go fine under 2.4. -tim - Using Tomcat but need to do

Re: [Numpy-discussion] multiarray tests skipped under py2.5

Gerard Vermeulen wrote: > On Thu, 12 Oct 2006 11:04:55 -0700 > Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >> Is any one else seeing the multiarray tests all get skipped because of >> an import error when compiling under python 2.5. Everything else seems >&g

Re: [Numpy-discussion] multiarray tests skipped under py2.5

Tim Hochberg wrote: > Gerard Vermeulen wrote: > >> On Thu, 12 Oct 2006 11:04:55 -0700 >> Tim Hochberg <[EMAIL PROTECTED]> wrote: >> >> >> >>> Is any one else seeing the multiarray tests all get skipped because of >>> an i

[Numpy-discussion] More SVN testing

I just checked in a couple of changes to SVN. I was going to check in errstate, but it looks like Travis beat me to it, so I contented myself with adding a docstring and some tests. These tests are only run under 2.5; things seem to work fine here, but if someone on a Linux box whose running

Re: [Numpy-discussion] multiarray tests skipped under py2.5

Travis Oliphant wrote: > Tim Hochberg wrote: > > >>> >>> >>> >>> >> Still there with a clean checkout. Blech! I hate weird import problems. >> I'll try to look into it, but if anyone has any good ideas, let me kno

Re: [Numpy-discussion] More SVN testing

Albert Strasheim wrote: > Hello all > > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:numpy- >> [EMAIL PROTECTED] On Behalf Of Tim Hochberg >> Sent: 12 October 2006 21:24 >> To: numpy-discussion >> Subject: [Numpy-discussion]

Re: [Numpy-discussion] How to make sqrt(-1) be 1j

Bill Baxter wrote: > On 10/12/06, Stefan van der Walt <[EMAIL PROTECTED]> wrote: > >> On Thu, Oct 12, 2006 at 08:58:21AM -0500, Greg Willden wrote: >> >>> On 10/11/06, Bill Baxter <[EMAIL PROTECTED]> wrote: >>> >> I tried to explain the argument at >> >> http://www.scipy.org/Negative

Re: [Numpy-discussion] How to make sqrt(-1) be 1j

Bill Baxter wrote: > > I think efficiency is not a very good argument for the default > behavior here, because -- lets face it -- if efficient execution was > high on your priority list, you wouldn't be using python. I care very much about efficiency where it matters, which is only in a tiny fra

Re: [Numpy-discussion] How to make sqrt(-1) be 1j

Bill Baxter wrote: > On 10/13/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > >> For this sort of thing, I >> would just make a new module to pull together the function I want and >> use that instead. It's then easy to explain that this new module bbeconf >&g

Re: [Numpy-discussion] Polyfit

Greg Willden wrote: > On 10/13/06, *A. M. Archibald* <[EMAIL PROTECTED] > > wrote: > > At this point you might as well use a polynomial class that can > accomodate a variety of bases for the space of polynomials - X^n, > (X-a)^n, orthogonal polynomials (transl

Re: [Numpy-discussion] rcond in polyfit

Charles R Harris wrote: > > > On 10/13/06, *A. M. Archibald* <[EMAIL PROTECTED] > > wrote: > > On 12/10/06, Charles R Harris <[EMAIL PROTECTED] > > wrote: > > Hi all, > > > > I note that polyfit looks like it should work for s

Re: [Numpy-discussion] rcond in polyfit

Charles R Harris wrote: > > > On 10/14/06, *A. M. Archibald* <[EMAIL PROTECTED] > > wrote: [SNIP] > > > Hmmm, I wonder if we have a dictionary of precisions indexed by dtype > somewhere? Here's some code I stole from somewhere for computing EPS. It would easy enough to

Re: [Numpy-discussion] Usage of NotImplemented in Numexpr

Ivan Vilata i Balaguer wrote: > Looking at the ``ophelper()`` decorator in the ``expressions`` module of > Numexpr, I see the following code is used to check/replace arguments of > operators:: > > for i, x in enumerate(args): > if isConstant(x): > args[i] = x = ConstantNode(

Re: [Numpy-discussion] Usage of NotImplemented in Numexpr

Ivan Vilata i Balaguer wrote: > En/na Tim Hochberg ha escrit:: > > >> Ivan Vilata i Balaguer wrote: >> >>> for i, x in enumerate(args): >>> if isConstant(x): >>> args[i] = ConstantNode(x) >>> elif

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

One thing that may be confusing the issue is that, as I understand it, FORTRAN and CONTIGUOUS together represent three states which I'll call FORTRAN_ORDER, C_ORDER and DISCONTIGUOUS. I periodically wonder if it would be valuable to have a way to query the order directly: the result would be "

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

Charles R Harris wrote: [SNIP] > > I'm not talking about the keyword in the ravel call, I'm talking about > the flag in a. The question is: do we *need* a fortran flag. I am > argueing not, because the only need is for fortran contiguous arrays > to pass to fortran function, or translation from

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

Charles R Harris wrote: > > > On 10/18/06, *Tim Hochberg* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Charles R Harris wrote: > > [SNIP] > > > > I'm not talking about the keyword in the ravel call, I'm talk

Re: [Numpy-discussion] histogram complete makeover

My $0.02: If histogram is going to get a makeover, particularly one that makes it more complex than at present, it should probably be moved to SciPy. Failing that, it should be moved to a submodule of numpy with similar statistical tools. Preferably with consistent interfaces for all of the f

Re: [Numpy-discussion] Unit test error with numpy rc3

Rudolph van der Merwe wrote: > I get the following error with RC3 on a RHE Linux box: > > Python 2.4.3 (#4, Mar 31 2006, 12:12:43) > [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > import numpy numpy.__version_

Re: [Numpy-discussion] Unit test error with numpy rc3

Travis Oliphant wrote: > Tim Hochberg wrote: > >> Rudolph van der Merwe wrote: >> >> >>> I get the following error with RC3 on a RHE Linux box: >>> >>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43) >>> [GCC 3.4.5 20051201 (Red Ha

Re: [Numpy-discussion] Unit test error with numpy rc3

Travis Oliphant wrote: > Tim Hochberg wrote: > >> Rudolph van der Merwe wrote: >> >> >>> I get the following error with RC3 on a RHE Linux box: >>> >>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43) >>> [GCC 3.4.5 20051201 (Red Ha

Re: [Numpy-discussion] Unit test error with numpy rc3

Travis Oliphant wrote: > Tim Hochberg wrote: > > >> Travis Oliphant wrote: >> >> >> >>> Tim Hochberg wrote: >>> >>> >>> >>> >>>> Rudolph van der Merwe wrote: >>>>

Re: [Numpy-discussion] Dimension reduction

Robert Kern wrote: > David Huard wrote: > >> Hi, >> >> Is there an elegant way to reduce an array but conserve the reduced >> dimension ? >> >> Currently, >> >>> a = random.random((10,10,10)) >> >>> a.sum(1).shape >> (10,10) >> >> but i'd like to keep (10,1,10) so I can do a/a.sum(1) directly

Re: [Numpy-discussion] Unit test error with numpy rc3

[CHOP] OK, I've checked in changes to suppress all the warnings in the test suite. I tried to be as targeted as possible so that any regressions from the current state in terms of warnings should show up. I suspect that there may be some issues with regards to masked arrays issuing spurious w

Re: [Numpy-discussion] adding an attribute to an nd-array

Christopher Barker wrote: > Travis Oliphant wrote: > >> Actually something as simple as >> >> class InfoArray(N.ndarray): >> pass >> >> will allow you to add attributes to InfoArray. >> > > Well, sure, but how the heck do you initialize it? > > >>> class InfoArray(N.ndarray): > ..

Re: [Numpy-discussion] Numpy-scalars vs Numpy 0-d arrays: copy or not copy?

Francesc Altet wrote: > A Divendres 20 Octubre 2006 11:42, Sebastien Bardeau va escriure: > [snip] > >> I can understand that numpy.scalars do not provide inplace operations >> (like Python standard scalars, they are immutable), so I'd like to use >> >> 0-d Numpy.ndarrays. But: >> >>> d = numpy

Re: [Numpy-discussion] Numpy-scalars vs Numpy 0-d arrays: copy or not copy?

Sebastien Bardeau wrote: > Ooops sorry there was two mistakes with the 'hasslice' flag. This seems > now to work for me. > > [SNIP code] That looks overly complicated. I believe that this (minimally tested in a slightly different setting) or some variation should work: return self[...,newaxi

Re: [Numpy-discussion] Problem introduced after 1.0rc2 on AIX with xlc

Brian Granger wrote: > Hi, > > i am running numpy on aix compiling with xlc. Revision 1.0rc2 works > fine and passes all tests. But 1.0rc3 and more recent give the > following on import: > > Warning: invalid value encountered in multiply > Warning: invalid value encountered in multiply > Warning:

Re: [Numpy-discussion] Problem introduced after 1.0rc2 on AIX with xlc

Brian Granger wrote: > Also, when I use seterr(all='ignore') the the tests fail: > > == > FAIL: Ticket #112 > -- > Traceback (most recent call last): > File > "

Re: [Numpy-discussion] Problem introduced after 1.0rc2 on AIX with xlc

Brian Granger wrote: > When I set seterr(all='warn') I see the following: > > In [1]: import numpy > /usr/common/homes/g/granger/usr/local/lib/python/numpy/lib/ufunclike.py:46: > RuntimeWarning: invalid value encountered in log > _log2 = umath.log(2) > /usr/common/homes/g/granger/usr/local/lib/py

Re: [Numpy-discussion] Problem introduced after 1.0rc2 on AIX with xlc

you could actually use the warnings code, but it may be a pain in the neck unless you can find some place to steal the relevant code from. -tim > thanks > > Brian > > > > On 10/20/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > >> Brian G

Re: [Numpy-discussion] Random integers

Albert Strasheim wrote: > Hello all > > I'm trying to generate random 32-bit integers. None of the following seem to > do the trick with NumPy 1.0.dev3383: > > In [32]: N.random.randint(-2**31, 2**31-1) > ValueError: low >= high > > In [43]: N.random.random_integers(-2**31, 2**31-1) > OverflowError

Re: [Numpy-discussion] Converting bool to float

Travis Oliphant wrote: > Robert Kern wrote: > > >> Travis Oliphant wrote: >> >> >> >> >>> It looks like 1.0-x is doing the right thing. >>> >>> The problem is 1.0*x for matrices is going to float64. For arrays it >>> returns float32 just like the 1.0-x >>> >>> >>> >> Why is t

Re: [Numpy-discussion] Compressed index sets, generators and iterators

A. M. Archibald wrote: > On 01/11/06, Bill Baxter <[EMAIL PROTECTED]> wrote: > > >> What's the reason iterators are not supported currently? >> For instance A[range(0,4)] works for a 1d A, but A[xrange(0,4)] does not. >> Are iterators just too inefficient to bother with? >> > > If you want

Re: [Numpy-discussion] Converting bool to float

Travis Oliphant wrote: > Robert Kern wrote: > > >> Tim Hochberg wrote: >> >> >> >>> Travis Oliphant wrote: >>> >>> >>> >>>> Robert Kern wrote: >>>> >>>> >>>&

Re: [Numpy-discussion] numpy.repeat TypeError: array cannot be safely cast to required type

George Sakkis wrote: > Can anyone explain this ? > > import numpy as N x = N.arange(1,6,dtype='B') x > array([1, 2, 3, 4, 5], dtype=uint8) > N.repeat(x, N.ones(5,'H')) > array([1, 2, 3, 4, 5], dtype=uint8) > N.repeat(x, N.ones(5,'l')) >>

Re: [Numpy-discussion] numpy.repeat TypeError: array cannot be safely cast to required type

George Sakkis wrote: > Tim Hochberg wrote: > > >> George Sakkis wrote: >> >>> Can anyone explain this ? >>> >>> >>> >>>>>> import numpy as N >>>>>> x = N.arange(1,6,dtype='B') >

Re: [Numpy-discussion] Style - was Re: numpy.repeat TypeError: array cannot be safely cast to required type

Colin J. Williams wrote: > Tim Hochberg wrote: > [snip] > >> A style note: please use the named dtypes (int32, uint32, etc) rather >> than the old-style letter codes; the former is much clearer. The answer >> to your question might have been immediately apparent h

Re: [Numpy-discussion] More on Numexpr-unsupported objects

Ivan Vilata i Balaguer wrote: [SNIP] > > Though I admit it may be strange for this error to be triggered. > > (I had a little mess with using ``expressions.ExpressionNode`` instead > of ``expr.ExpressionNode``... I still don't see why the private copy of > the module is necessary.) > > It's a

Re: [Numpy-discussion] A reimplementation of MaskedArray

A. M. Archibald wrote: > On 08/11/06, Pierre GM <[EMAIL PROTECTED]> wrote: > > >> I like your idea, but not its implementation. If MA.masked_singleton is >> defined as an object, as you suggest, then the dtype of the ndarray it is >> passed to becomes 'object', as you pointed out, and that is no

Re: [Numpy-discussion] A reimplementation of MaskedArray

A. M. Archibald wrote: > On 08/11/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >> It has always been my experience (on various flavors or Pentium) that >> operating on NANs is extremely slow. Does anyone know on what hardware >> NANs are *not* slow? Of c

Re: [Numpy-discussion] Int32s, scalar operations and Pyhon longs

Robert Kern wrote: > Fernando Perez wrote: > >> I understand why this happens, but I wonder if it should be in any way >> 'fixed' (if that is even feasible without introducing other problems): >> >> In [28]: x = 99 >> >> In [29]: y = numpy.array([x]) >> >> In [30]: z = y[0] >> >> In [31]: x=

Re: [Numpy-discussion] A reimplementation of MaskedArray

Christopher Barker wrote: > Tim Hochberg wrote: > >> I've been told that operations on NANs are slow because they aren't >> always implemented in the FPU hardware. Instead they are trapped and >> implemented software or firmware or something or other. &g

Re: [Numpy-discussion] x.min() depends on ordering

Robert Kern wrote: > Keith Goodman wrote: > >> x.min() and x.max() depend on the ordering of the elements: >> >> x = M.matrix([[ M.nan, 2.0, 1.0]]) x.min() >> nan >> >> x = M.matrix([[ 1.0, 2.0, M.nan]]) x.min() >> 1.0 >> >> If I were to

Re: [Numpy-discussion] x.min() depends on ordering

Robert Kern wrote: > Keith Goodman wrote: > >> How about a nanmin() function? >> > > Already there. > > In [2]: nanmin? > Type: function > Base Class: > Namespace: Interactive > File: > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1

Re: [Numpy-discussion] x.min() depends on ordering

Charles R Harris wrote: > > > On 11/11/06, *Tim Hochberg* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Robert Kern wrote: > > Keith Goodman wrote: > > > >> How about a nanmin() function? > >> &

Re: [Numpy-discussion] Equivalent to list.index ?

George Sakkis wrote: > def index(a, value): > return N.where(a==value)[0][0] > Or def index(a, value): return argmax(a == value) > This works but seems clunky and less efficient than necessary. If there > isn't a better alternative, I would welcome a new index() > function/method in t

Re: [Numpy-discussion] array from list of lists

Erin Sheldon wrote: > On 11/12/06, Erin Sheldon <[EMAIL PROTECTED]> wrote: > >> On 11/12/06, Pierre GM <[EMAIL PROTECTED]> wrote: >> >>> You could try the fromarrays function of numpy.core.records >>> >>> >> mydescriptor = {'names': (a','b','c','d'), 'formats':('f4', 'f4', 'f4',

Re: [Numpy-discussion] Equivalent to list.index ?

George Sakkis wrote: > Tim Hochberg wrote: > > >> George Sakkis wrote: >> >>> def index(a, value): >>> return N.where(a==value)[0][0] >>> >>> >> Or >> >> def index(a, value): >> return arg

  1   2   >