Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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__ >= 199901L) > >>#undef RESTRICT > >>#undef INLINE > >>#define RESTRICT restrict > >>#define INLINE inline > >>#endif > >> #endif > >> > > > > What does this last bit do? We implicitly assume that ieee floating point > > is > > available. > > It uses the restrict keyword in C99. The last test will pass on any C99 > compiler. > > > >> #ifdef DOUBLE > >>typedef double Treal > >> #else > >>typedef float Treal > >> #endif > >> typedef Treal *RESTRICT Vreal /* V as in "vector" */ > >> > >> > > I'm not sure about the names. I would prefer to keep the declarations > > along > > the lines of > > > > double * NPY_RESTRICT ptmp; > So use a local define. > > Yes, but then I would have to go in and edit all function bodies in > fftpack.c as well. fftpack.c currently uses "Treal array[]" as naming > convention, so I just changed that to "Vreal array". > > I changed all ints to long for 64 bit support. > Long is 32 bits on 64 bit windows. You need long long there. That's why npy_intp is preferred. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
> > 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 >>#define INLINE inline >>#endif >> #endif >> > > What does this last bit do? We implicitly assume that ieee floating point > is > available. It uses the restrict keyword in C99. The last test will pass on any C99 compiler. >> #ifdef DOUBLE >>typedef double Treal >> #else >>typedef float Treal >> #endif >> typedef Treal *RESTRICT Vreal /* V as in "vector" */ >> >> > I'm not sure about the names. I would prefer to keep the declarations > along > the lines of > > double * NPY_RESTRICT ptmp; Yes, but then I would have to go in and edit all function bodies in fftpack.c as well. fftpack.c currently uses "Treal array[]" as naming convention, so I just changed that to "Vreal array". I changed all ints to long for 64 bit support. Well, it compiles and runs ok on my computer now. I'll open a ticket for the FFT. I'll attach the C files to the ticket. Sturla Molden ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 to be restrict in ISO C99, __restrict__ in GCC 3 and 4,
> > __restrict in recent versions of MSVC, and nothing elsewhere.
>
>
> I know it's ugly, but something like this:
>
Can't help but be ugly when dealing with all the compilers out there.
>
> #define RESTRICT
> #define INLINE
> /*use GNU extension if possible*/
> #ifdef __GNUC__
>#if (__GNUC__ >= 3)
>#undef RESTRICT
>#undef INLINE
>#define RESTRICT __restrict__
>#define INLINE __inline__
>#endif
> #endif
> /* use MSVC extensions if possible */
> #ifdef MSVC
>#if (MSVC_VER >= 1400)
>#define RESTRICT __restrict
>#define INLINE inline
>#endif
> #endif
I think MSVC uses _inline
>
> #ifdef __cplusplus
> extern "C" {
>#undef INLINE
>#define INLINE inline
> #else
>/* use C99 if possible */
>#if (__STDC_VERSION__ >= 199901L)
>#undef RESTRICT
>#undef INLINE
>#define RESTRICT restrict
>#define INLINE inline
>#endif
> #endif
>
What does this last bit do? We implicitly assume that ieee floating point is
available.
>
> #ifdef DOUBLE
>typedef double Treal
> #else
>typedef float Treal
> #endif
> typedef Treal *RESTRICT Vreal /* V as in "vector" */
>
>
I'm not sure about the names. I would prefer to keep the declarations along
the lines of
double * NPY_RESTRICT ptmp;
As it is easier to read and understand without going to the macro
definition. Note that David has a quite involved check for the inline
keyword implementation and I expect he would want to do the same for the
restrict keyword. I think using lots of #if defined(xxx) might be easier but
I leave that stuff alone. It's David's headache.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 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 in recent versions of MSVC, and nothing elsewhere. > > > > I don't have a problem with this, although I not sure what npy type is > > appropriate without looking. Were you thinking of size_t? I was tempted > by > > that. But why is it more efficient? I haven't seen any special > > instructions > > at the assembly level, so unless there is some sort of global > optimization > > that isn't obvious I don't know where the advantage is. > > I may be that my memory serves med badly. I thought I read it here, but it > does not show examples of different assembly code being generated. So I > think I'll just leave it for now and experiment with this later. > > http://support.amd.com/us/Processor_TechDocs/22007.pdf > I suspect the biggest gains can be made from careful attention to cache issues. I had a prototype block based fft -- using a different algorithm than the usual -- that outperformed fftw at that time. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
> 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 in recent versions of MSVC, and nothing elsewhere.
I know it's ugly, but something like this:
#define RESTRICT
#define INLINE
/*use GNU extension if possible*/
#ifdef __GNUC__
#if (__GNUC__ >= 3)
#undef RESTRICT
#undef INLINE
#define RESTRICT __restrict__
#define INLINE __inline__
#endif
#endif
/* use MSVC extensions if possible */
#ifdef MSVC
#if (MSVC_VER >= 1400)
#define RESTRICT __restrict
#define INLINE inline
#endif
#endif
#ifdef __cplusplus
extern "C" {
#undef INLINE
#define INLINE inline
#else
/* use C99 if possible */
#if (__STDC_VERSION__ >= 199901L)
#undef RESTRICT
#undef INLINE
#define RESTRICT restrict
#define INLINE inline
#endif
#endif
#ifdef DOUBLE
typedef double Treal
#else
typedef float Treal
#endif
typedef Treal *RESTRICT Vreal /* V as in "vector" */
S.M.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 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 in recent versions of MSVC, and nothing elsewhere. > > > > I don't have a problem with this, although I not sure what npy type is > > appropriate without looking. Were you thinking of size_t? I was tempted > by > > that. But why is it more efficient? I haven't seen any special > > instructions > > at the assembly level, so unless there is some sort of global > optimization > > that isn't obvious I don't know where the advantage is. > > I may be that my memory serves med badly. I thought I read it here, but it > does not show examples of different assembly code being generated. So I > think I'll just leave it for now and experiment with this later. > > http://support.amd.com/us/Processor_TechDocs/22007.pdf > > Is an npy_intp 64 bit on 64 bit systems? > > Yes, it is the same size as a pointer, but it is signed... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
> 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 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 in recent versions of MSVC, and nothing elsewhere. > I don't have a problem with this, although I not sure what npy type is > appropriate without looking. Were you thinking of size_t? I was tempted by > that. But why is it more efficient? I haven't seen any special > instructions > at the assembly level, so unless there is some sort of global optimization > that isn't obvious I don't know where the advantage is. I may be that my memory serves med badly. I thought I read it here, but it does not show examples of different assembly code being generated. So I think I'll just leave it for now and experiment with this later. http://support.amd.com/us/Processor_TechDocs/22007.pdf Is an npy_intp 64 bit on 64 bit systems? Sturla Molden ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 of fft stuff to be done. I wonder if some of it > > shouldn't go in Scipy? I think David added some dcts to Scipy. > > I am not changing or adding algorithms for now. This is just to prevent > NumPy from locking up the interpreter while doing FFTs. > Well, I was hoping to get you sucked into doing some work here ;) > > The loops that are worth multithreading are done in C in > fftpack_litemodule.c, not in Python in fftpack.py. I have added OpenMP > pragmas around them. When NumPy gets a build process that supports OpenMP, > they will execute in parallel. On GCC 4.4 is means compiling with -fopenmp > and linking -lgomp -lpthread (that goes for mingw/cygwin as well). > > The init function seems to be thread safe. cffti and rffti work on arrays > created in the callers (fftpack_cffti and fftpack_rffti), no global > objects are touched. > > I'm attaching a version of fftpack_litemodule.c that fixes most of what I > mentioned. > Can you put it somewhere for review? I don't think this should go into 1.3 at this late date but 1.4 is a good chance. Hopefully we will get the next release out a bit faster than this one. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 > > expect > > transforms > 2GB aren't all that common. > > > By the way... When looking at fftpack.c there are two things that would > likely improve the performance. > > 1) If we used ISO C (aka C99), arrays could be restricted, thus allowing > more aggressive optimization. Now the compiler has to assume aliasing > between function arguments. But as the C code is translated from Fortran, > this is not the case. > We can't count on C99 at this point. Maybe David will add something so we can use c99 when it is available. > > 2) In C, indexing arrays with unsigned integers are much more efficient > (cf. AMDs optimization guide). I think the use of signed integers as array > indices are inherited from Fortran77 FFTPACK. We should probably index the > arrays with unsigned longs. > I don't have a problem with this, although I not sure what npy type is appropriate without looking. Were you thinking of size_t? I was tempted by that. But why is it more efficient? I haven't seen any special instructions at the assembly level, so unless there is some sort of global optimization that isn't obvious I don't know where the advantage is. I always figured that a really good optimizer should derive the FFT if you just give it the DFT code ;) Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
> 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... When looking at fftpack.c there are two things that would likely improve the performance. 1) If we used ISO C (aka C99), arrays could be restricted, thus allowing more aggressive optimization. Now the compiler has to assume aliasing between function arguments. But as the C code is translated from Fortran, this is not the case. 2) In C, indexing arrays with unsigned integers are much more efficient (cf. AMDs optimization guide). I think the use of signed integers as array indices are inherited from Fortran77 FFTPACK. We should probably index the arrays with unsigned longs. Sturla Molden ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
> 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 in Scipy? I think David added some dcts to Scipy.
I am not changing or adding algorithms for now. This is just to prevent
NumPy from locking up the interpreter while doing FFTs.
The loops that are worth multithreading are done in C in
fftpack_litemodule.c, not in Python in fftpack.py. I have added OpenMP
pragmas around them. When NumPy gets a build process that supports OpenMP,
they will execute in parallel. On GCC 4.4 is means compiling with -fopenmp
and linking -lgomp -lpthread (that goes for mingw/cygwin as well).
The init function seems to be thread safe. cffti and rffti work on arrays
created in the callers (fftpack_cffti and fftpack_rffti), no global
objects are touched.
I'm attaching a version of fftpack_litemodule.c that fixes most of what I
mentioned.
Sturla Molden
#include "fftpack.h"
#include "Python.h"
#include "numpy/arrayobject.h"
static PyObject *ErrorObject;
/* - */
static char fftpack_cfftf__doc__[] = "";
PyObject *
fftpack_cfftf(PyObject *NPY_UNUSED(self), PyObject *args)
{
PyObject *op1, *op2;
PyArrayObject *data;
PyArray_Descr *descr;
double *wsave, *dptr;
npy_intp nsave;
int npts, nrepeats, i;
if(!PyArg_ParseTuple(args, "OO", &op1, &op2)) {
return NULL;
}
data = (PyArrayObject *)PyArray_CopyFromObject(op1,
PyArray_CDOUBLE, 1, 0);
if (data == NULL) {
return NULL;
}
descr = PyArray_DescrFromType(PyArray_DOUBLE);
if (PyArray_AsCArray(&op2, (void *)&wsave, &nsave, 1, descr) == -1) {
goto fail;
}
if (data == NULL) {
goto fail;
}
npts = data->dimensions[data->nd - 1];
if (nsave != npts*4 + 15) {
PyErr_SetString(ErrorObject, "invalid work array for fft size");
goto fail;
}
nrepeats = PyArray_SIZE(data)/npts;
NPY_SIGINT_ON;
Py_BEGIN_ALLOW_THREADS
#pragma omp parallel for private(i,dptr) default(shared)
for (i = 0; i < nrepeats; i++) {
dptr = (double *)data->data + i*npts*2;
cfftf(npts, dptr, wsave);
}
Py_END_ALLOW_THREADS
NPY_SIGINT_OFF;
PyArray_Free(op2, (char *)wsave);
return (PyObject *)data;
fail:
PyArray_Free(op2, (char *)wsave);
Py_DECREF(data);
return NULL;
}
static char fftpack_cfftb__doc__[] = "";
PyObject *
fftpack_cfftb(PyObject *NPY_UNUSED(self), PyObject *args)
{
PyObject *op1, *op2;
PyArrayObject *data;
PyArray_Descr *descr;
double *wsave, *dptr;
npy_intp nsave;
int npts, nrepeats, i;
if(!PyArg_ParseTuple(args, "OO", &op1, &op2)) {
return NULL;
}
data = (PyArrayObject *)PyArray_CopyFromObject(op1,
PyArray_CDOUBLE, 1, 0);
if (data == NULL) {
return NULL;
}
descr = PyArray_DescrFromType(PyArray_DOUBLE);
if (PyArray_AsCArray(&op2, (void *)&wsave, &nsave, 1, descr) == -1) {
goto fail;
}
if (data == NULL) {
goto fail;
}
npts = data->dimensions[data->nd - 1];
if (nsave != npts*4 + 15) {
PyErr_SetString(ErrorObject, "invalid work array for fft size");
goto fail;
}
nrepeats = PyArray_SIZE(data)/npts;
dptr = (double *)data->data;
NPY_SIGINT_ON;
Py_BEGIN_ALLOW_THREADS
#pragma omp parallel for private(i,dptr) default(shared)
for (i = 0; i < nrepeats; i++) {
dptr = (double *)data->data + i*npts*2;
cfftb(npts, dptr, wsave);
}
Py_END_ALLOW_THREADS
NPY_SIGINT_OFF;
PyArray_Free(op2, (char *)wsave);
return (PyObject *)data;
fail:
PyArray_Free(op2, (char *)wsave);
Py_DECREF(data);
return NULL;
}
static char fftpack_cffti__doc__[] ="";
static PyObject *
fftpack_cffti(PyObject *NPY_UNUSED(self), PyObject *args)
{
PyArrayObject *op;
npy_intp dim;
long n;
if (!PyArg_ParseTuple(args, "l", &n)) {
return NULL;
}
/*Magic size needed by cffti*/
dim = 4*n + 15;
/*Create a 1 dimensional array of dimensions of type double*/
op = (PyArrayObject *)PyArray_SimpleNew(1, &dim, PyArray_DOUBLE);
if (op == NULL) {
return NULL;
}
NPY_SIGINT_ON;
Py_BEGIN_ALLOW_THREADS
cffti(n, (double *)((PyArrayObject*)op)->data);
Py_END_ALLOW_THREADS
NPY_SIGINT_OFF;
return (PyObject *)op;
}
static char fftpack_rfftf__doc__[] ="";
PyObject *
fftpack_rfftf(PyObject *NPY_UNUSED(self), PyObject *args)
{
PyObject *op1, *op2;
PyArrayObject *data, *ret;
PyArray_Descr *descr;
double *wsave, *dptr, *rptr;
npy_intp nsave;
int npts, nrepeats, i, rstep;
if(!PyArg_ParseTuple(args, "OO", &op1, &op2)) {
return NULL;
}
data = (PyArrayObject *)
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 list but I would be happy to leave it to you ;) Although I > >> expect > >> transforms > 2GB aren't all that common. > >> > > > > On the reentrant bit, IIRC fftpack builds a table of sin/cos. It might be > > worth checking/making that thread safe. > > Thanks, I'll take a careful look at it. > 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 in Scipy? I think David added some dcts to Scipy. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
> 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 >> transforms > 2GB aren't all that common. >> > > On the reentrant bit, IIRC fftpack builds a table of sin/cos. It might be > worth checking/making that thread safe. Thanks, I'll take a careful look at it. Sturla ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 >> >> 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 tests is >> > really, >> > really bad style. Tests should be deterministic. >> > >> > S.M. >> > >> >> The hypergeometric tests are on the support of the distribution and >> should never fail. And the outcome is not random. >> >> The test of logser with N = 10 also should be pretty exact and >> fail only with very low probability in the patched version. But again >> this is testet in scipy.stats. >> >> I think Sturlas idea to find a random seed that differentiates before >> and after will be better for numpy, and using only a small sample size >> e.g. N=1000, since it's pretty fast. But since I don't have an >> unpatched numpy version available right now, I cannot do this. > > Done. Thanks for the fixes and tests. > > Chuck > Thanks for taking care of this. I will run my scipy.stats.distribution test over it before 1.3 is released and enable the tests in scipy trunk after the release. Josef ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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 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 use multithreading for multiple FFTs in parallel >> (threading.Thread are ok, not special compilation needed). >> >> 3) Is there any reason numpy.fft does not have dct? If not, I'd suggest >> addition of numpy.fft.dct and numpy.fft.idct. >> >> 4) Regarding ticket #400: Cython now makes this easy. NumPy's FFTs should >> be exposed to C extesions without calling back to Python. >> >> >> Can I open a ticket for this and take care of it? At least 1, 2 and 4 >> should only take me an hour or so to write, so it might even be ready for >> 1.3.0. >> > > 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. > On the reentrant bit, IIRC fftpack builds a table of sin/cos. It might be worth checking/making that thread safe. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 this. I think the prngs should use fixed seeds known to pass > > the test. Depending on confidence intervals in the units tests is really, > > really bad style. Tests should be deterministic. > > > > S.M. > > > > The hypergeometric tests are on the support of the distribution and > should never fail. And the outcome is not random. > > The test of logser with N = 10 also should be pretty exact and > fail only with very low probability in the patched version. But again > this is testet in scipy.stats. > > I think Sturlas idea to find a random seed that differentiates before > and after will be better for numpy, and using only a small sample size > e.g. N=1000, since it's pretty fast. But since I don't have an > unpatched numpy version available right now, I cannot do this. > Done. Thanks for the fixes and tests. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 pass > the test. Depending on confidence intervals in the units tests is really, > really bad style. Tests should be deterministic. > > S.M. > The hypergeometric tests are on the support of the distribution and should never fail. And the outcome is not random. The test of logser with N = 10 also should be pretty exact and fail only with very low probability in the patched version. But again this is testet in scipy.stats. I think Sturlas idea to find a random seed that differentiates before and after will be better for numpy, and using only a small sample size e.g. N=1000, since it's pretty fast. But since I don't have an unpatched numpy version available right now, I cannot do this. Josef ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 to pass > the test. Depending on confidence intervals in the units tests is really, > really bad style. Tests should be deterministic. > Good idea... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Enhancements for NumPy's FFTs
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_lite did release the GIL, it would allow functions in > numpy.fft to use multithreading for multiple FFTs in parallel > (threading.Thread are ok, not special compilation needed). > > 3) Is there any reason numpy.fft does not have dct? If not, I'd suggest > addition of numpy.fft.dct and numpy.fft.idct. > > 4) Regarding ticket #400: Cython now makes this easy. NumPy's FFTs should > be exposed to C extesions without calling back to Python. > > > Can I open a ticket for this and take care of it? At least 1, 2 and 4 > should only take me an hour or so to write, so it might even be ready for > 1.3.0. > 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. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
> 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 tests is really, really bad style. Tests should be deterministic. S.M. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Enhancements for NumPy's FFTs
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 use multithreading for multiple FFTs in parallel (threading.Thread are ok, not special compilation needed). 3) Is there any reason numpy.fft does not have dct? If not, I'd suggest addition of numpy.fft.dct and numpy.fft.idct. 4) Regarding ticket #400: Cython now makes this easy. NumPy's FFTs should be exposed to C extesions without calling back to Python. Can I open a ticket for this and take care of it? At least 1, 2 and 4 should only take me an hour or so to write, so it might even be ready for 1.3.0. Sturla Molden ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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
>> >>
>> >> 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 frequency counts should be close to theoretical numbers
>> >> with this large sample
>>
>> Sorry, cut and paste error, the second case is k=2
>> for k=1 the unpatched version undersamples, for k=2 the unpatched
>> version oversamples, that's the reason for the inequalities; the
>> bugfix should reallocate them correctly.
>>
>> for several runs with N = 10, I get with the patched version
>>
>> >>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==1) / float(N)
>> in range: 0.4951, 0.4984# unpatched version is too small
>>
>> >>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==2) / float(N)
>> in range: 0.1980, 0.2001 # unpatched version is too large
>>
>> with constraints a bit more tight, it should be:
>>
>> >> assert np.sum(rvsn==1) / float(N) > 0.49 # theoretical: 0.49706795
>> >> assert np.sum(rvsn==2) / float(N) < 0.205 # theoretical: 0.19882718
>>
>
> OK. One more question: how often do the tests fail? I want to include a
> note to repeat testing if the test fails.
>
Mind, I don't want to test the distribution in detail, I just want something
that fails with the current code and passes with the new.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 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 frequency counts should be close to theoretical numbers
> >> with this large sample
>
> Sorry, cut and paste error, the second case is k=2
> for k=1 the unpatched version undersamples, for k=2 the unpatched
> version oversamples, that's the reason for the inequalities; the
> bugfix should reallocate them correctly.
>
> for several runs with N = 10, I get with the patched version
>
> >>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==1) / float(N)
> in range: 0.4951, 0.4984# unpatched version is too small
>
> >>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==2) / float(N)
> in range: 0.1980, 0.2001 # unpatched version is too large
>
> with constraints a bit more tight, it should be:
>
> >> assert np.sum(rvsn==1) / float(N) > 0.49 # theoretical: 0.49706795
> >> assert np.sum(rvsn==2) / float(N) < 0.205 # theoretical: 0.19882718
>
OK. One more question: how often do the tests fail? I want to include a note
to repeat testing if the test fails.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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
>> N = 10
>> rvsn = np.random.logseries(pr,size=N)
>> # these two frequency counts should be close to theoretical numbers
>> with this large sample
Sorry, cut and paste error, the second case is k=2
for k=1 the unpatched version undersamples, for k=2 the unpatched
version oversamples, that's the reason for the inequalities; the
bugfix should reallocate them correctly.
for several runs with N = 10, I get with the patched version
>>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==1) / float(N)
in range: 0.4951, 0.4984# unpatched version is too small
>>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==2) / float(N)
in range: 0.1980, 0.2001 # unpatched version is too large
with constraints a bit more tight, it should be:
>> assert np.sum(rvsn==1) / float(N) > 0.49 # theoretical: 0.49706795
>> assert np.sum(rvsn==2) / float(N) < 0.205 # theoretical: 0.19882718
Josef
>> }}}
>
> I just see one frequency count here. Do you mean that the frequency count
> should fall in that range with some probability?
>
> Chuck
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 frequency counts should be close to theoretical numbers
> with this large sample
> assert np.sum(rvsn==1) / float(N) > 0.45 # theoretical: 0.49706795
> assert np.sum(rvsn==1) / float(N) < 0.23 # theoretical: 0.19882718
> }}}
>
I just see one frequency count here. Do you mean that the frequency count
should fall in that range with some probability?
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
> 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
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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? Would it help if you had commit privileges
> in
> >> Numpy?
> >
> > Yes, I was about to suggest giving Josef commit access to numpy, I
> > unfortunately won't have much time to do anything but release tasks in
> > the next few days, including review. If someone else (you :) ) can
> > review the changes, before they go in, then there is no reason why
> > they can't go in - assuming they come in very soon,
> >
> > David
>
> The correctness of the random numbers are tested in scipy.stats. They
> are not tested in np.random.tests.
> Currently, I have the test for logser disabled because it always
> fails, for hypergeometric, I picked parameters for which the random
> numbers are correct. Once the bugs are fixed, I can add or re-enable
> the tests for the current failures.
>
> Here are some tests, that should fail with the current trunk and pass
> after the fix. I don't have an unpatched version of numpy available
> right now, but these are the cases that initially showed the bugs. Can
> you verify that they fail on current or recent trunk? They don't fail
> on my patched version. But it has been some time ago that I did this
> and I would need to check the details again if these tests don't fail
> on the current trunk.
>
> {{{
> 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 frequency counts should be close to theoretical numbers
> with this large sample
> assert np.sum(rvsn==1) / float(N) > 0.45 # theoretical: 0.49706795
> assert np.sum(rvsn==1) / float(N) < 0.23 # theoretical: 0.19882718
> }}}
>
>
I can verify that these currently fail on my machine. I'll make regression
tests out of them and then commit the fixes.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 this to allow big files to be memory mapped on 32 bit systems. > Only a minor change is required: > > if float(sys.version[:3]) > 2.5: > > bytes = bytes - offset > > mm = mmap.mmap(fid.fileno(), bytes, access=acc, offset=offset) > > self = ndarray.__new__(subtype, shape, dtype=descr, buffer=mm, > offset=0, order=order) > > else: > > mm = mmap.mmap(fid.fileno(), bytes, access=acc) > > self = ndarray.__new__(subtype, shape, dtype=descr, buffer=mm, > offset=offset, order=order) > > > Instead of just: > > mm = mmap.mmap(fid.fileno(), bytes, access=acc) > > self = ndarray.__new__(subtype, shape, dtype=descr, buffer=mm, > offset=offset, order=order) > > Can you open a ticket for this? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
>
> 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 is required:
if float(sys.version[:3]) > 2.5:
bytes = bytes - offset
mm = mmap.mmap(fid.fileno(), bytes, access=acc, offset=offset)
self = ndarray.__new__(subtype, shape, dtype=descr, buffer=mm,
offset=0, order=order)
else:
mm = mmap.mmap(fid.fileno(), bytes, access=acc)
self = ndarray.__new__(subtype, shape, dtype=descr, buffer=mm,
offset=offset, order=order)
Instead of just:
mm = mmap.mmap(fid.fileno(), bytes, access=acc)
self = ndarray.__new__(subtype, shape, dtype=descr, buffer=mm,
offset=offset, order=order)
Reagards,
Sturla Molden
__all__ = ['memmap']
import warnings
from numeric import uint8, ndarray, dtype
import sys
dtypedescr = dtype
valid_filemodes = ["r", "c", "r+", "w+"]
writeable_filemodes = ["r+","w+"]
mode_equivalents = {
"readonly":"r",
"copyonwrite":"c",
"readwrite":"r+",
"write":"w+"
}
class memmap(ndarray):
"""
Create a memory-map to an array stored in a file on disk.
Memory-mapped files are used for accessing small segments of large files
on disk, without reading the entire file into memory. Numpy's
memmap's are array-like objects. This differs from Python's ``mmap``
module, which uses file-like objects.
Parameters
--
filename : string or file-like object
The file name or file object to be used as the array data
buffer.
dtype : data-type, optional
The data-type used to interpret the file contents.
Default is `uint8`
mode : {'r+', 'r', 'w+', 'c'}, optional
The file is opened in this mode:
+--+-+
| 'r' | Open existing file for reading only.|
+--+-+
| 'r+' | Open existing file for reading and writing. |
+--+-+
| 'w+' | Create or overwrite existing file for reading and writing. |
+--+-+
| 'c' | Copy-on-write: assignments affect data in memory, but |
| | changes are not saved to disk. The file on disk is |
| | read-only. |
+--+-+
Default is 'r+'.
offset : integer, optional
In the file, array data starts at this offset. `offset` should be
a multiple of the byte-size of `dtype`. Requires `shape=None`.
The default is 0.
shape : tuple, optional
The desired shape of the array. By default, the returned array will be
1-D with the number of elements determined by file size and data-type.
order : {'C', 'F'}, optional
Specify the order of the ndarray memory layout: C (row-major) or
Fortran (column-major). This only has an effect if the shape is
greater than 1-D. The defaullt order is 'C'.
Methods
---
close
Close the memmap file.
flush
Flush any changes in memory to file on disk.
When you delete a memmap object, flush is called first to write
changes to disk before removing the object.
Notes
-
The memmap object can be used anywhere an ndarray is accepted.
Given a memmap ``fp``, ``isinstance(fp, numpy.ndarray)`` returns
``True``.
Notes
-
Memory-mapped arrays use the the Python memory-map object which
(prior to Python 2.5) does not allow files to be larger than a
certain size depending on the platform. This size is always < 2GB
even on 64-bit systems.
Examples
>>> data = np.arange(12, dtype='float32')
>>> data.resize((3,4))
This example uses a temporary file so that doctest doesn't write
files to your directory. You would use a 'normal' filename.
>>> from tempfile import mkdtemp
>>> import os.path as path
>>> filename = path.join(mkdtemp(), 'newfile.dat')
Create a memmap with dtype and shape that matches our data:
>>> fp = np.memmap(filename, dtype='float32', mode='w+', shape=(3,4))
>>> fp
memmap([[ 0., 0., 0., 0.],
[ 0., 0., 0., 0.],
[ 0., 0., 0., 0.]], dtype=float32)
Write data to memmap array:
>>> fp[:] = data[:]
>>> fp
memmap([[ 0., 1., 2., 3.],
[ 4., 5., 6., 7.],
[ 8., 9., 10., 11.]], dtype=float32)
Deletion flushes m
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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, I was about to suggest giving Josef commit access to numpy, I
> unfortunately won't have much time to do anything but release tasks in
> the next few days, including review. If someone else (you :) ) can
> review the changes, before they go in, then there is no reason why
> they can't go in - assuming they come in very soon,
>
> David
The correctness of the random numbers are tested in scipy.stats. They
are not tested in np.random.tests.
Currently, I have the test for logser disabled because it always
fails, for hypergeometric, I picked parameters for which the random
numbers are correct. Once the bugs are fixed, I can add or re-enable
the tests for the current failures.
Here are some tests, that should fail with the current trunk and pass
after the fix. I don't have an unpatched version of numpy available
right now, but these are the cases that initially showed the bugs. Can
you verify that they fail on current or recent trunk? They don't fail
on my patched version. But it has been some time ago that I did this
and I would need to check the details again if these tests don't fail
on the current trunk.
{{{
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 frequency counts should be close to theoretical numbers
with this large sample
assert np.sum(rvsn==1) / float(N) > 0.45 # theoretical: 0.49706795
assert np.sum(rvsn==1) / float(N) < 0.23 # theoretical: 0.19882718
}}}
About commit access: it would be convenient to have it, but not
necessary since there are only a few things that I can contribute to
numpy directly.
Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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, > > David > ___ > 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] Reminder: code freeze for bet at the end of the WE
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? > > Yes, I was about to suggest giving Josef commit access to numpy, I > unfortunately won't have much time to do anything but release tasks in > the next few days, including review. If someone else (you :) ) can > review the changes, before they go in, then there is no reason why > they can't go in - assuming they come in very soon, > The fixes are both one-liners. Testing... I wonder if tests for things like random distributions and computational accuracy of special functions shouldn't be separate scripts. They can be large file, ala special functions, or time consuming and it doesn't help that parts are needed by both scipy and numpy. I don't feel competent to say that the fixes are correct, I'll trust Josef in that regard. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 unfortunately won't have much time to do anything but release tasks in the next few days, including review. If someone else (you :) ) can review the changes, before they go in, then there is no reason why they can't go in - assuming they come in very soon, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 corresponds to 15th March midnight Pacific time), > > > 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? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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, > > David Any chance for tickets 921 and 923. I would like to remove some test failures in the random numbers in scipy.stats.distributions. Josef ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Build Failure on IA64
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 numpy maintainers with information about your >> platform (OS, CPU and compiler) >> >> This is on a linux machine using gcc. Here is the processor information: >> >> processor : 0 >> vendor : GenuineIntel >> arch : IA-64 >> family : Itanium 2 >> model : 2 >> revision : 1 >> archrev : 0 >> features : branchlong >> cpu number : 0 >> cpu regs : 4 >> cpu MHz : 1500.00 >> itc MHz : 1500.00 >> BogoMIPS : 2244.60 >> siblings : 1 > > OK, I added some macros in r6662, can you give it a shot? Do you know if > folks are using other OSs or compilers on that system? > > Chuck > Worked just fine. I don't think anyone is using another OS on this system. As for other compilers, I do have reason to believe there are other others on there, however I don't use them and don't know what they are. I'll try to ask around on Monday. Patrick -- Patrick Marsh Graduate Research Assistant School of Meteorology University of Oklahoma http://www.patricktmarsh.com ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Reminder: code freeze for bet at the end of the WE
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 mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
