Bug 150403 - JSC Math.pow tests makes wrong assumptions on precision
Summary: JSC Math.pow tests makes wrong assumptions on precision
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 108664
  Show dependency treegraph
 
Reported: 2015-10-21 11:42 PDT by Guillaume Emont
Modified: 2015-10-22 11:30 PDT (History)
1 user (show)

See Also:


Attachments
Patch (2.60 KB, patch)
2015-10-21 11:50 PDT, Guillaume Emont
no flags Details | Formatted Diff | Diff
Patch (2.57 KB, patch)
2015-10-21 15:43 PDT, Guillaume Emont
fpizlo: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Emont 2015-10-21 11:42:44 PDT
The test in Source/JavaScriptCore/tests/stress/math-pow-with-constants.js assumes the results of Math.pow() calls would be of a given precision, even though the spec[1] says that Math.pow():

  Returns an implementation-dependent approximation to the result of raising x to the power y.


At least on MIPS, the precision of the result is different on some tests.

[1] http://www.ecma-international.org/ecma-262/6.0/#sec-math.pow
Comment 1 Guillaume Emont 2015-10-21 11:50:20 PDT
Created attachment 263708 [details]
Patch
Comment 2 Guillaume Emont 2015-10-21 15:43:54 PDT
Created attachment 263752 [details]
Patch

New version with typo corrected
Comment 3 Filip Pizlo 2015-10-21 19:47:31 PDT
Comment on attachment 263752 [details]
Patch

Sounds like a mips bug. Jsc aims to have strong precision guarantees.
Comment 4 Guillaume Emont 2015-10-22 11:30:51 PDT
After further checking, it seems like the issue that I encountered with that test only happens when using uclibc. In that case, Math.pow(2,42.5) returns 6219777023950.949. Though that number looks like it has more precision, it turns out[1] that it seems that it is not rounded properly, but rather truncated (the correct rounding to 3 digits would be 
6219777023950.950), so it seems like it is a uclibc issue.
Sorry for the noise.

[1] http://www.wolframalpha.com/input/?i=2%5E42.5