yes, I verified that it get called.
On 11/14/2013 10:31 AM, Bill Spotz wrote:
> Burlen,
>
> Have you actually verified that the first instance of import_array() actually
> gets called? Because the behavior suggests that it does not.
>
> In PyTrilinos, I wrap the import_array() call inside a C++
On Thu, Nov 14, 2013 at 7:05 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
> On Thu, Nov 14, 2013 at 9:37 AM, David Cournapeau wrote:
>
>>
>> You can for example compare np.fft.fft(a) for 2**16 and 2**16+1 (and
>> 2**16-1 that while bad is not prime, so only 1 order of magnitude slowe
On Thu, Nov 14, 2013 at 9:37 AM, David Cournapeau wrote:
>
> You can for example compare np.fft.fft(a) for 2**16 and 2**16+1 (and
> 2**16-1 that while bad is not prime, so only 1 order of magnitude slower).
>
I actually did...
Each step of a FFT basically splits a DFT of size N = P*Q into P DFTs
Burlen,
Have you actually verified that the first instance of import_array() actually
gets called? Because the behavior suggests that it does not.
In PyTrilinos, I wrap the import_array() call inside a C++ singleton, and put
that singleton in a dynamic library that all my packages link to, thu
Hi David,
Yes, that the situation. using your naming convention, in addtion to
foo_wrap.c I have another file , say foo_convert.cxx, for massaging
python data structures into our internal data structures. This source is
compiled with a c++ compiler so that I can use templates to simplify
handl
On Thu, Nov 14, 2013 at 5:30 PM, Max Linke wrote:
> You can check everything in the notebook, it will generate all the data.
> I checked the runtime for sizes in logspace(2, 7, 25). I know that the
> fft will work faster for array sizes that are a power of 2 but
> differences on 3 orders of magni
You can check everything in the notebook, it will generate all the data.
I checked the runtime for sizes in logspace(2, 7, 25). I know that the
fft will work faster for array sizes that are a power of 2 but
differences on 3 orders of magnitude is huge. I also attached a script
generated from the no
On Thu, Nov 14, 2013 at 5:30 PM, Max Linke wrote:
>
> You can check everything in the notebook, it will generate all the data.
> I checked the runtime for sizes in logspace(2, 7, 25). I know that the
> fft will work faster for array sizes that are a power of 2 but
> differences on 3 orders of magn
On Thu, Nov 14, 2013 at 4:45 PM, Charles Waldman wrote:
>
> Can you post the raw data? It seems like there are just a couple of
"bad" sizes, I'd like to know more precisely what these are.
>
> It's typical for FFT to perform better at a sample size that is a power
of 2, and algorithms like FFTW t
On Thu, Nov 14, 2013 at 4:45 PM, Charles Waldman wrote:
> Can you post the raw data? It seems like there are just a couple of "bad"
> sizes, I'd like to know more precisely what these are.
>
Indeed. Several of the sizes generated by logspace(2, 7, 25) are prime
numbers, where numpy.fft is actua
Can you post the raw data? It seems like there are just a couple of "bad"
sizes, I'd like to know more precisely what these are.
It's typical for FFT to perform better at a sample size that is a power of
2, and algorithms like FFTW take advantage of factoring the size, and
"sizes that are product
On 14 November 2013 09:25, Pierre Haessig wrote:
> Le 13/11/2013 17:54, Daπid a écrit :
> >
> > np.savetxt('a.csv', [1], fmt=str('%.3f'))
> Thanks, that's what I did too.
>
> I'm just still wondering whether there is a cleaner solution...
>
I have a fix, I am submitting a PR. The only thing I am
Le 13/11/2013 17:54, Daπid a écrit :
>
> np.savetxt('a.csv', [1], fmt=str('%.3f'))
Thanks, that's what I did too.
I'm just still wondering whether there is a cleaner solution...
>
> Without the str, I get a clearer error:
> ValueError: invalid fmt: u'%.3f'
>
Yeah, the commit by Warren Weckesser m
13 matches
Mail list logo
