The ECMA-402 specification defines the ToRawPrecision algorithm to be very similar to Number.prototype.toPrecision. The only real difference is that TRP displays the full number instead of collapsing the exponential. Therefore, it stands to reason that, for numbers with a length shorter than 21, the output should be identical.
Part of the test data defines the following numbers and their respective formatted output with test data options {useGrouping: false, minimumSignificantDigits: 3, maximumSignificantDigits: 5}:
"123.44500": "123.45",
"-123.44500": "-123.45",
However, because of the issue we have with floating point accuracy, this test should be expected to fail because
123.445.toPrecision(5) === "123.44"
and
123.445.toFixed(2) === "123.44"
In both V8 and Spidermonkey. Because of the underlying floating point operations, the number is rounded down instead of up. The tests following, "123.44501" and "-123.44501" would pass.
I can't actually test this in Firefox or Chrome because neither have complete implementations of Intl.NumberFormat yet (Chrome's doesn't appear to support maximumSignificantDigits), so this could be invalid. Assuming the complete implementations would follow the same algorithm as Number.prototype.toPrecision/toFixed, though, I would expect it to be impossible for them to pass this test.
If I follow the logic of the bug description correctly, it's roughly:
1) Functions a and b are specified similarly.
2) There is a test case for function b, but not for function a.
3) Function a is implemented incorrectly in some browsers such that it would fail the test case for function b if it were rewritten to use function a.
4) Therefore function b must be implemented incorrectly in those browsers once they are implemented.
5) Therefore the test case for function b is invalid.
Comments:
1) Correct, ToRawPrecision is intentionally very similar to Number.prototype.toPrecision.
2) That seems like a gap in the test coverage for toPrecision. I've filed bug 1527.
3) That's sad. Are there bug reports against those browsers?
4) That might be true if functions a and b shared an implementation. At least in SpiderMonkey, they don't: NumberFormat.prototype.format uses ICU, while toPrecision doesn't. Intl.NumberFormat("en", {maximumSignificantDigits: 5}).format(123.44500) returns "123.45" as required by the spec. If you'd like to test with Firefox, here's one nightly build that has the Internationalization API enabled:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-05-08-03-11-13-mozilla-central/
5) That doesn't follow at all. A test case is only invalid if it tests something that's not required by the spec. Failing implementations may possibly lead to changes in the spec, which would then lead to changes in the tests.
Fair enough. I did say that it may be invalid, but I was anticipating this issue cropping up in Spidermonkey and V8 based on my own analysis and implementation of the specification, which obviously wasn't correct. Either way, at least one valid bug was filed as a result of my blundering ― my work here is done ;-)
I can't tell if you're saying I should file a bug regarding Number.prototype.toPrecision for V8 and Spidermonkey.
(In reply to comment #2)
> I can't tell if you're saying I should file a bug regarding
> Number.prototype.toPrecision for V8 and Spidermonkey.
If there are no bugs reporting the incorrect rounding behavior yet, then yes, it would be a good idea to file these bugs.