On Sat, Mar 14, 2009 at 10:44 PM, Sturla Molden wrote:
> >
> > I think MSVC uses _inline
>
> No, MSVC uses a double underscore. That is, __restrict for variable names
> and __declspec(restrict) for function return values.
>
Yes, but MSVC uses _inline for inline.
>
> >>#if (__STDC_VERSION__
>
> I think MSVC uses _inline
No, MSVC uses a double underscore. That is, __restrict for variable names
and __declspec(restrict) for function return values.
>>#if (__STDC_VERSION__ >= 199901L)
>>#undef RESTRICT
>>#undef INLINE
>>#define RESTRICT restrict
>>#de
On Sat, Mar 14, 2009 at 8:52 PM, Sturla Molden wrote:
>
> > Ok, but most GNU compilers has a __restrict__ extension for C89 and C++
> > that we could use. And MSVC has a compiler pragma in VS2003 and a
> > __restrict extension in VS2005 later versions. So we could define a
> mscro
> > RESTRICT t
On Sat, Mar 14, 2009 at 8:26 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
>
> > We can't count on C99 at this point. Maybe David will add something so we
> > can use c99 when it is available.
>
> Ok, but most GNU compilers has a __restrict__ extension for C8
> Ok, but most GNU compilers has a __restrict__ extension for C89 and C++
> that we could use. And MSVC has a compiler pragma in VS2003 and a
> __restrict extension in VS2005 later versions. So we could define a mscro
> RESTRICT to be restrict in ISO C99, __restrict__ in GCC 3 and 4,
> __restrict
On Sat, Mar 14, 2009 at 8:26 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
>
> > We can't count on C99 at this point. Maybe David will add something so we
> > can use c99 when it is available.
>
> Ok, but most GNU compilers has a __restrict__ extension for C8
> On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
> We can't count on C99 at this point. Maybe David will add something so we
> can use c99 when it is available.
Ok, but most GNU compilers has a __restrict__ extension for C89 and C++
that we could use. And MSVC has a compiler pragma in VS2
On Sat, Mar 14, 2009 at 7:02 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden wrote:
>
> > There is also a ticket (#579) to add an implementation of the Bluestein
> > algorithm for doing prime order fft's. This could also be used for zoom
> > type fft's. There is lots
On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
>
> > Give it a shot. Note that the fft transforms also use int instead of
> > intp,
> > which limits the maximum transform size to 32 bits. Fixing that is
> > somewhere
> > on my todo list but I would be happy to leave it to you ;) Although I
> Give it a shot. Note that the fft transforms also use int instead of
> intp,
> which limits the maximum transform size to 32 bits. Fixing that is
> somewhere
> on my todo list but I would be happy to leave it to you ;) Although I
> expect
> transforms > 2GB aren't all that common.
By the way..
> On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden wrote:
> There is also a ticket (#579) to add an implementation of the Bluestein
> algorithm for doing prime order fft's. This could also be used for zoom
> type fft's. There is lots of fft stuff to be done. I wonder if some of it
> shouldn't go i
On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 2:24 PM, Charles R Harris
>
> >> Give it a shot. Note that the fft transforms also use int instead of
> >> intp,
> >> which limits the maximum transform size to 32 bits. Fixing that is
> >> somewhere
> >> on my todo
> On Sat, Mar 14, 2009 at 2:24 PM, Charles R Harris
>> Give it a shot. Note that the fft transforms also use int instead of
>> intp,
>> which limits the maximum transform size to 32 bits. Fixing that is
>> somewhere
>> on my todo list but I would be happy to leave it to you ;) Although I
>> expect
On Sat, Mar 14, 2009 at 4:58 PM, Charles R Harris
wrote:
>
>
> On Sat, Mar 14, 2009 at 2:28 PM, wrote:
>>
>> On Sat, Mar 14, 2009 at 4:22 PM, Sturla Molden wrote:
>> >> On Sat, Mar 14, 2009 at 1:37 PM, wrote:
>> >
>> >> OK. One more question: how often do the tests fail? I want to include a
>>
On Sat, Mar 14, 2009 at 2:24 PM, Charles R Harris wrote:
>
>
> On Sat, Mar 14, 2009 at 2:16 PM, Sturla Molden wrote:
>
>>
>>
>> 1) I have noticed that fftpack_litemodule.c does not release the GIL
>> around calls to functions in fftpack.c. I cannot se any obvious reason for
>> this. As far as I
On Sat, Mar 14, 2009 at 2:28 PM, wrote:
> On Sat, Mar 14, 2009 at 4:22 PM, Sturla Molden wrote:
> >> On Sat, Mar 14, 2009 at 1:37 PM, wrote:
> >
> >> OK. One more question: how often do the tests fail? I want to include a
> >> note
> >> to repeat testing if the test fails.
> >
> > I don't like
On Sat, Mar 14, 2009 at 4:22 PM, Sturla Molden wrote:
>> On Sat, Mar 14, 2009 at 1:37 PM, wrote:
>
>> OK. One more question: how often do the tests fail? I want to include a
>> note
>> to repeat testing if the test fails.
>
> I don't like this. I think the prngs should use fixed seeds known to pa
On Sat, Mar 14, 2009 at 2:22 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 1:37 PM, wrote:
>
> > OK. One more question: how often do the tests fail? I want to include a
> > note
> > to repeat testing if the test fails.
>
> I don't like this. I think the prngs should use fixed seeds known
On Sat, Mar 14, 2009 at 2:16 PM, Sturla Molden wrote:
>
>
> 1) I have noticed that fftpack_litemodule.c does not release the GIL
> around calls to functions in fftpack.c. I cannot se any obvious reason for
> this. As far as I can tell, the functions in fftpack.c are re-entrant.
>
> 2) If fftpack_
> On Sat, Mar 14, 2009 at 1:37 PM, wrote:
> OK. One more question: how often do the tests fail? I want to include a
> note
> to repeat testing if the test fails.
I don't like this. I think the prngs should use fixed seeds known to pass
the test. Depending on confidence intervals in the units tes
1) I have noticed that fftpack_litemodule.c does not release the GIL
around calls to functions in fftpack.c. I cannot se any obvious reason for
this. As far as I can tell, the functions in fftpack.c are re-entrant.
2) If fftpack_lite did release the GIL, it would allow functions in
numpy.fft to
On Sat, Mar 14, 2009 at 1:52 PM, Charles R Harris wrote:
>
>
> On Sat, Mar 14, 2009 at 1:37 PM, wrote:
>
>> On Sat, Mar 14, 2009 at 3:11 PM, Charles R Harris
>> wrote:
>> > Hi Josef,
>> >
>> > On Sat, Mar 14, 2009 at 12:14 PM, wrote:
>> >
>> >
>> >>
>> >> {{{
>> >> import numpy as np
>> >>
>>
On Sat, Mar 14, 2009 at 1:37 PM, wrote:
> On Sat, Mar 14, 2009 at 3:11 PM, Charles R Harris
> wrote:
> > Hi Josef,
> >
> > On Sat, Mar 14, 2009 at 12:14 PM, wrote:
> >
> >
> >>
> >> {{{
> >> import numpy as np
> >>
> >> assert np.all(np.random.hypergeometric(3,18,11,size=10) < 4)
> >> assert n
On Sat, Mar 14, 2009 at 3:11 PM, Charles R Harris
wrote:
> Hi Josef,
>
> On Sat, Mar 14, 2009 at 12:14 PM, wrote:
>
>
>>
>> {{{
>> import numpy as np
>>
>> assert np.all(np.random.hypergeometric(3,18,11,size=10) < 4)
>> assert np.all(np.random.hypergeometric(18,3,11,size=10) > 0)
>>
>> pr = 0.8
Hi Josef,
On Sat, Mar 14, 2009 at 12:14 PM, wrote:
> {{{
> import numpy as np
>
> assert np.all(np.random.hypergeometric(3,18,11,size=10) < 4)
> assert np.all(np.random.hypergeometric(18,3,11,size=10) > 0)
>
> pr = 0.8
> N = 10
> rvsn = np.random.logseries(pr,size=N)
> # these two frequenc
> Can you open a ticket for this?
Done. Ticket #1053
Surla
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Mar 14, 2009 at 12:14 PM, wrote:
> On Sat, Mar 14, 2009 at 1:52 PM, David Cournapeau
> wrote:
> > On Sun, Mar 15, 2009 at 2:40 AM, Charles R Harris
> > wrote:
> >
> >>
> >> The fixes look small and I'd like them to go in. Can you put together
> some
> >> short tests for these fixes? Wou
Hi Sturla,
On Sat, Mar 14, 2009 at 12:23 PM, Sturla Molden wrote:
> >
> > Will memmap be fixed to use offsets correctly before 1.3?
>
> I posted this to scipy-dev (possibly wrong list) on March 9, so I'll
> repeat it here: In Python 2.6, mmap has a offset keyword. NumPy's memmap
> should use thi
>
> Will memmap be fixed to use offsets correctly before 1.3?
I posted this to scipy-dev (possibly wrong list) on March 9, so I'll
repeat it here: In Python 2.6, mmap has a offset keyword. NumPy's memmap
should use this to allow big files to be memory mapped on 32 bit systems.
Only a minor change
On Sat, Mar 14, 2009 at 1:52 PM, David Cournapeau wrote:
> On Sun, Mar 15, 2009 at 2:40 AM, Charles R Harris
> wrote:
>
>>
>> The fixes look small and I'd like them to go in. Can you put together some
>> short tests for these fixes? Would it help if you had commit privileges in
>> Numpy?
>
> Yes,
Will memmap be fixed to use offsets correctly before 1.3?
> hi,
>
> Just a friendly reminder that I will close the trunk for 1.3.0 at the
> end of 15th March (I will more likely do it at the end of Monday Japan
> time which roughly corresponds to 15th March midnight Pacific time),
>
> cheers,
>
On Sat, Mar 14, 2009 at 11:52 AM, David Cournapeau wrote:
> On Sun, Mar 15, 2009 at 2:40 AM, Charles R Harris
> wrote:
>
> >
> > The fixes look small and I'd like them to go in. Can you put together
> some
> > short tests for these fixes? Would it help if you had commit privileges
> in
> > Numpy?
On Sun, Mar 15, 2009 at 2:40 AM, Charles R Harris
wrote:
>
> The fixes look small and I'd like them to go in. Can you put together some
> short tests for these fixes? Would it help if you had commit privileges in
> Numpy?
Yes, I was about to suggest giving Josef commit access to numpy, I
unfortu
On Sat, Mar 14, 2009 at 10:57 AM, wrote:
> On Sat, Mar 14, 2009 at 12:01 PM, David Cournapeau
> wrote:
> > hi,
> >
> > Just a friendly reminder that I will close the trunk for 1.3.0 at the
> > end of 15th March (I will more likely do it at the end of Monday Japan
> > time which roughly correspon
On Sat, Mar 14, 2009 at 12:01 PM, David Cournapeau wrote:
> hi,
>
> Just a friendly reminder that I will close the trunk for 1.3.0 at the
> end of 15th March (I will more likely do it at the end of Monday Japan
> time which roughly corresponds to 15th March midnight Pacific time),
>
> cheers,
>
>
On Fri, Mar 13, 2009 at 9:18 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 13, 2009 at 2:15 PM, Patrick Marsh
> wrote:
>>
>> Hi,
>>
>> I'm trying to build numpy from SVN and ran across this error:
>> numpy/core/include/numpy/npy_cpu.h:44:10: error: #error Unknown CPU,
>> please report this to num
hi,
Just a friendly reminder that I will close the trunk for 1.3.0 at the
end of 15th March (I will more likely do it at the end of Monday Japan
time which roughly corresponds to 15th March midnight Pacific time),
cheers,
David
___
Numpy-discussion mai
37 matches
Mail list logo
