8000 -array(True) == False · Issue #4100 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

-array(True) == False #4100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
abalkin opened this issue Dec 5, 2013 · 9 comments
Closed

-array(True) == False #4100

abalkin opened this issue Dec 5, 2013 · 9 comments

Comments

@abalkin
Copy link
Contributor
abalkin commented Dec 5, 2013

NumPy behavior is inconsistent with that of python builtins:

>>> -numpy.array(True)
False
>>> -numpy.bool8(True)
False

but

>>> -True
-1
@seberg
Copy link
Member
seberg commented Dec 5, 2013

Well, numpy bools are not really python bools (since python bools are basically ints, numpy's are not). The whole definition of -, etc. is funny in numpy and I doubt it will change, but what bothers me a bit here is:

In [16]: np.array(False) + - np.array(False)
Out[16]: True

In [17]: np.array(False) - np.array(False)
Out[17]: False

@abalkin
Copy link
Contributor Author
abalkin commented Dec 5, 2013

The whole definition of -, etc. is funny in numpy and I doubt it will change

Note that it was different in Numeric:

>>> -Numeric.array(True, '1')
-1

I was not able to find any place where this behavior is documented and it is very surprising when boolean arrays are not interchangeable with integer 0/1 arrays in expressions. For example:

>>> -array([1,0,1,0])*arange(1,5)
array([-1,  0, -3,  0])
>>> -array([1,0,1,0], bool)*arange(1,5)
array([0, 2, 0, 4])

@njsmith
Copy link
Member
njsmith commented Dec 5, 2013

Yeah, it sure would make more sense for negation on bools to be either a
no-op (in Z/2, every element is its own additive inverse), or else to
promote to int. Since we define binary + and - as the Z/2 operations, the
former probably makes more sense.

Not sure if we can actually fix it at this point.

Maybe we should make unary - on bools just raise an error for now? That'd
be a safe change, at least.
On 4 Dec 2013 17:00, "abalkin" notifications@github.com wrote:

The whole definition of -, etc. is funny in numpy and I doubt it will
change

Note that it was different in Numeric:

-Numeric.array(True, '1')
-1

I was not able to find any place where this behavior is documented and it
is very surprising when boolean arrays are not interchangeable with integer
0/1 arrays in expression. For example:

-array([1,0,1,0])_arange(1,5)
array([-1, 0, -3, 0])
-array([1,0,1,0], bool)_arange(1,5)
array([0, 2, 0, 4])

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4100#issuecomment-29862452
.

@abalkin
Copy link
Contributor Author
abalkin commented Dec 5, 2013

Since we define binary + and - as the Z/2 operations

We don't:

>>> array(True)+array(True)
True

in Z/2 ring this would be False or 0.

As implemented, numpy bools form an idempotent semiring with respect to + and * operations. In a semiring addition does not have an inverse, so this observation does not help to define unary minus.

I think + and - should either promote bools to ints or raise an error. Given that semiring operations are already available as | and & operators and current unary minus is the same as ~, it is hard to see the utility of current implementation.

@njsmith
Copy link
Member
njsmith commented Dec 5, 2013

Good point, I skimmed @seberg's message too quickly :-).

Right now we have + is the same as |, * is the same as &, binary - is the
same as ^, and unary - is the same as ~. We can't define unary - to be
consistent with binary -, though I suppose we could define binary - to be
consistent with unary -. Can't see why we would want to though.

I agree that the ideal behaviour is for these to either error or promote to
int. I'm not sure which, but it doesn't really matter; even if we want to
switch to promoting, the first step would still be to transition to an
error.

I'd be +1 on a patch deprecating +/-/* for numpy bools.

On Wed, Dec 4, 2013 at 9:00 PM, abalkin notifications@github.com wrote:

Since we define binary + and - as the Z/2 operations

We don't:

array(True)+array(True)
True

in Z/2 ring this would be False or 0.

As implemented, numpy bools form an idempotent semiringhttp://en.wikipedia.org/wiki/Semiring#Definitionwith respect to + and * operations. In a semiring addition does not have an
inverse, so this observation does not help to define unary minus.

I think + and - should either promote bools to ints or raise an error.
Given that semiring operation are already available as | and & operators
and current unary minus is the same as ~, it is hard to see the utility of
current implementation.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4100#issuecomment-29871734
.

Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

@abalkin abalkin mentioned this issue Dec 5, 2013
8000 Closed
@seberg
Copy link
Member
seberg commented Dec 5, 2013

Gave the deprecation a shot in gh-4105. In principle I tihnk it is good, but the impact on real live code might be rather large. I did not yet do any of the fixes in numpy itself (maybe you want to have a look at it and send a PR against me PR -- yes that is possible -- or a patch). The thing I am unsure about is, after this has been deprecated a while, what integer type do you cast it to? int8?

@njsmith
Copy link
Member
njsmith commented Dec 5, 2013

My first guess would be to upcast to dtype(int), but no point in worrying
about such details now, we'll just end up re-debating it if and when we
actually make the change.
On 5 Dec 2013 13:59, "seberg" notifications@github.com wrote:

Gave the deprecation a shot in gh-4105#4105.
In principle I tihnk it is good, but the impact on real live code might be
rather large. I did not yet do any of the fixes in numpy itself (maybe you
want to have a look at it and send a PR against me PR -- yes that is
possible -- or a patch). The thing I am unsure about is, after this has
been deprecated a while, what integer type do you cast it to? int8?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4100#issuecomment-29942712
.

@charris
Copy link
Member
charris commented Dec 5, 2013

I agree with changing the behaviour to something nicer, but it should be discussed on the list first. That said, I doubt there will be much disagreement or that many rely on current behavior.

@charris
Copy link
Member
charris commented Feb 24, 2014

Unary - has been deprecated for numpy booleans.

@charris charris closed this as completed Feb 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@seberg @charris @abalkin @njsmith
0