On Tue, Jul 23, 2013 at 4:10 PM, Frédéric Bastien no...@nouiz.org wrote:
I'm mixed, because I see the good value, but I'm not able to guess the
consequence of the interface change.
So doing your FutureWarning would allow to gatter some data about this, and
if it seam to cause too much
On Thu, Jul 25, 2013 at 7:48 AM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Jul 23, 2013 at 4:10 PM, Frédéric Bastien no...@nouiz.org wrote:
I'm mixed, because I see the good value, but I'm not able to guess the
consequence of the interface change.
So doing your FutureWarning would
On Sat, 2013-07-13 at 11:28 -0400, josef.p...@gmail.com wrote:
On Sat, Jul 13, 2013 at 9:14 AM, Nathaniel Smith n...@pobox.com wrote:
snip
I'm now +1 on the exception that Sebastian proposed.
I like consistency, and having a more straightforward mental model of
the numpy behavior for
I'm mixed, because I see the good value, but I'm not able to guess the
consequence of the interface change.
So doing your FutureWarning would allow to gatter some data about this, and
if it seam to cause too much problem, we could cancel the change.
Also, in the case there is a few software that
Python itself doesn't raise an exception in such cases :
(3,4) != (2, 3, 4)
True
(3,4) == (2, 3, 4)
False
Should numpy behave differently ?
Bruno.
2013/7/12 Frédéric Bastien no...@nouiz.org
I also don't like that idea, but I'm not able to come to a good reasoning
like Benjamin.
I
On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet bruno.pig...@gmail.com wrote:
Python itself doesn't raise an exception in such cases :
(3,4) != (2, 3, 4)
True
(3,4) == (2, 3, 4)
False
Should numpy behave differently ?
The numpy equivalent to Python's scalar == is called array_equal,
and
On Mon, 2013-07-15 at 15:09 +0200, bruno Piguet wrote:
Python itself doesn't raise an exception in such cases :
(3,4) != (2, 3, 4)
True
(3,4) == (2, 3, 4)
False
Should numpy behave differently ?
Yes, because Python tests whether the tuple is different, not whether
the elements are:
Just a question, should == behave like a ufunc or like python == for tuple?
I think that all ndarray comparision (==, !=, =, ...) should behave the
same. If they don't (like it was said), making them consistent is good.
What is the minimal change to have them behave the same? From my
Thank-you for your explanations.
So, if the operator == applied to np.arrays is a shorthand for the
ufunc np.equal, it should definitly behave exactly as np.equal(), and raise
an error.
One side question about style : In case you would like to protect a x ==
y test by a try/except clause,
2013/7/15 Frédéric Bastien no...@nouiz.org
Just a question, should == behave like a ufunc or like python == for tuple?
That's what I was also wondering.
I see the advantage of consistency for newcomers.
I'm not experienced enough to see if this is a problem for numerical
practitionners Maybe
On Mon, 2013-07-15 at 17:12 +0200, bruno Piguet wrote:
2013/7/15 Frédéric Bastien no...@nouiz.org
Just a question, should == behave like a ufunc or like python
== for tuple?
That's what I was also wondering.
I am not sure I understand the question. Of
On Fri, 2013-07-12 at 19:29 -0400, josef.p...@gmail.com wrote:
On Fri, Jul 12, 2013 at 3:35 PM, Frédéric Bastien no...@nouiz.org wrote:
I also don't like that idea, but I'm not able to come to a good reasoning
like Benjamin.
I don't see advantage to this change and the reason isn't good
On Fri, Jul 12, 2013 at 2:13 PM, Benjamin Root ben.r...@ou.edu wrote:
I can see where you are getting at, but I would have to disagree. First of
all, when a comparison between two mis-shaped arrays occur, you get back a
bone fide python boolean, not a numpy array of bools. So if any action was
On Sat, Jul 13, 2013 at 9:14 AM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Jul 12, 2013 at 2:13 PM, Benjamin Root ben.r...@ou.edu wrote:
I can see where you are getting at, but I would have to disagree. First of
all, when a comparison between two mis-shaped arrays occur, you get back a
Hey,
the array comparisons == and != never raise errors but instead simply
return False for invalid comparisons.
The main example are arrays of non-matching dimensions, and object
arrays with invalid element-wise comparisons:
In [1]: np.array([1,2,3]) == np.array([1,2])
Out[1]: False
In [2]:
I can see where you are getting at, but I would have to disagree. First of
all, when a comparison between two mis-shaped arrays occur, you get back a
bone fide python boolean, not a numpy array of bools. So if any action was
taken on the result of such a comparison assumed that the result was
I also don't like that idea, but I'm not able to come to a good reasoning
like Benjamin.
I don't see advantage to this change and the reason isn't good enough to
justify breaking the interface I think.
But I don't think we rely on this, so if the change goes in, it probably
won't break stuff or
On Fri, Jul 12, 2013 at 3:35 PM, Frédéric Bastien no...@nouiz.org wrote:
I also don't like that idea, but I'm not able to come to a good reasoning
like Benjamin.
I don't see advantage to this change and the reason isn't good enough to
justify breaking the interface I think.
But I don't
18 matches
Mail list logo
