> Zero-padding won't help with the non-periodicity, will it? For
> that you may want to window instead.
Umh, it depends what you use the FFT for. You are right Stéfan when
saying that Joseph should probably also use a window to get rid of the
high frequencies that will come from the sharp ste
If your sequence is not meant to be periodic (i.e., if after one minute
there is no reason why the signal should start back at the beginning
right away), then you should do zero-padding. And while you zero-pad,
you can zero-pad to a sequence that is a power of two, thus preventing
awkward facto
>> Id rather have us discuss how to facilitate the integration of as
many possible fft libraries with numpy behind a maximally uniform
interface, rather than having us debate which fft library is 'best'.
I agree with the above.
> I would agree if it were not already there, but removing it (lik
> I think we could add new generators to NumPy though,
> perhaps with a keyword to control the algorithm (defaulting to the
current
> Mersenne Twister).
Why not do something like the C++11 ? In , a "generator"
is the engine producing randomness, and a "distribution" decides what is
the type
> You had me at Kronecker delta... :-) +1
> >
>
>
> Sounds good to me. I don't see a reason for not
relaxing the
> restriction, unless there is some technical issue,
(I created issue 4965 earlier today on this topic, and I have been
advised to email to this mailing list to discuss whether it is a good
idea or not. I include my original post as-is, followed by additional
comments.)
I think that the following new feature would make `numpy.einsum` even
more p
