Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 11:00 PM, David Cournapeau wrote: > Charles R Harris wrote: > > > > > > > > Just to be clear, there are *already* macros in the ndarrayobject.h file > > that aren't py3k compatible. How do you propose to fix those? > > I don't understand the connection with the public vs pr

Re: [Numpy-discussion] numpy 2.0, what else to do?

Charles R Harris wrote: > > > > Just to be clear, there are *already* macros in the ndarrayobject.h file > that aren't py3k compatible. How do you propose to fix those? I don't understand the connection with the public vs private issue. If the py3k compatibility header is to be shared by seve

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 10:35 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Mon, Feb 15, 2010 at 10:19 PM, David Cournapeau > wrote: > >> Charles R Harris wrote: >> > >> > >> > On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau < >> da...@silveregg.co.jp >> >

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 10:19 PM, David Cournapeau wrote: > Charles R Harris wrote: > > > > > > On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau > > wrote: > > > > Charles R Harris wrote: > > > > > > > > > On Mon, Feb 15, 2010 at 3:58 PM, Charles

Re: [Numpy-discussion] numpy 2.0, what else to do?

Charles R Harris wrote: > > > On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau > wrote: > > Charles R Harris wrote: > > > > > > On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris > > mailto:charlesr.har...@gmail.com> >

Re: [Numpy-discussion] numpy-1.4.0 no longer available for download?

Ahhh I see this is due to the ABI change, sorry for the noise. Cheers Adam On Mon, Feb 15, 2010 at 21:00, Adam Mercer wrote: > Hi > > According to the NumPy download page > the latest available > version is 1.3.0, what happened to 1.4.0? Apologies

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau wrote: > Charles R Harris wrote: > > > > > > On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris > > mailto:charlesr.har...@gmail.com>> wrote: > > > > > > > > On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau > > mailto:courn...@gmail.com>> w

Re: [Numpy-discussion] Why does np.nan{min, max} clobber my array mask?

On Mon, Feb 15, 2010 at 8:35 PM, Pierre GM wrote: > On Feb 15, 2010, at 8:51 PM, David Carmean wrote: >> On Sun, Feb 14, 2010 at 03:22:04PM -0500, Pierre GM wrote: >> >>> >>> I'm sorry, I can't follow you. Can you post a simpler self-contained >>> example I can play with ? >>> Why using np.nanmin

Re: [Numpy-discussion] numpy 2.0, what else to do?

Charles R Harris wrote: > > > On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris > mailto:charlesr.har...@gmail.com>> wrote: > > > > On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau > mailto:courn...@gmail.com>> wrote: > > On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris >

[Numpy-discussion] numpy-1.4.0 no longer available for download?

Hi According to the NumPy download page the latest available version is 1.3.0, what happened to 1.4.0? Apologies if I've missed some announcement. Cheers Adam ___ NumPy-Discussion mailing list NumPy-Discus

Re: [Numpy-discussion] Why does np.nan{min, max} clobber my array mask?

On Feb 15, 2010, at 8:51 PM, David Carmean wrote: > On Sun, Feb 14, 2010 at 03:22:04PM -0500, Pierre GM wrote: > >> >> I'm sorry, I can't follow you. Can you post a simpler self-contained example >> I can play with ? >> Why using np.nanmin/max ? These functions are designed for ndarrays, to >>

Re: [Numpy-discussion] Why does np.nan{min, max} clobber my array mask?

On Sun, Feb 14, 2010 at 03:22:04PM -0500, Pierre GM wrote: > > I'm sorry, I can't follow you. Can you post a simpler self-contained example > I can play with ? > Why using np.nanmin/max ? These functions are designed for ndarrays, to avoid > using a masked array: can't you just use min/max on t

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris wrote: > > > On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau wrote: > >> On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris >> wrote: >> > >> > >> > On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau >> > wrote: >> >> >> >> On Tue, Feb 16, 2010

Re: [Numpy-discussion] Python 3 porting

ma, 2010-02-15 kello 15:51 -0700, Charles R Harris kirjoitti: [clip] > A lot of the remaining failures are of this sort: > > x: array([b'pi', b'pi', b'pi', b'four', b'five'], > dtype='|S8') > y: array(['pi', 'pi', 'pi', 'four', 'five'], > dtype=' > > This looks fixable by specify

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau wrote: > On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris > wrote: > > > > > > On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau > > wrote: > >> > >> On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris > >> wrote: > >> > >> > > >> > I was wonderi

Re: [Numpy-discussion] Python 3 porting

On Mon, Feb 15, 2010 at 3:19 PM, Charles R Harris wrote: > > > On Mon, Feb 15, 2010 at 3:05 PM, Pauli Virtanen wrote: > >> ma, 2010-02-15 kello 21:58 +0200, Pauli Virtanen kirjoitti: >> [clip] >> > > Program received signal SIGABRT, Aborted. >> > > 0x7fff84e1efe6 in __kill () >> > > (gdb) bt

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris wrote: > > > On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau > wrote: >> >> On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris >> wrote: >> >> > >> > I was wondering about that. Why do we have a private include directory? >> > Would it make more

Re: [Numpy-discussion] Python 3 porting

On Mon, Feb 15, 2010 at 3:05 PM, Pauli Virtanen wrote: > ma, 2010-02-15 kello 21:58 +0200, Pauli Virtanen kirjoitti: > [clip] > > > Program received signal SIGABRT, Aborted. > > > 0x7fff84e1efe6 in __kill () > > > (gdb) bt > > > #0 0x7fff84e1efe6 in __kill () > > > #1 0x7fff84ebfe32

Re: [Numpy-discussion] Python 3 porting

ma, 2010-02-15 kello 21:58 +0200, Pauli Virtanen kirjoitti: [clip] > > Program received signal SIGABRT, Aborted. > > 0x7fff84e1efe6 in __kill () > > (gdb) bt > > #0 0x7fff84e1efe6 in __kill () > > #1 0x7fff84ebfe32 in abort () > > #2 0x0001000cd715 in Py_FatalError () > > #3 0x0

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau wrote: > On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris > wrote: > > > > > I was wondering about that. Why do we have a private include directory? > > Would it make more sense to move it to core/include/numpy/private. > > No, the whole point is

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris wrote: > > I was wondering about that. Why do we have a private include directory? > Would it make more sense to move it to core/include/numpy/private. No, the whole point is to avoid other packages to include that by mistake, to avoid namespace

Re: [Numpy-discussion] Python 3 porting

On 15 February 2010 23:11, Charles R Harris wrote: >> OSX, 64-bit with (I'm assuming) UCS2 (since I didn't specify the UCS4 >> variant when building).  Is there an easy way to check the unicode >> width? >> > I found it in the pyconfig.h file: > > pyconfig.h:#define Py_UNICODE_SIZE 4' Aha! #defi

Re: [Numpy-discussion] Python 3 porting

2010/2/15 Stéfan van der Walt > On 15 February 2010 21:58, Pauli Virtanen wrote: > > ma, 2010-02-15 kello 21:41 +0200, Stéfan van der Walt kirjoitti: > > [clip] > >> .Fatal Python error: Inconsistent interned string > >> state. > >> > > The platform is OSX -- 32 or 64 bits? Is yo

Re: [Numpy-discussion] Python 3 porting

On 15 February 2010 21:58, Pauli Virtanen wrote: > ma, 2010-02-15 kello 21:41 +0200, Stéfan van der Walt kirjoitti: > [clip] >> .Fatal Python error: Inconsistent interned string >> state. >> > The platform is OSX -- 32 or 64 bits? Is your Python unicode narrow or > wide? Which test

Re: [Numpy-discussion] Python 3 porting

On Mon, Feb 15, 2010 at 12:58 PM, Pauli Virtanen wrote: > ma, 2010-02-15 kello 21:41 +0200, Stéfan van der Walt kirjoitti: > [clip] > > > On Python 3.1, the numpymemoryview_init is a stub function that does > > > nothing. I guess this is another single-file compilation issue -- the > > > new file

Re: [Numpy-discussion] Python 3 porting

ma, 2010-02-15 kello 21:41 +0200, Stéfan van der Walt kirjoitti: [clip] > > On Python 3.1, the numpymemoryview_init is a stub function that does > > nothing. I guess this is another single-file compilation issue -- the > > new file should be included in multiarraymodule_onefile.c. Should be > > fix

Re: [Numpy-discussion] Python 3 porting

2010/2/15 Stéfan van der Walt : > Thanks, it works now. Progress: the unit test suite starts to run, but fails soon after. .Fatal Python error: Inconsistent interned string state. Program received signal SIGABRT, Aborted. 0x7fff84e1efe6 in __kill () (gdb) bt #0 0x7fff84

Re: [Numpy-discussion] Python 3 porting

On 15 February 2010 21:19, Pauli Virtanen wrote: > Oh crap, nothing seems to work for anyone else ;) Don't speak too soon: we have import! > On Python 3.1, the numpymemoryview_init is a stub function that does > nothing. I guess this is another single-file compilation issue -- the > new file sho

Re: [Numpy-discussion] Python 3 porting

ma, 2010-02-15 kello 21:07 +0200, Stéfan van der Walt kirjoitti: [clip] > After your latest changes, numpy builds on OSX, although importing is > still broken: > > from . import multiarray > ImportError: > dlopen(/Users/stefan/lib/python3.1/site-packages/numpy/core/multiarray.so, > 2): Symbol

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 12:03 PM, Pauli Virtanen wrote: > su, 2010-02-14 kello 11:51 -0700, Charles R Harris kirjoitti: > [clip] > > There are more - grep -r ob_type numpy/* - how do you want to go about > > fixing these things? > > self->ob_type is fine if `self` is a plain PyObject* and not a s

Re: [Numpy-discussion] Python 3 porting

Hi Pauli Well done! You and Charles have made huge strides since last I looked at the problem. After your latest changes, numpy builds on OSX, although importing is still broken: from . import multiarray ImportError: dlopen(/Users/stefan/lib/python3.1/site-packages/numpy/core/multiarray.so

Re: [Numpy-discussion] numpy 2.0, what else to do?

su, 2010-02-14 kello 11:51 -0700, Charles R Harris kirjoitti: [clip] > There are more - grep -r ob_type numpy/* - how do you want to go about > fixing these things? self->ob_type is fine if `self` is a plain PyObject* and not a subclass pointer. The issue in changing all of them to Py_TYPE is tha

Re: [Numpy-discussion] Python 3 porting

On Mon, Feb 15, 2010 at 10:55 AM, Pauli Virtanen wrote: > ma, 2010-02-15 kello 10:18 -0600, Bruce Southey kirjoitti: > [clip] >> Is there a correct way to get Python3.1 to find the relative path on Linux? >> I can change the import statement to work but I do not think that is viable. > > You need

Re: [Numpy-discussion] Python 3 porting

On Mon, Feb 15, 2010 at 10:55 AM, Pauli Virtanen wrote: > ma, 2010-02-15 kello 10:23 -0700, Charles R Harris kirjoitti: > [clip] > > Segfaults: > > > > test_multiarray.TestNewBufferProtocol.test_export_simple_1d ... FAIL > > test_multiarray.TestNewBufferProtocol.test_export_simple_nd ... ok > > t

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 10:04 AM, David Huard wrote: > In the list of things to do, I suggest deleting completely the old > histogram behaviour and the `new` keyword. +1 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/

Re: [Numpy-discussion] Python 3 porting

ma, 2010-02-15 kello 10:23 -0700, Charles R Harris kirjoitti: [clip] > Segfaults: > > test_multiarray.TestNewBufferProtocol.test_export_simple_1d ... FAIL > test_multiarray.TestNewBufferProtocol.test_export_simple_nd ... ok > test_multiarray.TestNewBufferProtocol.test_export_subarray ... FAIL > tes

Re: [Numpy-discussion] Python 3 porting

On Mon, Feb 15, 2010 at 9:55 AM, Pauli Virtanen wrote: > ma, 2010-02-15 kello 10:18 -0600, Bruce Southey kirjoitti: > [clip] > > Is there a correct way to get Python3.1 to find the relative path on > Linux? > > I can change the import statement to work but I do not think that is > viable. > > You

Re: [Numpy-discussion] Python 3 porting

ma, 2010-02-15 kello 10:18 -0600, Bruce Southey kirjoitti: [clip] > Is there a correct way to get Python3.1 to find the relative path on Linux? > I can change the import statement to work but I do not think that is viable. You need to use relative imports. 2to3 should be able to take care of this.

Re: [Numpy-discussion] cov

> On Mon, Feb 15, 2010 at 8:42 AM, Alan G Isaac wrote: >> > 1. Should `numpy.cov` use `ddof` instead of `bias`, >> > like `std` and `mean`? On 2/15/2010 9:31 AM, josef.p...@gmail.com wrote: > +1 > > (I just checked scipy stats and the usage of bias versus ddof is also > inconsistent. Is there

[Numpy-discussion] numpy 1.4 distutils install_clib when there are none?

I was doing the final checks for a new release of statsmodels and ran into a problem with install_clib I do "setup.py install" from the source or sdist of scikits.statsmodels and the install breaks with this message at the end running install_clib No module named msvccompiler in numpy.distutils;

Re: [Numpy-discussion] Python 3 porting

On 02/15/2010 12:55 AM, Pauli Virtanen wrote: > ma, 2010-02-15 kello 00:38 +0100, Xavier Gnata kirjoitti: > >> Ok! >> git clone git://github.com/pv/numpy-work.git >> git checkout origin/py3k >> NPY_SEPARATE_BUILD=1 python3.1 setup.py build >> >> but now it fails during the build: >> >> In file

Re: [Numpy-discussion] numpy 2.0, what else to do?

In the list of things to do, I suggest deleting completely the old histogram behaviour and the `new` keyword. The `new` keyword argument has raised a deprecation warning since 1.3 and was set for removal in 1.4. David H. On Mon, Feb 15, 2010 at 9:21 AM, Robert Kern wrote: > On Mon, Feb 15, 2010

Re: [Numpy-discussion] cov

On Mon, Feb 15, 2010 at 8:42 AM, Alan G Isaac wrote: > 1. Should `numpy.cov` use `ddof` instead of `bias`, > like `std` and `mean`? +1 (I just checked scipy stats and the usage of bias versus ddof is also inconsistent. Is there an interpretation for a general ddof for skew and kurtosis, or does

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 05:24, David Cournapeau wrote: > David Cournapeau wrote: > >> >> It is always an ABI change, but is mostly backward compatible (which is >> neither the case of matplotlib or scipy AFAIK). > > This sentence does not make any sense: I meant that it is backward > compatible fr

[Numpy-discussion] cov

1. Should `numpy.cov` use `ddof` instead of `bias`, like `std` and `mean`? 2. Should the docs for scipy.cov state that it is deprecated? http://docs.scipy.org/scipy/docs/scipy.stats.stats.cov/#scipy-stats-cov (Use raises a deprecation warning.) Thanks, Alan Isaac _

Re: [Numpy-discussion] Unpleasant behavior with poly1d and numpy scalar multiplication

Charles R Harris gmail.com> writes: > I was also thinking that someone might want to provide a better display at > some point, drawing on a canvas, for instance. And what happens when the > degree gets up over 100, which is quite reasonable with the Cheybshev > polynomials? There may well be be

Re: [Numpy-discussion] numpy 2.0, what else to do?

David Cournapeau wrote: > > It is always an ABI change, but is mostly backward compatible (which is > neither the case of matplotlib or scipy AFAIK). This sentence does not make any sense: I meant that it is backward compatible from an ABI POV, unless the structure PyArray_Array itself is inc

Re: [Numpy-discussion] numpy 2.0, what else to do?

Sebastian Haase wrote: > On Mon, Feb 15, 2010 at 11:17 AM, Francesc Alted wrote: >> A Sunday 14 February 2010 13:40:17 Stéfan van der Walt escrigué: >>> On 14 February 2010 01:23, David Cournapeau wrote: I think that there should be absolutely no change whatsoever, for two reasons: - th

Re: [Numpy-discussion] numpy 2.0, what else to do?

On Mon, Feb 15, 2010 at 11:17 AM, Francesc Alted wrote: > A Sunday 14 February 2010 13:40:17 Stéfan van der Walt escrigué: >> On 14 February 2010 01:23, David Cournapeau wrote: >> > I think that there should be absolutely no change whatsoever, for two >> > reasons: - the release is in a few weeks

Re: [Numpy-discussion] numpy 2.0, what else to do?

A Sunday 14 February 2010 13:40:17 Stéfan van der Walt escrigué: > On 14 February 2010 01:23, David Cournapeau wrote: > > I think that there should be absolutely no change whatsoever, for two > > reasons: - the release is in a few weeks, it is too late to change much. > > The whole datetime issue