On 10/3/07, Perry Greenfield [EMAIL PROTECTED] wrote:
On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote:
On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote:
This should return an error and not silently truncate to int.
Why do you say that? The current behaviour is
To follow on to my previous posting on this topic given Robert's
response.
As I said previously, I was never strongly committed to one approach
or the other. But since the v1 release has been made, I think more
care needs to be given to consideration of proposals like this before
actually
Shouldn't x**0 be boolean for a boolean matrix?
Cheers,
Alan Isaac
import numpy
numpy.__version__
'1.0.3.1'
x = numpy.mat('1 1;1 0',dtype='bool')
x**0
matrix([[ 1., 0.],
[ 0., 1.]])
x**1
matrix([[ True, True],
[ True, False]], dtype=bool)
x**2
matrix([[ True, True],
On Wed, Oct 03, 2007 at 11:12:07AM -0400, Perry Greenfield wrote:
On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote:
On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote:
This should return an error and not silently truncate to int.
Why do you say that? The current behaviour
On Oct 3, 2007, at 1:35 PM, Stefan van der Walt wrote:
We certainly can't change it now (just imagine all the code out
there
that will break); but I personally don't think it is a big problem.
I disagree. If people are willing to change the Class API of numpy
to be
consistent with
Stefan van der Walt wrote:
The current behavior is consistent and well
defined:
a[x] == a[int(x)]
This is all possible because of PEP 357:
http://www.python.org/dev/peps/pep-0357/
However, when I read this from the PEP:
It is not possible to use the nb_int (and __int__ special method)
for
On 10/3/07, Christopher Barker [EMAIL PROTECTED] wrote:
Stefan van der Walt wrote:
The current behavior is consistent and well
defined:
a[x] == a[int(x)]
This is all possible because of PEP 357:
I think that the current behavior has always been possible; arbitrary
objects can be passed
Timothy Hochberg wrote:
As I understand it, the whole point of PEP-357 was to allow the coercion
of int-like things (numpy.int32 say, or your own private integerish
class) to be used as indices without also allowing things that aren't
integers, but that can be coerced to integers (floats for
On 10/3/07, Perry Greenfield [EMAIL PROTECTED] wrote:
2) API changes should only be made in major releases, not minor
releases (IMHO).
+1
3) Greater time should be provided to accommodate the transition. For
example, there should not be deprecation warnings in the first
version that this
On 10/3/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
As I understand it, the whole point of PEP-357 was to allow the coercion of
int-like things (numpy.int32 say, or your own private integerish class) to
be used as indices without also allowing things that aren't integers, but
that can be
On Wed, Oct 03, 2007 at 01:50:01PM -0400, Perry Greenfield wrote:
Let me rephrase: we cannot change the API until 1.1, unless this is
seen as a bug. To which other API changes are you referring? The
style changes is a different matter entirely.
The recent numpy and scipy threads on
On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote:
3) Greater time should be provided to accommodate the transition. For
example, there should not be deprecation warnings in the first
version that this API appears in. The first release of this should
not lead to nuisance messages for those
On 10/3/07, Perry Greenfield [EMAIL PROTECTED] wrote:
On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote:
3) Greater time should be provided to accommodate the transition. For
example, there should not be deprecation warnings in the first
version that this API appears in. The first
To help me understand, might someone offer some examples of
NumPy names that really should be changed?
Thank you,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
APL 2007 in Montreal (only 2 1/2 weeks away, Oct 20-22).
Summary program information is now available
on the APL2007 home page
http://www.sigapl.org/apl2007.html
with a link to the comprehensive program description at
http://www.sigapl.org/apl2007-program.html#a2
Registration
15 matches
Mail list logo
