Editorial: correct references to negative zero#626
Conversation
"Negative zero" cannot be expressed with an ECMA262 mathematical value, but it may be expressed with an ECMA262 Number value. Update new references to "negative zero" to use an appropriate type. Update corresponding references to "zero" to avoid comparing mathematical values with Number values.
spec/numberformat.html
Outdated
|
|
||
| <emu-alg> | ||
| 1. If _x_ < 0 or _x_ is *-0*<sub>𝔽</sub>, let _isNegative_ be *true*; else let _isNegative_ be *false*. | ||
| 1. If _x_ < 0<sub>𝔽</sub> or _x_ is *-0*<sub>𝔽</sub>, let _isNegative_ be *true*; else let _isNegative_ be *false*. |
There was a problem hiding this comment.
This one is kind of tricky - this operation is generic over both Number and BigInt values, so it's not obviously reasonable to compare against the floating-point 0.
I'd suggest instead:
| 1. If _x_ < 0<sub>𝔽</sub> or _x_ is *-0*<sub>𝔽</sub>, let _isNegative_ be *true*; else let _isNegative_ be *false*. | |
| 1. If ℝ(_x_) < 0 or _x_ is *-0*<sub>𝔽</sub>, let _isNegative_ be *true*; else let _isNegative_ be *false*. |
spec/numberformat.html
Outdated
| 1. Else, | ||
| 1. Assert: _signDisplay_ is *"exceptZero"*. | ||
| 1. If _x_ is 0 or _x_ is -0 or _x_ is *NaN*, then | ||
| 1. If _x_ is 0<sub>𝔽</sub> or _x_ is -0<sub>𝔽</sub> or _x_ is *NaN*, then |
There was a problem hiding this comment.
This operation is also generic over both Number and BigInt, so
| 1. If _x_ is 0<sub>𝔽</sub> or _x_ is -0<sub>𝔽</sub> or _x_ is *NaN*, then | |
| 1. If _x_ is *NaN* or ℝ(_x_) is 0, then |
(ℝ requires its argument to be finite, so we have to rule out the infinities and NaN before calling it. I'm pretty sure the infinities are screened out at the callsite, so I didn't guard against them here, but if I'm wrong this should be or _x_ is finite and ℝ(_x_) is 0.)
There was a problem hiding this comment.
Thanks for calling attention to the infinities in particular. I don't think those are screened at the call site: PartitionNumberPattern has a branch for them, but it still ends up passing them to this abstract operation.
Is there any ambiguity in the prose, "If A or B and C", though?
There was a problem hiding this comment.
I suppose it's somewhat ambiguous, though I think in this context there's no other coherent reading.
But it's probably best to be more explicit. You can distinguish the cases as in If A, or if B and C, maybe.
There was a problem hiding this comment.
Sounds good to me!
spec/numberformat.html
Outdated
| 1. If _x_ is 0<sub>𝔽</sub> or _x_ is -0<sub>𝔽</sub> or _x_ is *NaN*, then | ||
| 1. Let _pattern_ be _patterns_.[[zeroPattern]]. | ||
| 1. Else if _x_ > 0, then | ||
| 1. Else if _x_ > 0<sub>𝔽</sub>, then |
There was a problem hiding this comment.
| 1. Else if _x_ > 0<sub>𝔽</sub>, then | |
| 1. Else if ℝ(_x_) > 0, then |
|
Thanks for the review, @bakkot! |
|
I don't get it; in the current spec, |
|
|
4 participants
"Negative zero" cannot be expressed with an ECMA262 mathematical value,
but it may be expressed with an ECMA262 Number value. Update new
references to "negative zero" to use an appropriate type. Update
corresponding references to "zero" to avoid comparing mathematical
values with Number values.
/cc @bakkot