Editorial: Improve the clarity and consistency of Number.prototype.toPrecision

[gibson042]

We should strive to make algorithm steps maximally deterministic, and in particular should avoid interdependent assignment where possible.

[gibson042]

I'm also thinking about improving the names of these aliases and replacing the code point references with inline literals.

Suggested change

	1. Let _c_ be the code unit 0x002B (PLUS SIGN).
	1. Let _sign_ be *"+"*.

[bakkot]

This seems like an improvement to my eyes, although I'm not sure about the n < 10^p -> n ≤ 10^p change - what was the motivation for that?

Also, I note that there's a very similar text in Number.prototype.toExponential; presumably they should match.

[gibson042]

This seems like an improvement to my eyes, although I'm not sure about the n < 10^p -> n ≤ 10^p change - what was the motivation for that?

This is actually the crux of the change, and it relates to cases where rounding increases magnitude. For example, consider x = 995 with p = 2. The old algorithm would require non-constructive discovery of (e=2, n=99) and (e=3, n=10), respectively corresponding to approximations 99e1 (990) and 10e2 (1000), and then tiebreaking to the latter because it is larger. The proposed algorithm instead anchors e=2 to discover n=99 and n=100 (the latter only allowed by looseness of "≤"), performs the same tiebreaking logic to settle on n=100, and then ends up at the same place by normalizing 100e1 to 10e2.

Also, I note that there's a very similar text in Number.prototype.toExponential; presumably they should match.

Yes, and also in ECMA-402 (this change was actually prompted by tc39/ecma402#572), and arguably in Number::toString as well. I'd like to explore the possibility of having them all defer to a new operation for finding the relevant integers, but haven't yet determined what shape it would have.