Skip to content
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.

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

[expr.unary.op]/8 #4131

Closed
jabelloc opened this issue Aug 30, 2020 · 10 comments · Fixed by #4215
Closed

[expr.unary.op]/8 #4131

jabelloc opened this issue Aug 30, 2020 · 10 comments · Fixed by #4215
Assignees

Comments

@jabelloc
Copy link

[expr.unary.op]/8:

The operand of the unary - operator shall have arithmetic or unscoped enumeration type and the result is the negation of its operand. ...

The negation is obviously wrong.

@jensmaurer
Copy link
Member

What other word would you suggest to use?

@jabelloc
Copy link
Author

I would suggest the replacement of the word "negation" by "negative value".

@Eelis
Copy link
Contributor

Eelis commented Aug 31, 2020

"negative value" could be a bit weird since the value might not actually be negative. "opposite" or "additive inverse" are options which don't have this problem.

@tkoeppe
Copy link
Contributor

tkoeppe commented Sep 1, 2020

Just "negative" seems like an improvement: "the result is the negative of its operand". That's pretty standard terminology. (Indeed a negative need not be negative.)

@zygoloid
Copy link
Member

The negation is obviously wrong.

I don't think it's wrong; see this question on English language stackexchange. The unary operator - negates its operand, so the result is the negation of its operand. But I will happily accept that this usage of "negation" may not be familiar to all of our target audience; I'm happy to use a different word.

I don't think "negative" is an improvement. However, I think "additive inverse" would be an improvement, especially because it more directly means the right thing for unsigned types.

@tkoeppe
Copy link
Contributor

tkoeppe commented Sep 22, 2020

@zygoloid: why is "negative" bad but "additive inverse" is acceptable? Isn't the former simply a name for the latter?

@jabelloc
Copy link
Author

jabelloc commented Sep 22, 2020

I took my old copy of Walter Rudin's book "Principles of Mathematical Analysis" (second edition), perhaps one of the most renowned academic texts on the subject, for graduate courses. After a brief rereading of his first chapter "The Real and Complex Number System", I did not identify a single time that the author referred to the - sign as a negation. But there are references in this chapter to the terms negative cut or positive cut, which are mathematical abstractions used by Dedekind to define the set of rational numbers. I haven't checked this thing out for the whole book, but I don't remember ever seeing the word negation associated with the - arithmetic sign, in any math book that I had a chance to read or study in my life.

@zygoloid
Copy link
Member

zygoloid commented Oct 5, 2020

ISO/IEC 2382:2015 defines:

negation
NOT operation
Boolean complementation
inversion

monadic Boolean operation whose result has the Boolean value opposite to that of the operand

That's not what we mean here, so we should certainly change this wording (regardless of whether our readership is or is not familiar with this usage of this word). It also defines:

negate

perform the operation of negation

... so we can't use that either, except to describe the operation of ! or ~.

@zygoloid: why is "negative" bad but "additive inverse" is acceptable? Isn't the former simply a name for the latter?

"Negative" also refers to the set of numbers less than zero. Indeed, while ISO/IEC 2382:2015 does not define "negative", it uses it exclusively to refer to numbers less than zero. Also, in my experience it's not common to refer to the additive inverse of an element in an arbitrary ring (such as the ring modeled by an unsigned type) as the negative of that element. I think, for the most part, "additive inverse" uniquely identifies the operation we're looking for here.

Hm. But "additive inverse" doesn't work for floating-point types, because +inf doesn't have an additive inverse, but unary minus is typically still well-defined when applied to it. It's also wrong in the presence of signed zeroes, wherein 0 does not have an additive inverse: there is nothing that can be added to -0.0 + 0.0 (== 0.0) to get -0.0.

So:

  • "negation" and "negate" are out (ISO/IEC 2382 defines them as something else)
  • "negative" is questionable (not really appropriate for unsigned types, and risks confusion with property of being negative)
  • "additive inverse" is out (wrong for floating-point infinity and zero)
  • "with the sign {flipped/reversed/inverted}" / "with the opposite sign" is somewhat unnatural for unsigned types and probably overconstraining for floating point
  • "the result of subtracting the operand from zero" almost works, but is also wrong for negative zeroes (0.0 - 0.0 is positive zero)
  • "the result of subtracting the operand from negative zero" works, but is very strange
  • "the result of multiplying the operand by -1" seems to work in all cases, but it's not ideal for unsigned types

I'm not entirely happy with any of these options.

@jabelloc
Copy link
Author

jabelloc commented Oct 6, 2020

I don't see a problem using the term negative for -x when x is an unsigned type, given that the operation is defined in [basic.fundamental/2 with this sentence:

arithmetic for the unsigned type is performed modulo 2N

In arithmetic the name of the operation -x is called the negative of x. And this is defined according to the fundamental rules of arithmetic:

if x > 0, the negative of x, denoted as -x, is defined as the negative number -x.
if x = 0, the negative of x, denoted as -x, is defined as 0.
if x < 0, the negative of x, denoted as -x, is defined as the positive number -x.

Thus, if x is an unsigned type with value x, the negative of x, denoted by -x, is defined by x modulo 2N.

@zygoloid
Copy link
Member

zygoloid commented Oct 6, 2020

C uses "negative of" for this purpose. I think that's enough motivation to prefer that word, even though it's not ideal for unsigned types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants