Re: [Numpy-discussion] array copy-to-self and views

On 01/02/07, Zachary Pincus <[EMAIL PROTECTED]> wrote: > I recently was trying to write code to modify an array in-place (so > as not to invalidate any references to that array) via the standard > python idiom for lists, e.g.: You can do this, but if your concern is invalidating references, you m

Re: [Numpy-discussion] Vectorizing a class method

On 14/02/07, Wojciech Śmigaj <[EMAIL PROTECTED]> wrote: > Timothy Hochberg wrote: > > On 2/14/07, *Wojciech Śmigaj* <[EMAIL PROTECTED] > > > wrote: > >> I have a question about the vectorize function. I'd like to use it to > >> create a vectorized version of a clas

Re: [Numpy-discussion] Managing Rolling Data

On 21/02/07, Alexander Michael <[EMAIL PROTECTED]> wrote: > I'm new to numpy and looking for advice on setting up and managing > array data for my particular problem. I'm collecting observations of P > properties for N objects over a rolling horizon of H sample times. I > could conceptually store t

Re: [Numpy-discussion] what goes wrong with cos(), sin()

On 21/02/07, WolfgangZillig <[EMAIL PROTECTED]> wrote: > Hi, > > I'm quite new to numpy/scipy so please excuse if my problem is too obvious. > > example code: > > import numpy as n > print n.sin(n.pi) > print n.cos(n.pi/2.0) > > results in: > 1.22460635382e-016 > 6.12303176911e-017 > > I've expecte

Re: [Numpy-discussion] what goes wrong with cos(), sin()

On 21/02/07, Zachary Pincus <[EMAIL PROTECTED]> wrote: > A corrolary: in general do not two floating-point values for equality > -- use something like numpy.allclose. (Exception -- equality is > expected if the exact sequence of operations to generate two numbers > were identical.) I really can't

Re: [Numpy-discussion] Managing Rolling Data

On 21/02/07, Alexander Michael <[EMAIL PROTECTED]> wrote: > On 2/21/07, Mike Ressler <[EMAIL PROTECTED]> wrote: > > Would loading your data via memmap, then slicing it, do your job > > (using numpy.memmap)? ... > > Interesting idea. I think Anne's suggestion that sliced assignment > will reduce to

Re: [Numpy-discussion] what goes wrong with cos(), sin()

On 21/02/07, Robert Kern <[EMAIL PROTECTED]> wrote: > Well, you can always use long double if it is implemented on your platform. > You > will have to construct a value for π yourself, though. I'm afraid that we > don't > really make that easy. If the trig functions are implemented at all, you

Re: [Numpy-discussion] Managing Rolling Data

On 23/02/07, Alexander Michael <[EMAIL PROTECTED]> wrote: > I still find the ring buffer solution appealing, but I did not see a > way to stack two arrays together without creating copies. Am I missing > a bit of numpy cleverness? The short answer is no; the stride in memory from one element to t

Re: [Numpy-discussion] Buffer Interface for Python 3.0

On 27/02/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Basically, what we are going to do now is > > 1) Return the data-format specification in an extended struct-style string > 2) Return the shape information in a tuple of lists: (shape, strides) > > There are two questions I'm grappling with

Re: [Numpy-discussion] Draft PEP for the new buffer interface to be in Python 3000

On 27/02/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > The problem is that we aren't really specifying floating-point > standards, we are specifying float, double and long double as whatever > the compiler understands. > > There are some platforms which don't follow the IEEE 754 standard. > Thi

Re: [Numpy-discussion] In-place fancy selection

On 01/03/07, Francesc Altet <[EMAIL PROTECTED]> wrote: Hi, I don't think there is a solution for this, but perhaps anybody may offer some idea. Given: In [79]:a=numpy.arange(9,-1,-1) In [80]:b=numpy.arange(10) In [81]:numpy.random.shuffle(b) In [82]:b Out[82]:array([2, 6, 3, 5, 4, 9, 0, 8, 7, 1

Re: [Numpy-discussion] in place random generation

On 07/03/07, Daniel Mahler <[EMAIL PROTECTED]> wrote: > My problem is not space, but time. > I am creating a small array over and over, > and this is turning out to be a bottleneck. > My experiments suggest that problem is the allocation, > not the random number generation. > Allocating all the arr

Re: [Numpy-discussion] in place random generation

On 08/03/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > For normals this seems overkill as the same result can be achieved by an > offset and scale, i.e., if r is an array of random numbers with mean 0 and > sigma 1, then > > myrandomarray = (r*mysigma + mymean) > > easily achieves the same res

Re: [Numpy-discussion] in place random generation

On 09/03/07, Robert Kern <[EMAIL PROTECTED]> wrote: > Mark P. Miller wrote: > > As an aside, are the random number generators from scipy.random the same > > as those for numpy.random? If not, will those of us who need to just > > use a few random numbers here and there throughout our code (we don'

Re: [Numpy-discussion] zoom FFT with numpy?

On 15/03/07, Ray Schumacher <[EMAIL PROTECTED]> wrote: > The desired band is rather narrow, as the goal is to determine the f of a > peak that always occurs in a narrow band of about 1kHz around 7kHz > > >2) frequency shift, {low pass}, and downsample By this I would take it to mean, multiply by

Re: [Numpy-discussion] Array of Callables

On 21/03/07, Andrew Corrigan <[EMAIL PROTECTED]> wrote: > This is a feature I've been wanting for a long time, so I'm really glad that > Shane brought this up. > > While I was hoping for a gain in speed, that isn't the only reason that I > would > like to see this added. In fact, the most compel

Re: [Numpy-discussion] Array of Callables

On 21/03/07, Andrew Corrigan <[EMAIL PROTECTED]> wrote: > Thanks for pointing that out. Technically that works, but it doesn't really > express this operation as concisely and as naturally as I'd like to be able > to. > > What I really want is to be able to write: > > >>> a = array([lambda x: x**

Re: [Numpy-discussion] nd_image.affine_transform edge effects

On 22/03/07, James Turner <[EMAIL PROTECTED]> wrote: > So, its not really a bug, its a undesired feature... It is curable, though painful - you can pad the image out, given an estimate of the size of the window. Yes, this sucks. Anne. ___ Numpy-discuss

Re: [Numpy-discussion] Simple multi-arg wrapper for dot()

On 24/03/07, Bill Baxter <[EMAIL PROTECTED]> wrote: > I mentioned in another thread Travis started on the scipy list that I > would find it useful if there were a function like dot() that could > multiply more than just two things. > > Here's a sample implementation called 'mdot'. > > mdot(a,b,c,d)

Re: [Numpy-discussion] Detect subclass of ndarray

On 23/03/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > Anyone, > > What is the easiest way to detect in python/C if an object is a subclass of > ndarray? Um, how about isinstance or issubclass? (if you want strictness you can look at whether x.__class__ is zeros(1).__class__) Anne ___

Re: [Numpy-discussion] Simple multi-arg wrapper for dot()

On 24/03/07, Bill Baxter <[EMAIL PROTECTED]> wrote: > Nice, but how does that fare on things like mdot(a,(b,c),d) ? I'm > pretty sure it doesn't handle it. > I think an mdot that can only multiply things left to right comes up > short compared to an infix operator that can easily use parentheses

Re: [Numpy-discussion] Detect subclass of ndarray

On 24/03/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > My opinion is that a 1-d array in matrix-multiplication should always be > interpreted as a row vector. Is this not what is currently done? If > not, then it is a bug in my mind. An alternative approach, in line with the usual usage, is

Re: [Numpy-discussion] New Operators in Python

On 24/03/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > Yes indeed, this is an old complaint. Just having an infix operator would be > an improvement: > > A dot B dot C > > Not that I am suggesting dot in this regard ;) In particular, it wouldn't > parse without spaces. What about division? Mat

[Numpy-discussion] vectorized methods

Hi, What is the current idiom for vectorizing instance methods? I don't need vectorization over self. For functions: from numpy import * @vectorize def f(x): if x>0: return 1 else: return 2 print f(array([-1,0,1])) does the right thing. But for instance methods: class u

Re: [Numpy-discussion] .data doesn't account for .transpose()?

On 29/03/07, Robert Kern <[EMAIL PROTECTED]> wrote: > Glen W. Mabey wrote: > > > So, would that imply that a .copy() should be done first on any array > > that you want to access .data on? > > Or even ascontiguousarray(). I'd like to point out that the numpy usage of the word "contiguous" is a bit

Re: [Numpy-discussion] newbie question - large dataset

On 07/04/07, Steve Staneff <[EMAIL PROTECTED]> wrote: Hi, I'm looking for a better solution to managing a very large calculation. Set A is composed of tuples a, each of the form a = [float, string]; set B is composed of tuples of similar structure (b = [float, string]). For each possible combin

[Numpy-discussion] degree to which numpy releases threads

On 07/04/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > You are correct. If g,h in the OP's description satisfy: > > a) they are bloody expensive > > b) they release the GIL internally via the proper C API calls, which > means they are promising not to modify any shared python objects > > the pu

Re: [Numpy-discussion] detecting shared data

On 11/04/07, Bill Baxter <[EMAIL PROTECTED]> wrote: Must be pretty recent. I'm using 1.0.2.dev3520 (enthought egg) and the function's not there. It is. I've never been quite happy with it, though; I realize it's not very feasible to write one that efficiently checks all possible overlaps, bu

Re: [Numpy-discussion] detecting shared data

On 12/04/07, Stefan van der Walt <[EMAIL PROTECTED]> wrote: > Thank you for taking the time to write those tests! > > Failures may be expressed using > > NumpyTestCase.failIf(self, expr, msg=None) That's not quite what I mean. There are situations, with the current code, that it gets the answer w

Re: [Numpy-discussion] Question about Optimization (Inline and Pyrex)

On 17/04/07, Lou Pecora <[EMAIL PROTECTED]> wrote: > You should probably look over your code and see if you > can eliminate loops by using the built in > vectorization of NumPy. I've found this can really > speed things up. E.g. given element by element > multiplication of two n-dimensional array

Re: [Numpy-discussion] Question about Optimization (Inline and Pyrex)

On 17/04/07, Francesc Altet <[EMAIL PROTECTED]> wrote: > Finally, don't let benchmarks fool you. If you can, it is always better > to run your own benchmarks made of your own problems. A tool that can be > killer for one application can be just mediocre for another (that's > somewhat extreme, but

Re: [Numpy-discussion] Question about Optimization (Inline and Pyrex)

On 17/04/07, Lou Pecora <[EMAIL PROTECTED]> wrote: > Now, I didn't know that. That's cool because I have a > new dual core Intel Mac Pro. I see I have some > learning to do with multithreading. Thanks. No problem. I had completely forgotten about the global interpreter lock, wrote a little mult

Re: [Numpy-discussion] Question about Optimization (Inline and Pyrex)

On 17/04/07, Lou Pecora <[EMAIL PROTECTED]> wrote: I get what you are saying, but I'm not even at the Stupidly Easy Parallel level, yet. Eventually. Well, it's hardly wonderful, but I wrote a little package to make idioms like: d = {} def work(f): d[f] = sum(exp(2.j*pi*f*times)) foreach(wo

Re: [Numpy-discussion] Question about Optimization (Inline, and Pyrex)

On 17/04/07, James Turner <[EMAIL PROTECTED]> wrote: > Hi Anne, > > Your reply to Lou raises a naive follow-up question of my own... > > > Normally, python's multithreading is effectively cooperative, because > > the interpreter's data structures are all stored under the same lock, > > so only one

Re: [Numpy-discussion] Question about Optimization (Inline, and Pyrex)

On 18/04/07, Robert Kern <[EMAIL PROTECTED]> wrote: > Sebastian Haase wrote: > > > Hi, > > I don't know much about ATLAS -- would there be other numpy functions > > that *could* or *should* be implemented using ATLAS !? > > Any ? > > Not really, no. ATLAS is a library designed to implement linea

Re: [Numpy-discussion] Question about Optimization (Inline and Pyrex)

On 18/04/07, Sebastian Haase <[EMAIL PROTECTED]> wrote: > Hi Anne, > I'm just starting to look into your code (sound very interesting - > should probably be put onto the wiki) > -- quick note: > you are mixing tabs and spaces :-( > what editor are you using !? Agh. vim is misbehaving. Sorry abou

Re: [Numpy-discussion] efficient use of numpy.where() and .any()

On 23/04/07, Pierre GM <[EMAIL PROTECTED]> wrote: > Have you tried nonzero() ? > > a[a<0] = numpy.random.normal(0,1) > > will put a random number from the normal distribution where your initial a is > negative. No Python loops needed, no Python temps. When you say "no python temps" I guess you me

Re: [Numpy-discussion] efficient use of numpy.where() and .any()

On 23/04/07, Pierre GM <[EMAIL PROTECTED]> wrote: > Note that in addition of the bitwise operators, you can use the "logical_" > functions. OK, you'll still end up w/ temporaries, but I wonder whether there > couldn't be some tricks to bypass that... If you're really determined not to make many t

Re: [Numpy-discussion] Inplace reshape

On 23/04/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > Hi, > > I thought I remembered there was a way to reshape in-place an array, but > neither google, nor greping my mailbox brings anything out. > Am I wrong, or is there indeed a way to reshape in-place an array ? Sometimes it's just impossib

Re: [Numpy-discussion] matlab vs. python question

On 25/04/07, Sturla Molden <[EMAIL PROTECTED]> wrote: > You have to realize that Matlab is mainly used by people who are not > skilled programmers but scientists and engineers, the majority of which > have never used anything else except perhaps Fortran 77. An array is the > most advanced data str

Re: [Numpy-discussion] sort bug

On 26/04/07, Anton Sherwood <[EMAIL PROTECTED]> wrote: > All I really need is the four highest eigenvalues and their vectors. It's not really very efficient, but sorting time is going to be tiny compared to however you get your eigenvalues, so you could argsort the eigenvalue array and use the re

Re: [Numpy-discussion] arctan2 with complex args

On 29/04/07, David Goldsmith <[EMAIL PROTECTED]> wrote: > Far be it from me to challenge the mighty Wolfram, but I'm not sure that > using the *formula* for calculating the arctan of a *single* complex > argument from its real and imaginary parts makes any sense if x and/or y > are themselves compl

Re: [Numpy-discussion] matlab vs. python question

On 08/05/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Tue, May 08, 2007 at 12:18:56PM +0200, Giorgio Luciano wrote: > > A good workspace (with an interactive button) just to not get figures > > freezed > > I am not sure what you mean by "figures freezed" but I would like to > check that you a

Re: [Numpy-discussion] numpy version of Interactive Data Analysis tutorial available

On 10/05/07, Perry Greenfield <[EMAIL PROTECTED]> wrote: > I have updated the "Using Python for Interactive Data Analysis" > tutorial to use numpy instead of numarray (finally!). There are > further improvements I would like to make in its organization and > formatting (in the process including sug

Re: [Numpy-discussion] very large matrices.

On 12/05/07, Dave P. Novakovic <[EMAIL PROTECTED]> wrote: > core 2 duo with 4gb RAM. > > I've heard about iterative svd functions. I actually need a complete > svd, with all eigenvalues (not LSI). I'm actually more interested in > the individual eigenvectors. > > As an example, a single row could

[Numpy-discussion] Unfortunate user experience with max()

Hi, Numpy has a max() function. It takes an array, and possibly some extra arguments (axis and default). Unfortunately, this means that >>> numpy.max(-1.3,2,7) -1.3 This can lead to surprising bugs in code that either explicitly expects it to behave like python's max() or implicitly expects that

Re: [Numpy-discussion] Unfortunate user experience with max()

On 16/05/07, Alan G Isaac <[EMAIL PROTECTED]> wrote: > On Wed, 16 May 2007, Anne Archibald apparently wrote: > >>>> numpy.max(-1.3,2,7) > > -1.3 > > Is that new behavior? > I get a TypeError on the last argument. > (As expected.) For which version of

Re: [Numpy-discussion] best way for storing extensible data?

On 18/05/07, David M. Cooke <[EMAIL PROTECTED]> wrote: > It'll act like appending to a list, where it will grow the array (by > doubling, I think) when it needs to, so appending each value is > amortized to O(1) time. A list though would use more memory > per element as each element is a full Pyth

Re: [Numpy-discussion] Question about flags of fancy indexed array

On 23/05/07, Albert Strasheim <[EMAIL PROTECTED]> wrote: > Consider the following example: First a comment: almost nobody needs to care how the data is stored internally. Try to avoid looking at the flags unless you're interfacing with a C library. The nice feature of numpy is that it hides all t

Re: [Numpy-discussion] Question about flags of fancy indexed array

On 23/05/07, Albert Strasheim <[EMAIL PROTECTED]> wrote: > If you are correct that this is in fact a fresh new array, I really > don't understand where the values of these flags. To recap: > > In [19]: x = N.zeros((3,2)) > > In [20]: x.flags > Out[20]: > C_CONTIGUOUS : True > F_CONTIGUOUS : Fa

Re: [Numpy-discussion] Single-Precision FFT

On 24/05/07, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > I know that FFTW can be compiled to run in single precision. What would it > take > to make NumPy use a single-precision FFT library? > > If absolutely necessary, it might be possible to ship a patched version of > NumPy, but any oth

Re: [Numpy-discussion] byteswap() leaves dtype unchanged

On 30/05/07, Matthew Brett <[EMAIL PROTECTED]> wrote: > I think the point is that you can have several different situations > with byte ordering: > > 1) Your data and dtype endianess match, but you want the data swapped > and the dtype to reflect this > > 2) Your data and dtype endianess don't mat

Re: [Numpy-discussion] SciPy Journal

On 31/05/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > 2) I think it's scope should be limited to papers that describe > algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we > could also accept papers that describe code that depends on NumPy / > SciPy that is also easily availa

Re: [Numpy-discussion] flatten() without copy - is this possible?

On 01/06/07, dmitrey <[EMAIL PROTECTED]> wrote: > y = x.flatten(1) > > turn array into vector (note that this forces a copy) > > Is there any way to do the trick wthout copying? > What are the problems here? Just other way of array elements indexing... It is sometimes possible to flatten an array

Re: [Numpy-discussion] flatten() without copy - is this possible?

On 05/06/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > > On 6/5/07, dmitrey <[EMAIL PROTECTED]> wrote: > > Thank you, but all your examples deal with 3-dimensional arrays. and I > > still misunderstood, is it possible somehow for 2-dimensional arrays or > no? > > D. > > There is nothing special

Re: [Numpy-discussion] randint for long type (permutations)

On 14/06/07, Will Woods <[EMAIL PROTECTED]> wrote: > I want to choose a subset of all possible permutations of a sequence of > length N, with each element of the subset unique. This is then going to > be scattered across multiple machines using mpi. Since there is a > one-to-one mapping between th

Re: [Numpy-discussion] fancy indexing/broadcasting question

On 07/07/07, Mark.Miller <[EMAIL PROTECTED]> wrote: > A quick question for the group. I'm working with some code to generate > some arrays of random numbers. The random numbers, however, need to > meet certain criteria. So for the moment, I have things that look like > this (code is just an abst

Re: [Numpy-discussion] expm

On 20/07/07, Nils Wagner <[EMAIL PROTECTED]> wrote: > lorenzo bolla wrote: > > hi all. > > is there a function in numpy to compute the exp of a matrix, similar > > to expm in matlab? > > for example: > > expm([[0,0],[0,0]]) = eye(2) > Numpy doesn't provide expm but scipy does. > >>> from scipy.lina

Re: [Numpy-discussion] numpy arrays, data allocation and SIMD alignement

On 04/08/07, David Cournapeau <[EMAIL PROTECTED]> wrote: > > Here's a hack that google turned up: I'd avoid hacks in favour of posix_memalign (which allows arbitrary degrees of alignment. For one thing, freeing becomes a headache (you can't free a pointer you've jiggered!). > - Check whethe

Re: [Numpy-discussion] numpy arrays, data allocation and SIMD alignement

On 06/08/07, David Cournapeau <[EMAIL PROTECTED]> wrote: > Well, when I proposed the SIMD extension, I was willing to implement the > proposal, and this was for a simple goal: enabling better integration > with many numeric libraries which need SIMD alignment. > > As nice as a custom allocator mig

Re: [Numpy-discussion] numpy arrays, data allocation and SIMD alignement

On 07/08/07, David Cournapeau <[EMAIL PROTECTED]> wrote: > Anne, you said previously that it was easy to allocate buffers for a > given alignment at runtime. Could you point me to a document which > explains how ? For platforms without posix_memalign, I don't see how to > implement a memory alloca

Re: [Numpy-discussion] numpy arrays, data allocation and SIMD alignement

On 08/08/2007, Stefan van der Walt <[EMAIL PROTECTED]> wrote: > On Tue, Aug 07, 2007 at 01:33:24AM -0400, Anne Archibald wrote: > > Well, it can be done in Python: just allocate a too-big ndarray and > > take a slice that's the right shape and has the right alignment. But

Re: [Numpy-discussion] numpy arrays, data allocation and SIMD alignement

On 08/08/2007, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > On 8/8/07, Anne Archibald <[EMAIL PROTECTED]> wrote: > > Oh. Well, it's not *terrible*; it gets you an aligned array. But you > > have to allocate the original array as a 1D byte array (to all

Re: [Numpy-discussion] vectorized function inside a class

On 08/08/2007, mark <[EMAIL PROTECTED]> wrote: > Thanks for the ideas to circumvent vectorization. > But the real function I need to vectorize is quite a bit more > complicated. > So I would really like to use vectorize. > Are there any reasons against vectorization? Is it slow? > The way Tim sugge

Re: [Numpy-discussion] .transpose() of memmap array fails to close()

On 13/08/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > As I have tried to think through what should be the appropriate > behavior for the returned value of __getitem__, I have not been able to > see an appropriate solution (let alone know how to implement it) to this > issue. Is the problem one

Re: [Numpy-discussion] .transpose() of memmap array fails to close()

On 15/08/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > On Tue, Aug 14, 2007 at 12:23:26AM -0400, Anne Archibald wrote: > > On 13/08/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > > > > > As I have tried to think through what should be the appropriate >

Re: [Numpy-discussion] .transpose() of memmap array fails to close()

On 16/08/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > On Wed, Aug 15, 2007 at 08:50:28PM -0400, Anne Archibald wrote: > > But to be pythonic, or numpythonic, when the original A is > > garbage-collected, the garbage collection should certainly close the > > mmap. &

Re: [Numpy-discussion] "Extended" Outer Product

On 21/08/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote: > This is just a general comment on recent threads of this type and not > directed specifically at Chuck or anyone else. > > IMO, the emphasis on avoiding FOR loops at all costs is misplaced. It is > often more memory friendly and thus faste

Re: [Numpy-discussion] Bug in resize method?

On 29/08/2007, Timothy Hochberg <[EMAIL PROTECTED]> wrote: > The main inconsistency I see above is that resize appears to only require > ownership of the data if in fact the number of items changes. I don't think > that's actually a bug, but I don't like it much; I would prefer that resize > be st

[Numpy-discussion] Bug or surprising undocumented behaviour in irfft

Hi, numpy's Fourier transforms have the handy feature of being able to upsample and downsample signals; for example the documentation cites irfft(rfft(A),16*len(A)) as a way to get a Fourier interpolation of A. However, there is a peculiarity with the way numpy handles the highest-frequency coeffi

Re: [Numpy-discussion] Bug or surprising undocumented behaviour in irfft

On 29/08/2007, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > What is going on is that the coefficient at the Nyquist frequency appears > once in the unextended array, but twice when the array is extended with > zeros because of the Hermitean symmetry. That should probably be fixed in > the ups

Re: [Numpy-discussion] Bug or surprising undocumented behaviour in irfft

On 29/08/2007, Charles R Harris <[EMAIL PROTECTED]> wrote: > > Is this also appropriate for the other FFTs? (inverse real, complex, > > hermitian, what have you) I have written a quick hack (attached) that > > should do just that rescaling, but I don't know that it's a good idea, > > as implemente

Re: [Numpy-discussion] Accessing a numpy array in a mmap fashion

On 30/08/2007, Brian Donovan <[EMAIL PROTECTED]> wrote: > Hello all, > > I'm wondering if there is a way to use a numpy array that uses disk as a > memory store rather than ram. I'm looking for something like mmap but which > can be used like a numpy array. The general idea is this. I'm simulatin

Re: [Numpy-discussion] Docstring improvements for numpy.where?

On 12/09/2007, Robert Kern <[EMAIL PROTECTED]> wrote: > That sentence applies to the 3-argument form, which has nothing to do with > nonzero() and does not yield a tuple. But in general, yes, the docstring > leaves > much to be desired. Well, here's what I hope is a step in the right direction.

Re: [Numpy-discussion] arange and floating point arguments

On 14/09/2007, Robert Kern <[EMAIL PROTECTED]> wrote: > Ed Schofield wrote: > > Using arange in this way is a fundamentally unreliable thing to do, > > but is there anything we want to do about this? > > Tell people to use linspace(). Yes, it does a slightly different thing; that's > why it works.

Re: [Numpy-discussion] arange and floating point arguments

On 14/09/2007, Charles R Harris <[EMAIL PROTECTED]> wrote: > Since none of the numbers are exactly represented in IEEE floating point, > this sort of oddity is expected. If you look at the exact values, (.4 + > .2)/.1 > 6 and .6/.1 < 6 . That said, I would expect something like > ceil(interval/d

Re: [Numpy-discussion] arange and floating point arguments

On 15/09/2007, Christopher Barker <[EMAIL PROTECTED]> wrote: > Oh, and could someone post an actual example of a use for which FP > arange is required (with fudges to try to accommodate decimal to binary > conversion errors), and linspace won't do? Well, here's one: evaluating a function we know

Re: [Numpy-discussion] "Extended" Outer Product

On 19/09/2007, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Anne Archibald wrote: > > vectorize, of course, is a good example of my point above: it really > > just loops, in python IIRC, but conceptually it's extremely handy for > > doing exactly what the OP

Re: [Numpy-discussion] Casting a float array into a string array

On 05/10/2007, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > I'd like to have the '2.', because if the number is negative, only '-' is > returned, not the real value. For string arrays you need to specify the length of the string as part of the data type (and it defaults to length 1): In [11]: ra

[Numpy-discussion] bug in vectorize? (was: Re: Casting a float array into a string array)

On 05/10/2007, Christopher Barker <[EMAIL PROTECTED]> wrote: > I don't know how to generalize this to n-d though -- maybe numpy.vectorize? Oops! Looks like there's a big somewhere: In [1]: from numpy import * In [2]: vectorize(lambda x: "%5.3g" % x)(ones((2,2,2))) Out[2]: array([[[' ', '\xc1'],

Re: [Numpy-discussion] appending extra items to arrays

On 11/10/2007, Robert Kern <[EMAIL PROTECTED]> wrote: > Appending to a list then converting the list to an array is the most > straightforward way to do it. If the performance of this isn't a problem, I > recommend leaving it alone. Just a speculation: Python strings have a similar problem - the

Re: [Numpy-discussion] fortran array storage question

On 26/10/2007, Georg Holzmann <[EMAIL PROTECTED]> wrote: > if in that example I also change the strides: > >int s = tmp->strides[1]; >tmp->strides[0] = s; >tmp->strides[1] = s * dim0[0]; > > Then I get in python the fortran-style array in right order. This is the usual way. More or le

Re: [Numpy-discussion] fortran array storage question

On 26/10/2007, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > There is an optimization where-in the inner-loops are done over the > dimension with the smallest stride. > > What other cache-coherent optimizations do you recommend? That sounds like a very good first step. I'm far from an expert on

Re: [Numpy-discussion] numpy FFT memory accumulation

On 31/10/2007, Ray S <[EMAIL PROTECTED]> wrote: > I am using > fftRes = abs(fft.rfft(data_array[end-2**15:end])) > to do running analysis on streaming data. The N never changes. > It sucks memory up at ~1MB/sec with 70kHz data rate and 290 ffts/sec. > (Interestingly, Numeric FFT accumulates much sl

Re: [Numpy-discussion] Numeric integration of higher order integrals

When the dimensionality gets high, grid methods like you're describing start to be a problem ("the curse of dimensionality"). The standard approaches are simple Monte Carlo integration or its refinements (Metropolis-Hasings, for example). These converge somewhat slowly, but are not much affected by

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

What a useful package! Apart from helping all the people who know they need quaternions, this package removes one major family of use cases for vectorized small-matrix operations, namely, 3D rotations. Quaternions are the canonical way to represent orientation and rotation in three dimensions, and

Re: [Numpy-discussion] Can I index array starting with 1?

Don't forget the everything-looks-like-a-nail approach: make all your arrays one bigger than you need and ignore element zero. Anne On 7/28/11, Stéfan van der Walt wrote: > Hi Jeremy > > On Thu, Jul 28, 2011 at 3:19 PM, Jeremy Conlin wrote: >> I have a need to index my array(s) starting with a

Re: [Numpy-discussion] Can I index array starting with 1?

, implementation would be pretty easy - just make a subclass of ndarray that replaces the indexing function. Anne On 28 July 2011 19:26, Derek Homeier wrote: > On 29.07.2011, at 1:19AM, Stéfan van der Walt wrote: > >> On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald >> wrote: &g

Re: [Numpy-discussion] [SciPy-User] recommendation for saving data

In astronomy we tend to use FITS, which is well-supported by pyfits, but a little limited. Some new instruments are beginning to use HDF5. All these generic formats allow very general data storage, so you will need to come up with a standrdized way to represent your own data. Used well, these form

Re: [Numpy-discussion] Efficient way to load a 1Gb file?

There was also some work on a semi-mutable array type that allowed appending along one axis, then 'freezing' to yield a normal numpy array (unfortunately I'm not sure how to find it in the mailing list archives). One could write such a setup by hand, using mmap() or realloc(), but I'd be inclined t

[Numpy-discussion] supporting quad precision

Hi folks, I recently came across an application I needed quad precision for (high-accuracy solution of a differential equation). I found a C++ library (odeint) that worked for the integration itself, but unfortunately it appears numpy is not able to work with quad precision arrays. For my applicat

Re: [Numpy-discussion] supporting quad precision

one could use a package like qd to provide portable quad precision (and quad-double). I'll take a look. Anne On Jun 5, 2013 7:10 PM, "David Cournapeau" wrote: > On Wed, Jun 5, 2013 at 5:21 PM, Charles R Harris > wrote: > > Hi Anne, > > > > Long time n

Re: [Numpy-discussion] supporting quad precision

On 9 June 2013 13:23, David Cournapeau wrote: > So it depends on the CPU, the OS and the compiler. Using long double > for anything else than compatibility (e.g. binary files) is often a > mistake IMO, and highly unportable. > Now this I have to comment on. Long double is highly questionable for

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

Do we want a deprecation-like approach, so that eventually people who want replicability will specify versions, and everyone else gets bug fixes and improvements? This would presumably take several major versions, but it might avoid people getting unintentionally trapped on this version. Incidenta

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Fri, Jun 5, 2015 at 5:45 PM Sebastian Berg wrote: > On Fr, 2015-06-05 at 08:36 -0400, josef.p...@gmail.com wrote: > > > > > > > What is actually being deprecated? > > It looks like there are different examples. > > > > > > wrong length: Nathaniels first example above, where the mask is not >

[Numpy-discussion] Development workflow (not git tutorial)

Hi, What is a sensible way to work on (modify, compile, and test) numpy? There is documentation about "contributing to numpy" at: http://docs.scipy.org/doc/numpy-dev/dev/index.html and: http://docs.scipy.org/doc/numpy-dev/dev/gitwash/development_workflow.html but these are entirely focused on usi

Re: [Numpy-discussion] Defining a white noise process using numpy

On Thu, Aug 27, 2015 at 12:51 AM Daniel Bliss wrote: Can anyone give me some advice for translating this equation into code > using numpy? > > eta(t) = lim(dt -> 0) N(0, 1/sqrt(dt)), > > where N(a, b) is a Gaussian random variable of mean a and variance b**2. > > This is a heuristic definition of

Re: [Numpy-discussion] feature request - increment counter on write check

On Fri, Sep 11, 2015 at 3:20 PM Sebastian Berg wrote: > On Fr, 2015-09-11 at 13:10 +, Daniel Manson wrote: > > Originally posted as issue 6301 on github. > > > > > > Presumably any block of code that modifies an ndarray's buffer is > > wrapped in a (thread safe?) check of the writable flag. W

Re: [Numpy-discussion] Python needs goto

goto! and comefrom! Together with exceptions, threads, lambda, super, generators, and coroutines, all we're lacking is call-with-current-continuation for the full list of impenetrable control-flow constructs. Oh, and lisp-style resumable exception handling. (Suggested syntax: drop(exception, value)

Re: [Numpy-discussion] Sign of NaN

IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point arrays. Why should it be different for object arrays? Anne P.S. If you want exceptions when NaNs appear, that's what np.seterr is for. -A On Tue, Sep 29, 2015 at 5:18 PM Freddy Rietdijk wrote: > I wouldn't know of any valid outpu

  1   2   3   4   5   >