A Sunday 14 February 2010 13:40:17 Stéfan van der Walt escrigué:
On 14 February 2010 01:23, David Cournapeau courn...@gmail.com 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
On Mon, Feb 15, 2010 at 11:17 AM, Francesc Alted fal...@pytables.org wrote:
A Sunday 14 February 2010 13:40:17 Stéfan van der Walt escrigué:
On 14 February 2010 01:23, David Cournapeau courn...@gmail.com wrote:
I think that there should be absolutely no change whatsoever, for two
reasons: -
Sebastian Haase wrote:
On Mon, Feb 15, 2010 at 11:17 AM, Francesc Alted fal...@pytables.org wrote:
A Sunday 14 February 2010 13:40:17 Stéfan van der Walt escrigué:
On 14 February 2010 01:23, David Cournapeau courn...@gmail.com wrote:
I think that there should be absolutely no change
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
Charles R Harris charlesr.harris at 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
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
On Mon, Feb 15, 2010 at 05:24, David Cournapeau da...@silveregg.co.jp 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
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 robert.k...@gmail.com wrote:
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 included from
On Mon, Feb 15, 2010 at 8:42 AM, Alan G Isaacais...@american.edu 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.
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.
On Mon, Feb 15, 2010 at 9:55 AM, Pauli Virtanen p...@iki.fi 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.
On Mon, Feb 15, 2010 at 10:55 AM, Pauli Virtanen p...@iki.fi 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
On Mon, Feb 15, 2010 at 10:55 AM, Pauli Virtanen p...@iki.fi 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
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 that
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:
On Mon, Feb 15, 2010 at 12:03 PM, Pauli Virtanen p...@iki.fi 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
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 not
2010/2/15 Stéfan van der Walt ste...@sun.ac.za:
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
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
fixed now.
On Mon, Feb 15, 2010 at 12:58 PM, Pauli Virtanen p...@iki.fi 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
On 15 February 2010 21:58, Pauli Virtanen p...@iki.fi 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
2010/2/15 Stéfan van der Walt ste...@sun.ac.za
On 15 February 2010 21:58, Pauli Virtanen p...@iki.fi 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
On 15 February 2010 23:11, Charles R Harris charlesr.har...@gmail.com 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
On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris
charlesr.har...@gmail.com 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
On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau courn...@gmail.comwrote:
On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
I was wondering about that. Why do we have a private include directory?
Would it make more sense to move it to
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
On Mon, Feb 15, 2010 at 3:05 PM, Pauli Virtanen p...@iki.fi 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 in
On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau courn...@gmail.com
wrote:
On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
I was wondering about that. Why do we have a
On Mon, Feb 15, 2010 at 3:19 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Mon, Feb 15, 2010 at 3:05 PM, Pauli Virtanen p...@iki.fi wrote:
ma, 2010-02-15 kello 21:58 +0200, Pauli Virtanen kirjoitti:
[clip]
Program received signal SIGABRT, Aborted.
0x7fff84e1efe6 in
On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau courn...@gmail.comwrote:
On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau courn...@gmail.com
wrote:
On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris
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='U4')
This looks fixable by
On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau courn...@gmail.comwrote:
On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Feb 15, 2010 at 2:46 PM, David
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 the
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
avoid using
On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau da...@silveregg.co.jpwrote:
Charles R Harris wrote:
On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris
charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote:
On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau
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 ramer...@gmail.com wrote:
Hi
According to the NumPy download page
http://sourceforge.net/projects/numpy/files/ the latest available
version is 1.3.0, what happened to
Charles R Harris wrote:
On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau da...@silveregg.co.jp
mailto:da...@silveregg.co.jp wrote:
Charles R Harris wrote:
On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris
charlesr.har...@gmail.com
On Mon, Feb 15, 2010 at 10:19 PM, David Cournapeau da...@silveregg.co.jpwrote:
Charles R Harris wrote:
On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau da...@silveregg.co.jp
mailto:da...@silveregg.co.jp wrote:
Charles R Harris wrote:
On Mon, Feb 15, 2010
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
da...@silveregg.co.jpwrote:
Charles R Harris wrote:
On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau
da...@silveregg.co.jp
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 several
On Mon, Feb 15, 2010 at 11:00 PM, David Cournapeau da...@silveregg.co.jpwrote:
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
42 matches
Mail list logo
