[Numpy-discussion] Has IPython been useful to you? Please let me know...

Hi all, [ apologies for the semi-spam, I'll keep this brief and expect all replies off-list ] IPython is a project that many of you on this list are likely to use in your daily work, either directly or indirectly (if you've embedded it or used it as a component of some other system). I would sim

Re: [Numpy-discussion] Superfluous array transpose (cf. ticket #1054)

Sun, 15 Mar 2009 19:57:10 +0100, Sturla Molden wrote: > Regarding ticket #1054. What is the reason for this strange behaviour? > a = np.zeros((10,10),order='F') a.flags > C_CONTIGUOUS : False > F_CONTIGUOUS : True > OWNDATA : True > WRITEABLE : True > ALIGNED : True > UPDATE

Re: [Numpy-discussion] Py_ssize_t

On Mon, Mar 16, 2009 at 4:10 AM, Charles R Harris wrote: > Some of the calls to the python c-api have been changed to use Py_ssize_t. > As Py_ssize_t was not available in Python 2.4 I wonder if we check if it is > defined and set it to int if not. Yes, we do, in ndarrayobject.h > Also, are we ru

[Numpy-discussion] Py_ssize_t

Some of the calls to the python c-api have been changed to use Py_ssize_t. As Py_ssize_t was not available in Python 2.4 I wonder if we check if it is defined and set it to int if not. Also, are we running tests on Python 2.4 for the release? Chuck ___ N

[Numpy-discussion] Superfluous array transpose (cf. ticket #1054)

Regarding ticket #1054. What is the reason for this strange behaviour? >>> a = np.zeros((10,10),order='F') >>> a.flags C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False >>> (a+1).flags C_CONTIGUOUS : True F_CONTIGUOUS : Fa

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

> Well, that's nearly as good. (Though submitting a single svn diff > containing all changes could have been a bit more easy to handle than > separate patches for each file. But a small nitpick only.) The problem is I am really bad at using these tools. I have TortoiseSVN installed, but no idea h

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

Sun, 15 Mar 2009 17:48:51 +0100, Sturla Molden wrote: >> Mon, 16 Mar 2009 00:33:28 +0900, David Cournapeau wrote: >> >> Also, you could post the patch on the http://codereview.appspot.com >> site. Then it would be easier to both review and to keep track of its >> revisions > > I have posted the f

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

> Mon, 16 Mar 2009 00:33:28 +0900, David Cournapeau wrote: > > Also, you could post the patch on the http://codereview.appspot.com site. > Then it would be easier to both review and to keep track of its > revisions I have posted the files here: http://projects.scipy.org/numpy/ticket/1055 Sturla

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

> Would it be possible to make the changes as a patch (svn diff) - this > makes things easier to review. I've added diff files to ticket #1055. > Yes, I would be more comfortable without them (for 1.3). This is > typically the kind of small changes which can be a PITA to deal with > just before

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

Mon, 16 Mar 2009 00:33:28 +0900, David Cournapeau wrote: > Sturla Molden wrote: >> >> There is a version of fftpack_litemodule.c, fftpack.c and fftpack.h >> that does this attached to ticket #1055. The two important changes are >> releasing the GIL and using npy_intp for 64 bit support. >> >>

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

Sturla Molden wrote: > > There is a version of fftpack_litemodule.c, fftpack.c and fftpack.h that > does this attached to ticket #1055. The two important changes are > releasing the GIL and using npy_intp for 64 bit support. > Would it be possible to make the changes as a patch (svn diff) - thi

Re: [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

Re: [Numpy-discussion] suggestion for generalizing numpy functions

Hi Travis, On Mon, Mar 9, 2009 at 6:08 PM, Travis E. Oliphant wrote: > Darren Dale wrote: > > On Mon, Mar 9, 2009 at 9:50 AM, Darren Dale > > wrote: > > > > I spent some time over the weekend fixing a few bugs in numpy that > > were exposed when attempting to u

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

On Sun, Mar 15, 2009 at 12:46 PM, Charles R Harris wrote: > > > 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

Re: [Numpy-discussion] Enhancements for NumPy's FFTs

On Sun, Mar 15, 2009 at 5:16 AM, 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_l