[Numpy-discussion] Re FFTs in SciPy (and NumPy)

[Sturla Molden]

There has been some discussion on FFTPACK lately. Problems with FFTPACK 
seems to be:

- Written in old Fortran 77.
- Unprecise for single precision.
- Can sometimes be very slow, depending on input size.
- Can only handle a few small prime factors {2,3,4,5} efficiently.
- How to control integer size portably for 64-bit and f2py?
- Only 1D transforms.

There is another FFT library in cwplib from Colorado Mining School. It 
has some very nice properties:

- Written in C, not Fortran, and the FFT-part of the library is just one 
single C file.
- License is BSD it seems.
- Quite fast (see benchmarks in http://www.fftw.org/fftw-paper.pdf and 
http://www.fftw.org/speed/)
- Can handle larger set of prime factors than FFTPACK 
{2,3,4,5,7,8,9,11,13,16}.
- 1D and 2D inplace transforms.

The problem with cwplib is that it does not allow arbitrary sized FFTs. 
But til will be fast whenever FFTPACK is fast (it seems FFTPACK is only 
competitive for N=2**k case). It will also be fast for other 
factorizations where FFTPACK will fallback to O(N**2).

How to handle arbitrary sized arrays with cwplib? One possibility is 
using Bluestein's FFT algorithm, which just requires a few lines og 
Python. This was even suggested to avoid O(N**2) fallback in FFTPACK 
here a while ago. If we are going to do that for FFTPACK, the cwplib's 
FFT will actually be more flexible with respect to array size.

All in all I think it is worth looking at.

The C code is in the "Seismic U*nx" download from CWP, which is huge, 
but contains a lot of nice C library functions for scientific computing 
apart from FFTs as well (all of which are BSD licensed it seems). 
http://www.cwp.mines.edu/cwpcodes/index.html

Regards,
Sturla







 

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Here's what I've done to numpy.fft

[David Goldsmith]

2010/7/12 Jochen Schröder 

> On 13/07/10 08:47, David Goldsmith wrote:
> > In light of my various questions and the responses thereto, here's what
> > I've done (but not yet committed) to numpy.fft.
> >
> > There are many ways to define the DFT, varying in the sign of the
> > exponent, normalization, etc.  In this implementation, the DFT is defined
> > as
> >
> > .. math::
> > A_k =  \sum_{m=0}^{n-1} a_m \exp\left\{-2\pi i{mk \over n}\right\}
> > \qquad k = 0,\ldots,n-1
> >
> > where `n` is the number of input points.  In general, the DFT is defined
> > for complex inputs and outputs, and a single-frequency component at
> linear
> > frequency :math:`f` is represented by a complex exponential
> > :math:`a_m = \exp\{2\pi i\,f m\Delta t\}`, where
> > :math:`\Delta t` is the *sampling interval*.
> >
> > Note that, due to the periodicity of the exponential function, formally
> > :math:`A_{n-1} = A_{-1}, A_{n-2} = A_{-2}`, etc.  That said, the values
> in
> > the result are in the so-called "standard" order: if ``A = fft(a,n)``,
> > then ``A[0]`` contains the zero-frequency term (the sum of the data),
> > which is always purely real for real inputs.  Then ``A[1:n/2]`` contains
> > the positive-frequency terms, and ``A[n/2+1:]`` contains the
> > negative-frequency (in the sense described above) terms, from least (most
> > negative) to largest (closest to zero).  In particular, for `n` even,
> > ``A[n/2]`` represents both the positive and the negative Nyquist
> > frequencies, and is also purely real for real input.  For `n` odd,
> > ``A[(n-1)/2]`` contains the largest positive frequency, while
> > ``A[(n+1)/2]`` contains the largest (in absolute value) negative
> > frequency.  In both cases, i.e., `n` even or odd, ``A[n-1]`` contains the
> > negative frequency closest to zero.
> >
> > Feedback welcome.
> >
> > DG
> >
> Hi David,
>
> great work. I agree with Travis leave the sampling out. This make things
> more confusing. I'd also suggest pointing to fftshift for converting the
> "standard" order to order "min frequency to max frequency"
>

Thanks, Jochen.  Such a pointer was/is already in the original docstring; I
found nothing unclear about it, so I didn't modify it, so I didn't include
it in my post; indeed, the complete docstring is much longer - I only posted
that portion to which I made significant changes.  (To which I should
probably add: I haven't "picked over" the rest of the docstring w/ nearly
the same degree of care as that portion I did post, primarily because my
main motivation in doing what I did was for consistency w/ what I'm
"borrowing" from the docstring for the much more succinct narrative portion
I'm adding to the docstring for scipy.fftpack.basic.  In other words, though
numpy.fft's docstring was at "Needs review" status going into this, it
should probably be put back to "Being written.")

DG

>
> Cheers
> Jochen
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.fft, yet again

[David Goldsmith]

2010/7/12 Jochen Schröder 

> On 13/07/10 08:04, Eric Firing wrote:
> > On 07/12/2010 11:43 AM, David Goldsmith wrote:
> >>   > From the docstring:
> >>
> >> "A[0] contains the zero-frequency term (the mean of the signal)"
> >>
> >> And yet, consistent w/ the definition given in the docstring (and
> >> included w/ an earlier email), the code gives, e.g.:
> >>
> >>   >>>  import numpy as np
> >>   >>>  x = np.ones((16,)); x
> >> array([ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,
> >>   1.,  1.,  1.])
> >>   >>>  y = np.fft.fft(x); y
> >> array([ 16.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
> >>0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
> >>0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j])
> >>
> >> i.e., the zero-th term is the sum, not the mean (which, again, is
> >> consistent w/ the stated defining formula).
> >>
> >> So, same ol', same ol': bug in the doc (presumably) or bug in the code?
> >
> > Bug in the doc.  Good catch.  "mean" is correct for the ifft, not for
> > the fft.
> >
> > Eric
> >
> I'd say that a pointer to a discussion about normalization of ffts would
> be good here. The issue is that numpy is doing a normalization to len(x)
> for the inverse fft. However to make ffts unitary it should actually be
> that fft and ifft are normalized by sqrt(len(x)). And some fft
> implementations don't do normalizations at all (FFTW).
>
> Interesting comment: it made me run down the fftpack 
> tutorialjosef
>  has alluded to in the past to see if the suggested pointer could point
there without having to write a lot of new content.  What I found was that
although the scipy basic fft functions don't support it (presumably because
they're basically just wrappers for the numpy fft functions), scipy's
discrete cosine transforms support an "norm=ortho" keyword argument/value
pair that enables the function to return the unitary versions that you
describe above.  There isn't much narrative explanation of the issue yet,
but it got me wondering: why don't the fft functions support this?  If there
isn't a "good" reason, I'll go ahead and submit an enhancement ticket.

DG

> Cheers
> Jochen
>
> >>
> >> DG
> >>
> >>
> >>
> >> ___
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion@scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] match or vectorized in-type function.

[Zachary Pincus]

> match(v1, v2) => returns a boolean array of length len(v1) indicating
> whether element i in v1 is in v2.

You want numpy.in1d (and friends, probably, like numpy.unique and the  
others that are all collected in numpy.lib.arraysetops...)


Definition:   numpy.in1d(ar1, ar2, assume_unique=False)
Docstring:
 Test whether each element of a 1D array is also present in a  
second array.

 Returns a boolean array the same length as `ar1` that is True
 where an element of `ar1` is in `ar2` and False otherwise.

 Parameters
 --
 ar1 : array_like, shape (M,)
 Input array.
 ar2 : array_like
 The values against which to test each value of `ar1`.
 assume_unique : bool, optional
 If True, the input arrays are both assumed to be unique, which
 can speed up the calculation.  Default is False.

 Returns
 ---
 mask : ndarray of bools, shape(M,)
 The values `ar1[mask]` are in `ar2`.

 See Also
 
 numpy.lib.arraysetops : Module with a number of other functions for
 performing set operations on arrays.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] match or vectorized in-type function.

[James Bullard]

I have two vectors of integers of not necessarily the same length.
Consider the hypothetical function match (or if you are familiar to R
then consider that function). 

match(v1, v2) => returns a boolean array of length len(v1) indicating
whether element i in v1 is in v2. 

I cannot find this function in numpy. I would assume a variant is there,
but not being able to find it I wrote it myself. First, is there such a
function? Second, if there is not, is this implementation reasonable?

thanks, jim


from numpy import *

a2 = random.randint(1, 1000, 1000)
a1 = random.randint(1, 1000, 10)

def match(v1, v2):
d = dict(zip(v2, range(0, len(v2
return array([ d.has_key(x) for x in v1])
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Here's what I've done to numpy.fft

[Jochen Schröder]

On 13/07/10 08:47, David Goldsmith wrote:
> In light of my various questions and the responses thereto, here's what
> I've done (but not yet committed) to numpy.fft.
>
> There are many ways to define the DFT, varying in the sign of the
> exponent, normalization, etc.  In this implementation, the DFT is defined
> as
>
> .. math::
> A_k =  \sum_{m=0}^{n-1} a_m \exp\left\{-2\pi i{mk \over n}\right\}
> \qquad k = 0,\ldots,n-1
>
> where `n` is the number of input points.  In general, the DFT is defined
> for complex inputs and outputs, and a single-frequency component at linear
> frequency :math:`f` is represented by a complex exponential
> :math:`a_m = \exp\{2\pi i\,f m\Delta t\}`, where
> :math:`\Delta t` is the *sampling interval*.
>
> Note that, due to the periodicity of the exponential function, formally
> :math:`A_{n-1} = A_{-1}, A_{n-2} = A_{-2}`, etc.  That said, the values in
> the result are in the so-called "standard" order: if ``A = fft(a,n)``,
> then ``A[0]`` contains the zero-frequency term (the sum of the data),
> which is always purely real for real inputs.  Then ``A[1:n/2]`` contains
> the positive-frequency terms, and ``A[n/2+1:]`` contains the
> negative-frequency (in the sense described above) terms, from least (most
> negative) to largest (closest to zero).  In particular, for `n` even,
> ``A[n/2]`` represents both the positive and the negative Nyquist
> frequencies, and is also purely real for real input.  For `n` odd,
> ``A[(n-1)/2]`` contains the largest positive frequency, while
> ``A[(n+1)/2]`` contains the largest (in absolute value) negative
> frequency.  In both cases, i.e., `n` even or odd, ``A[n-1]`` contains the
> negative frequency closest to zero.
>
> Feedback welcome.
>
> DG
>
Hi David,

great work. I agree with Travis leave the sampling out. This make things 
more confusing. I'd also suggest pointing to fftshift for converting the 
"standard" order to order "min frequency to max frequency"

Cheers
Jochen
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Here's what I've done to numpy.fft

[David Goldsmith]

On Mon, Jul 12, 2010 at 6:33 PM, Travis Oliphant wrote:

>
> On Jul 12, 2010, at 5:47 PM, David Goldsmith wrote:
>
> > In light of my various questions and the responses thereto, here's what
> I've done (but not yet committed) to numpy.fft.
> >
> > There are many ways to define the DFT, varying in the sign of the
> > exponent, normalization, etc.  In this implementation, the DFT is defined
> > as
> >
> > .. math::
> >A_k =  \sum_{m=0}^{n-1} a_m \exp\left\{-2\pi i{mk \over n}\right\}
> >\qquad k = 0,\ldots,n-1
> >
> > where `n` is the number of input points.  In general, the DFT is defined
> > for complex inputs and outputs, and a single-frequency component at
> linear
> > frequency :math:`f` is represented by a complex exponential
> > :math:`a_m = \exp\{2\pi i\,f m\Delta t\}`, where
> > :math:`\Delta t` is the *sampling interval*.
>
> This sounds very good, but I would not mix discussions of sampling interval
> with the DFT except as an example use case.
>
> The FFT is an implementation of the DFT, and the DFT is self-contained for
> discrete signals without any discussion of continuous-time frequency or
> sampling interval.   Many applications of the FFT, however, use sampled
> continuous-time signals.
>
> So, use a_m = \exp\(2\pi j m k\) to describe the single-frequency case.
> If you want to say that k = f\Delta t for a sampled-continuous time signal,
> then that would be fine, but there are plenty of discrete signals that don't
> have any relation to continuous time where an FFT still makes sense.
>

This is an interesting comment, as the delta t, sampling interval, and
sampling-of-a-continuous-time-signal context are all "inherited" from the
original docstring (I made an effort to clarify the existing content while
still preserving it as much as possible).  If others agree that a more
general presentation is preferable, the docstring *may* require a more
extensive edit (I'll have to go back and re-read the other sections with an
eye specifically to that issue).

>
> >
> > Note that, due to the periodicity of the exponential function, formally
> > :math:`A_{n-1} = A_{-1}, A_{n-2} = A_{-2}`, etc.  That said, the values
> in
> > the result are in the so-called "standard" order: if ``A = fft(a,n)``,
> > then ``A[0]`` contains the zero-frequency term (the sum of the data),
> > which is always purely real for real inputs.  Then ``A[1:n/2]`` contains
> > the positive-frequency terms, and ``A[n/2+1:]`` contains the
> > negative-frequency (in the sense described above) terms, from least (most
> > negative) to largest (closest to zero).  In particular, for `n` even,
> > ``A[n/2]`` represents both the positive and the negative Nyquist
> > frequencies, and is also purely real for real input.  For `n` odd,
> > ``A[(n-1)/2]`` contains the largest positive frequency, while
> > ``A[(n+1)/2]`` contains the largest (in absolute value) negative
> > frequency.  In both cases, i.e., `n` even or odd, ``A[n-1]`` contains the
> > negative frequency closest to zero.
> >
> > Feedback welcome.
>
> I would remove "That said, " near the beginning of the paragraph.
>

Too colloquial? ;-)  NP.

Thanks for the great docs.
>

Thank you for the encouraging words, and for taking the time and interest.

DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.fft, yet again

[Jochen Schröder]

On 13/07/10 08:04, Eric Firing wrote:
> On 07/12/2010 11:43 AM, David Goldsmith wrote:
>>   > From the docstring:
>>
>> "A[0] contains the zero-frequency term (the mean of the signal)"
>>
>> And yet, consistent w/ the definition given in the docstring (and
>> included w/ an earlier email), the code gives, e.g.:
>>
>>   >>>  import numpy as np
>>   >>>  x = np.ones((16,)); x
>> array([ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,
>>   1.,  1.,  1.])
>>   >>>  y = np.fft.fft(x); y
>> array([ 16.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
>>0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
>>0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j])
>>
>> i.e., the zero-th term is the sum, not the mean (which, again, is
>> consistent w/ the stated defining formula).
>>
>> So, same ol', same ol': bug in the doc (presumably) or bug in the code?
>
> Bug in the doc.  Good catch.  "mean" is correct for the ifft, not for
> the fft.
>
> Eric
>

I'd say that a pointer to a discussion about normalization of ffts would 
be good here. The issue is that numpy is doing a normalization to len(x) 
for the inverse fft. However to make ffts unitary it should actually be 
that fft and ifft are normalized by sqrt(len(x)). And some fft 
implementations don't do normalizations at all (FFTW).

Cheers
Jochen

>>
>> DG
>>
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Here's what I've done to numpy.fft

[Travis Oliphant]

On Jul 12, 2010, at 5:47 PM, David Goldsmith wrote:

> In light of my various questions and the responses thereto, here's what I've 
> done (but not yet committed) to numpy.fft.
> 
> There are many ways to define the DFT, varying in the sign of the 
> exponent, normalization, etc.  In this implementation, the DFT is defined
> as
> 
> .. math::
>A_k =  \sum_{m=0}^{n-1} a_m \exp\left\{-2\pi i{mk \over n}\right\}
>\qquad k = 0,\ldots,n-1
> 
> where `n` is the number of input points.  In general, the DFT is defined 
> for complex inputs and outputs, and a single-frequency component at linear
> frequency :math:`f` is represented by a complex exponential 
> :math:`a_m = \exp\{2\pi i\,f m\Delta t\}`, where 
> :math:`\Delta t` is the *sampling interval*.

This sounds very good, but I would not mix discussions of sampling interval 
with the DFT except as an example use case. 

The FFT is an implementation of the DFT, and the DFT is self-contained for 
discrete signals without any discussion of continuous-time frequency or 
sampling interval.   Many applications of the FFT, however, use sampled 
continuous-time signals. 

So, use a_m = \exp\(2\pi j m k\) to describe the single-frequency case.   If 
you want to say that k = f\Delta t for a sampled-continuous time signal, then 
that would be fine, but there are plenty of discrete signals that don't have 
any relation to continuous time where an FFT still makes sense. 


> 
> Note that, due to the periodicity of the exponential function, formally
> :math:`A_{n-1} = A_{-1}, A_{n-2} = A_{-2}`, etc.  That said, the values in
> the result are in the so-called "standard" order: if ``A = fft(a,n)``,
> then ``A[0]`` contains the zero-frequency term (the sum of the data), 
> which is always purely real for real inputs.  Then ``A[1:n/2]`` contains 
> the positive-frequency terms, and ``A[n/2+1:]`` contains the 
> negative-frequency (in the sense described above) terms, from least (most
> negative) to largest (closest to zero).  In particular, for `n` even,
> ``A[n/2]`` represents both the positive and the negative Nyquist 
> frequencies, and is also purely real for real input.  For `n` odd, 
> ``A[(n-1)/2]`` contains the largest positive frequency, while 
> ``A[(n+1)/2]`` contains the largest (in absolute value) negative 
> frequency.  In both cases, i.e., `n` even or odd, ``A[n-1]`` contains the
> negative frequency closest to zero.
> 
> Feedback welcome.

I would remove "That said, " near the beginning of the paragraph. 

Thanks for the great docs. 

-Travis

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal: NumPy ndarray with named axes

[Robert Kern]

On Mon, Jul 12, 2010 at 17:30, Rob Speer  wrote:
> rec['305'] extracts a single value from a single record.

No, in Neil's example `rec` was a structured array. You can index
structured arrays using the names of the record members, not just
scalars.

> arr.named[:,305] extracts an *entire column* from a 2-D datarray,
> returning you a 1-D datarray.

And this is exactly what rec['305'] would get you.

In [1]: dt = np.dtype([('201', float), ('305', float), ('410', float)])

In [2]: rec = np.arange(12).astype(float).view(dt)

In [3]: rec
Out[3]:
array([(0.0, 1.0, 2.0), (3.0, 4.0, 5.0), (6.0, 7.0, 8.0), (9.0, 10.0, 11.0)],
  dtype=[('201', ' Once again, 1-D record arrays and 2-D labeled arrays look similar when
> you print them, but the data structures are so unrelated that there is
> really not much point in comparing them any further.

Not really. 1-D structured arrays can and do work well for the very
common case where one has unlabeled rows and labeled columns. They are
also a little bit more flexible in that the columns can be
heterogeneous in dtype, as columns are wont to do.

May I politely suggest that, just as some people did not do a
sufficient job of reading the datarray proposal to understand how they
differ from structured arrays, you do not know as much about
structured arrays to understand the ways in which they are similar to
labeled arrays? Understanding both the similarities and differences is
important because both are going to be living in the same ecosystem
with overlapping niches.

-- 
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Here's what I've done to numpy.fft

[David Goldsmith]

In light of my various questions and the responses thereto, here's what I've
done (but not yet committed) to numpy.fft.

There are many ways to define the DFT, varying in the sign of the
exponent, normalization, etc.  In this implementation, the DFT is defined
as

.. math::
   A_k =  \sum_{m=0}^{n-1} a_m \exp\left\{-2\pi i{mk \over n}\right\}
   \qquad k = 0,\ldots,n-1

where `n` is the number of input points.  In general, the DFT is defined
for complex inputs and outputs, and a single-frequency component at linear
frequency :math:`f` is represented by a complex exponential
:math:`a_m = \exp\{2\pi i\,f m\Delta t\}`, where
:math:`\Delta t` is the *sampling interval*.

Note that, due to the periodicity of the exponential function, formally
:math:`A_{n-1} = A_{-1}, A_{n-2} = A_{-2}`, etc.  That said, the values in
the result are in the so-called "standard" order: if ``A = fft(a,n)``,
then ``A[0]`` contains the zero-frequency term (the sum of the data),
which is always purely real for real inputs.  Then ``A[1:n/2]`` contains
the positive-frequency terms, and ``A[n/2+1:]`` contains the
negative-frequency (in the sense described above) terms, from least (most
negative) to largest (closest to zero).  In particular, for `n` even,
``A[n/2]`` represents both the positive and the negative Nyquist
frequencies, and is also purely real for real input.  For `n` odd,
``A[(n-1)/2]`` contains the largest positive frequency, while
``A[(n+1)/2]`` contains the largest (in absolute value) negative
frequency.  In both cases, i.e., `n` even or odd, ``A[n-1]`` contains the
negative frequency closest to zero.

Feedback welcome.

DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Memory leak found in ndarray (I think)?

[Nathaniel Peterson]

Wes McKinney  writes:

> Did you mean to post a different link? That's the ticket I just created :)

How silly of me! I meant http://projects.scipy.org/numpy/ticket/1427
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal: NumPy ndarray with named axes

[Rob Speer]

rec['305'] extracts a single value from a single record.
arr.named[:,305] extracts an *entire column* from a 2-D datarray,
returning you a 1-D datarray.

Once again, 1-D record arrays and 2-D labeled arrays look similar when
you print them, but the data structures are so unrelated that there is
really not much point in comparing them any further.
-- Rob

On Mon, Jul 12, 2010 at 6:01 PM, Neil Crighton  wrote:
> Rob Speer  MIT.EDU> writes:
>
>> It's not just about the rows: a 2-D datarray can also index by
>> columns, an operation that has no equivalent in a 1-D array of records
>> like your example.
>
> rec['305'] effectively indexes by column. This is one the main attractions of
> structured/record arrays.
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.fft, yet again

[David Goldsmith]

On Mon, Jul 12, 2010 at 3:04 PM, Eric Firing  wrote:

> On 07/12/2010 11:43 AM, David Goldsmith wrote:
> >  >From the docstring:
> >
> > "A[0] contains the zero-frequency term (the mean of the signal)"
> >
> > And yet, consistent w/ the definition given in the docstring (and
> > included w/ an earlier email), the code gives, e.g.:
> >
> >  >>> import numpy as np
> >  >>> x = np.ones((16,)); x
> > array([ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,
> >  1.,  1.,  1.])
> >  >>> y = np.fft.fft(x); y
> > array([ 16.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
> >   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
> >   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j])
> >
> > i.e., the zero-th term is the sum, not the mean (which, again, is
> > consistent w/ the stated defining formula).
> >
> > So, same ol', same ol': bug in the doc (presumably) or bug in the code?
>
> Bug in the doc.  Good catch.


Thanks.  (In case you hadn't noticed, I'm detail-oriented to a fault.) :-/

DG

> "mean" is correct for the ifft, not for
> the fft.
>

> Eric
>
> >
> > DG
> >
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.fft, yet again

[Eric Firing]

On 07/12/2010 11:43 AM, David Goldsmith wrote:
>  >From the docstring:
>
> "A[0] contains the zero-frequency term (the mean of the signal)"
>
> And yet, consistent w/ the definition given in the docstring (and
> included w/ an earlier email), the code gives, e.g.:
>
>  >>> import numpy as np
>  >>> x = np.ones((16,)); x
> array([ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,
>  1.,  1.,  1.])
>  >>> y = np.fft.fft(x); y
> array([ 16.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
>   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
>   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j])
>
> i.e., the zero-th term is the sum, not the mean (which, again, is
> consistent w/ the stated defining formula).
>
> So, same ol', same ol': bug in the doc (presumably) or bug in the code?

Bug in the doc.  Good catch.  "mean" is correct for the ifft, not for 
the fft.

Eric

>
> DG
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal: NumPy ndarray with named axes

[Neil Crighton]

Rob Speer  MIT.EDU> writes:

> It's not just about the rows: a 2-D datarray can also index by
> columns, an operation that has no equivalent in a 1-D array of records
> like your example.

rec['305'] effectively indexes by column. This is one the main attractions of 
structured/record arrays.




___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy.fft, yet again

[David Goldsmith]

>From the docstring:

"A[0] contains the zero-frequency term (the mean of the signal)"

And yet, consistent w/ the definition given in the docstring (and included
w/ an earlier email), the code gives, e.g.:

>>> import numpy as np
>>> x = np.ones((16,)); x
array([ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,
1.,  1.,  1.])
>>> y = np.fft.fft(x); y
array([ 16.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
 0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j,
 0.+0.j,   0.+0.j,   0.+0.j,   0.+0.j])

i.e., the zero-th term is the sum, not the mean (which, again, is consistent
w/ the stated defining formula).

So, same ol', same ol': bug in the doc (presumably) or bug in the code?

DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Memory leak found in ndarray (I think)?

[Wes McKinney]

On Mon, Jul 12, 2010 at 3:39 PM, Nathaniel Peterson
 wrote:
> This memory leak may be related: http://projects.scipy.org/numpy/ticket/1542
> It shows what appears to be a memory leak when calling astype('float')
> on an array of dtype 'object'.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

Did you mean to post a different link? That's the ticket I just created :)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Memory leak found in ndarray (I think)?

[Nathaniel Peterson]

This memory leak may be related: http://projects.scipy.org/numpy/ticket/1542
It shows what appears to be a memory leak when calling astype('float')
on an array of dtype 'object'.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Memory leak found in ndarray (I think)?

[Wes McKinney]

On Mon, Jul 12, 2010 at 2:22 PM, Wes McKinney  wrote:
> This one was quite a bear to track down, starting from the of course
> very high level observation of "why is my application leaking memory".
> I've reproduced it on Windows XP using NumPy 1.3.0 on Python 2.5 and
> 1.4.1 on Python 2.6 (EPD). Basically it seems that calling
> .astype(bool) on an ndarray slice with object dtype is leaving a
> hanging reference count, should be pretty obvious to see:
>
> from datetime import datetime
> import numpy as np
> import sys
>
> def foo(verbose=True):
>    arr = np.array([datetime.today() for _ in xrange(1000)])
>    arr = arr.reshape((500, 2))
>    sl = arr[:, 0]
>
>    if verbose: print 'Rec ct of index 0: %d' % sys.getrefcount(sl[0])
>
>    for _ in xrange(10):
>        foo = sl.astype(bool)
>
>    if verbose: print 'Rec ct of index 0: %d' % sys.getrefcount(sl[0])
>
> if __name__ == '__main__':
>    foo()
>    for i in xrange(1):
>        if not i % 1000: print i
>        foo(verbose=False)
>
> On my machine this bleeds about 100 MB of memory that you don't get
> back-- let me know if I've misinterpreted the results. I'll happily
> create a ticket on the Trac page.
>
> Thanks,
> Wes
>

Posted in Ticket #1542

http://projects.scipy.org/numpy/ticket/1542
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 3 dim array unpacking

[Anne Archibald]

On 12 July 2010 13:24, K.-Michael Aye  wrote:
> Dear numpy hackers,
>
> I can't find the syntax for unpacking the 3 dimensions of a rgb array.
> so i have a MxNx3 image array 'img' and would like to do:
>
> red, green, blue = img[magical_slicing]
>
> Which slicing magic do I need to apply?

Not slicing exactly; unpacking happens along the first dimension, so
you need to reorder your axes so your array is 3xMxN. np.rollaxis is
handy for this, as it pulls the axis you specify to the front:

red, green, blue = np.rollaxis(img,2)

Anne
> Thanks for your help!
>
> BR,
> Michael
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] 3 dim array unpacking

[K . -Michael Aye]

Dear numpy hackers,

I can't find the syntax for unpacking the 3 dimensions of a rgb array.
so i have a MxNx3 image array 'img' and would like to do:

red, green, blue = img[magical_slicing]

Which slicing magic do I need to apply?

Thanks for your help!

BR,
Michael


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Memory leak found in ndarray (I think)?

[Wes McKinney]

This one was quite a bear to track down, starting from the of course
very high level observation of "why is my application leaking memory".
I've reproduced it on Windows XP using NumPy 1.3.0 on Python 2.5 and
1.4.1 on Python 2.6 (EPD). Basically it seems that calling
.astype(bool) on an ndarray slice with object dtype is leaving a
hanging reference count, should be pretty obvious to see:

from datetime import datetime
import numpy as np
import sys

def foo(verbose=True):
arr = np.array([datetime.today() for _ in xrange(1000)])
arr = arr.reshape((500, 2))
sl = arr[:, 0]

if verbose: print 'Rec ct of index 0: %d' % sys.getrefcount(sl[0])

for _ in xrange(10):
foo = sl.astype(bool)

if verbose: print 'Rec ct of index 0: %d' % sys.getrefcount(sl[0])

if __name__ == '__main__':
foo()
for i in xrange(1):
if not i % 1000: print i
foo(verbose=False)

On my machine this bleeds about 100 MB of memory that you don't get
back-- let me know if I've misinterpreted the results. I'll happily
create a ticket on the Trac page.

Thanks,
Wes
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal: NumPy ndarray with named axes

[Rob Speer]

It's not just about the rows: a 2-D datarray can also index by
columns, an operation that has no equivalent in a 1-D array of records
like your example.

In the movie example, arr.col_named(305) (or, in datarray syntax,
arr.named[:,305], or arr.user.named[305]) contains the movie ratings
for the user with ID 305, still indexed by movie titles. You can't do
that at all with a record array of the form you described, except by
using a list comprehension over the whole array that turns it into
something else.

2-D datarrays and 1-D record arrays may look similar, but they are
very different data structures. In fact, they're probably orthogonal
to each other -- I see no reason one couldn't make a datarray of
records, except for the fact that I wouldn't want to write the __str__
for such a beast.

(Speaking of which, I'm working on a 2-D datarray __str__ based on the
Divisi one. I have to make it support datatypes besides floats,
however.)
-- Rob

On Sun, Jul 11, 2010 at 2:09 PM, Neil Crighton  wrote:
> Robert Kern  gmail.com> writes:
>
>>
>> On Sun, Jul 11, 2010 at 11:36, Rob Speer  mit.edu> wrote:
>> >> But the utility of named indices is not so clear
>> >> to me. As I understand it, these new arrays will still only be
>> >> able to have a single type of data (one of float, str, int and so
>> >> on). This seems to be pretty limiting.
>>
>> Having ticks on *every* axis is the primary feature there.
>>
>
> I see, thanks.
>
> So for Rob's example slide you could use a record array:
>
> rec = np.rec.fromrecords(data, names='name,305,6,234')
>
> (Here data is a list of tuples, each tuple giving the movie name + it's data.)
>
> In this case it's easy to index by field name (rec['205']), but a trickier to
> choose the row using the movie name:
>
> ind = dict((n,i) for i,n in enumerate(rec.name))
>
> rec[ind['Wrong Trousers, The (1993)']]
>
> So datarrays would make this easier.
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Another reality check

[David Goldsmith]

Thanks, both.

On Mon, Jul 12, 2010 at 5:39 AM, Fabrice Silva wrote:

> Le lundi 12 juillet 2010 à 18:14 +1000, Jochen Schröder a écrit :
> > On 07/12/2010 12:36 PM, David Goldsmith wrote:
> > > On Sun, Jul 11, 2010 at 6:18 PM, David Goldsmith
> > > mailto:d.l.goldsm...@gmail.com>> wrote:
> > >
> > > In numpy.fft we find the following:
> > >
> > > "Then A[1:n/2] contains the positive-frequency terms, and A[n/2+1:]
> > > contains the negative-frequency terms, in order of decreasingly
> > > negative frequency."
> > >
> > > Just want to confirm that "decreasingly negative frequency" means
> > > ..., A[n-2] = A_(-2), A[n-1] = A_(-1), as implied by our definition
> > > (attached).
> > >
> > > DG
> > > And while I have your attention :-)
> > >
> > > "For an odd number of input points, A[(n-1)/2] contains the largest
> > > positive frequency, while A[(n+1)/2] contains the largest [in absolute
> > > value] negative frequency."  Are these not also termed Nyquist
> > > frequencies?  If not, would it be incorrect to characterize them as
> "the
> > > largest realizable frequencies" (in the sense that the data contain no
> > > information about any higher frequencies)?
> > >
> > > DG
> > >
> > I would find the term the "largest realizable frequency" quite
> > confusing. Realizing is a too ambiguous term IMO. It's the largest
> > possible frequency contained in the array, so Nyquist frequency would be
> > correct IMO.
>
> Denoting Fs the sampling frequency (Fs/2 the Nyquist frequency):
>
> For even n
> A[n/2-1] stores frequency Fs/2-Fs/n, i.e. Nyquist frequency less a small
> quantity.
> A[n/2] stores frequency Fs/2, i.e. exactly Nyquist frequency.
> A[n/2+1] stores frequency -Fs/2+Fs/n, i.e. Nyquist frequency less a
> small quantity, for negative frequencies.
>
> For odd n
> A[(n-1)/2] stores frequency Fs/2-Fs/(2n) and A[(n+1)/2] the opposite
> negative frequency. But please pay attention that it does not compute
> the content at the exact Nyquist frequency! That justify the careful
> 'largest realizable frequency'.
>
> Note that the equation for the inverse DFT should state "for m=0...n-1"
> and not "for n=0...n-1"...
>

Yeah, I already caught that, thanks!

How 'bout I just use "Fabrice's formula"?  It's explicit and thus, IMO,
clear.

DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's?proposal:?NumPy?ndarray with named axes

[Gael Varoquaux]

On Mon, Jul 12, 2010 at 01:04:55PM +, Neil Crighton wrote:
> Thanks, that's a really nice description. Instead of

> data.ax_day.mean(axis=0)

> I think it would be clearer to do something like 

> data.mean(axis='day')

Yes, that's even better. The problem is that it does not extend to
operations that are not methods of the ndarray. This is why both
approaches are useful.

Anyhow, these developments do make me excited, and I am much looking
forward at the prospect of cleaning up our codebase using these features.

Gaël
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal: NumPy?ndarray with named axes

[Ryan May]

On Mon, Jul 12, 2010 at 8:04 AM, Neil Crighton  wrote:
> Gael Varoquaux  normalesup.org> writes:
>> I do such manipulation all the time, and keeping track of which axis is
>> what is fairly tedious and error prone. It would be much nicer to be able
>> to write:
>>
>>     data.ax_day.mean(axis=0)
>>     data.ax_hour.mean(axis=0)
>>
>
> Thanks, that's a really nice description. Instead of
>
> data.ax_day.mean(axis=0)
>
> I think it would be clearer to do something like
>
> data.mean(axis='day')

IIRC somewhere, at least at the BOF, this exact syntax was intended to
be supported.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Another reality check

[Fabrice Silva]

Le lundi 12 juillet 2010 à 18:14 +1000, Jochen Schröder a écrit :
> On 07/12/2010 12:36 PM, David Goldsmith wrote:
> > On Sun, Jul 11, 2010 at 6:18 PM, David Goldsmith
> > mailto:d.l.goldsm...@gmail.com>> wrote:
> >
> > In numpy.fft we find the following:
> >
> > "Then A[1:n/2] contains the positive-frequency terms, and A[n/2+1:]
> > contains the negative-frequency terms, in order of decreasingly
> > negative frequency."
> >
> > Just want to confirm that "decreasingly negative frequency" means
> > ..., A[n-2] = A_(-2), A[n-1] = A_(-1), as implied by our definition
> > (attached).
> >
> > DG
> >
> >
> > And while I have your attention :-)
> >
> > "For an odd number of input points, A[(n-1)/2] contains the largest
> > positive frequency, while A[(n+1)/2] contains the largest [in absolute
> > value] negative frequency."  Are these not also termed Nyquist
> > frequencies?  If not, would it be incorrect to characterize them as "the
> > largest realizable frequencies" (in the sense that the data contain no
> > information about any higher frequencies)?
> >
> > DG
> >
> I would find the term the "largest realizable frequency" quite 
> confusing. Realizing is a too ambiguous term IMO. It's the largest 
> possible frequency contained in the array, so Nyquist frequency would be 
> correct IMO.

Denoting Fs the sampling frequency (Fs/2 the Nyquist frequency):

For even n
A[n/2-1] stores frequency Fs/2-Fs/n, i.e. Nyquist frequency less a small 
quantity.
A[n/2] stores frequency Fs/2, i.e. exactly Nyquist frequency.
A[n/2+1] stores frequency -Fs/2+Fs/n, i.e. Nyquist frequency less a
small quantity, for negative frequencies.

For odd n
A[(n-1)/2] stores frequency Fs/2-Fs/(2n) and A[(n+1)/2] the opposite
negative frequency. But please pay attention that it does not compute
the content at the exact Nyquist frequency! That justify the careful
'largest realizable frequency'.

Note that the equation for the inverse DFT should state "for m=0...n-1"
and not "for n=0...n-1"...


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal : NumPy?ndarray with named axes

[Neil Crighton]

Gael Varoquaux  normalesup.org> writes:

> Let say that you have a dataset that is in a 3D array, where axis 0
> corresponds to days, axis 1 to hours of the day, and axis 2 to
> temperature, you might want to have the mean of the temperature in each
> day, which would be in current numpy:
> 
> data.mean(axis=0)
> 
> or the mean of the temperature at every hour, across the different days,
> which would be:
> 
> data.mean(axis=1)
> 
> I do such manipulation all the time, and keeping track of which axis is
> what is fairly tedious and error prone. It would be much nicer to be able
> to write:
> 
> data.ax_day.mean(axis=0)
> data.ax_hour.mean(axis=0)
> 

Thanks, that's a really nice description. Instead of

data.ax_day.mean(axis=0)

I think it would be clearer to do something like 

data.mean(axis='day')

but I see the motivation.


Neil




___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Function returns nothing!

[Scott Sinclair]

>On 12 July 2010 11:45, allan oware  wrote:
> Hi All!
>
> def height_diffs():
>     h = []
>     i = 0
>     while True:
>     x = raw_input("Enter height difference ")
>     if x == 'q':
>     break
>     else:
>     h.append(x)
>     i = i + 1
>
>     m = asarray(h,dtype=float)
>
>     return m
>
>
> why does return statement return nothing?

It works for me. Can you explain what you mean by "return nothing"?

Cheers,
Scott
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF notes: Fernando's proposal: NumPy?ndarray with named axes

[Gael Varoquaux]

On Sun, Jul 11, 2010 at 11:59:30AM +, Neil Crighton wrote:
> What is a use case for the new array type that can't be solved by
> structured/record arrays?  Sounds like it was decided at the Sciy
> BOF they were a good idea, several people have implemented a
> version of them and Fernando and Gael have both said they find
> them useful, so they must have something going for them.  Maybe
> Fernando or Gael could share an example where arrays with named
> axes and indices are especially useful, for the peanut gallery's
> benefit?

Because my name is in this e-mail, I feel obliged to answer, but I think
that my usecases and opinions are not any more important than anybody
else.

Let say that you have a dataset that is in a 3D array, where axis 0
corresponds to days, axis 1 to hours of the day, and axis 2 to
temperature, you might want to have the mean of the temperature in each
day, which would be in current numpy:

data.mean(axis=0)

or the mean of the temperature at every hour, across the different days,
which would be:

data.mean(axis=1)

I do such manipulation all the time, and keeping track of which axis is
what is fairly tedious and error prone. It would be much nicer to be able
to write:

data.ax_day.mean(axis=0)
data.ax_hour.mean(axis=0)

Also, when dealing in a library with such data and writing functions,
it's quite easy to have errors in the computations coming from
transpositions or other reorderings. Given an array, I have no way of
telling what axis corresponds to what, and to trace such error. If my
library has a convention that each ndarray should have a named axis
called 'time', I know how to do timeseries analysis on multidimensional
data.

My 2 cents,

Gaël
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Function returns nothing!

[allan oware]

Hi All!

def height_diffs():
h = []
i = 0
while True:
x = raw_input("Enter height difference ")
if x == 'q':
break
else:
h.append(x)
i = i + 1

m = asarray(h,dtype=float)

return m


why does return statement return nothing?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Another reality check

[Jochen Schröder]

On 07/12/2010 12:36 PM, David Goldsmith wrote:
> On Sun, Jul 11, 2010 at 6:18 PM, David Goldsmith
> mailto:d.l.goldsm...@gmail.com>> wrote:
>
> In numpy.fft we find the following:
>
> "Then A[1:n/2] contains the positive-frequency terms, and A[n/2+1:]
> contains the negative-frequency terms, in order of decreasingly
> negative frequency."
>
> Just want to confirm that "decreasingly negative frequency" means
> ..., A[n-2] = A_(-2), A[n-1] = A_(-1), as implied by our definition
> (attached).
>
> DG
>
>
> And while I have your attention :-)
>
> "For an odd number of input points, A[(n-1)/2] contains the largest
> positive frequency, while A[(n+1)/2] contains the largest [in absolute
> value] negative frequency."  Are these not also termed Nyquist
> frequencies?  If not, would it be incorrect to characterize them as "the
> largest realizable frequencies" (in the sense that the data contain no
> information about any higher frequencies)?
>
> DG
>
I would find the term the "largest realizable frequency" quite 
confusing. Realizing is a too ambiguous term IMO. It's the largest 
possible frequency contained in the array, so Nyquist frequency would be 
correct IMO.

>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion