bugs.bib

@misc{bug:v8:3006,
	abstract = {In Mac Chrome 33.0.1706.0 canary, Math.cos(Math.pow(2,120)) returns 0.47796506772457525. In Chromium ToT from today, after a V8 roll with the new sin/cos implementation using table lookup and interpolation, this now returns 0. The true value evaluated to full precision is closer to -0.925879. This also causes a test regression in webaudio that uses sin. This is highly unexpected that the new implementation causes a sine wave saved to a 16-bit wav file to produce different values.},
	keywords = {math, trig, trigonometry, native, standard, chrome, chromium, v8, bug, javascript},
	title = {{Inaccurate sin/cos values}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3006},
	year = {2013}
}

@misc{bug:chromium:320097,
	abstract = {From examining the source code, the cause is likely some optimization recently introduced into V8 around Math.sin or Math.cos. It may be that the change in behavior is perfectly valid; this demo is known to exercise the full range of floating-point values. However, investigation is needed to confirm that a regression hasn't been introduced.},
	keywords = {math, sin, sine, cos, cosine, trig, trigonometry, bug, standard, chrome, chromium, v8, javascript},
	title = {{V8 version 3.23.4 changes results of trigonometric functions}},
	url = { https://bugs.chromium.org/p/chromium/issues/detail?id=320097},
	year = {2013}
}

@misc{bug:v8:3089,
	abstract = {Let x = Math.pow(2,120). Math.sin(x) = 0.2446152181180111. Math.sin(-x) = -0.2970278622893754. You can argue whether there's any significance to Math.sin(x), but since sin(-x) = -sin(x) for all x, Math.sin should satisfy the same identity for any real x. Math.tan has the same issue, but it will be fixed if Math.sin is fixed.},
	keywords = {math, bug, sine, sin, standard, ieee754, floating-point, chrome, v8, trig, trigonometry, javascript},
	title = {{Math.sin(-x) is not -Math.sin(x)}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3089},
	year = {2014}
}

@misc{bug:mozilla:967709,
	abstract = {On the attached microbenchmark, which just pounds on sin with non-repeating values, V8 is about 2.8x faster on my Linux machine. (Our sin/cos just call in the C stdlib's sin/cos, so this is highly dependent on OS and stdlib version. I'd appreciate seeing what numbers other people get.) Profiling the box2d benchmark on awfy shows about 50% of its time is just calling sin/cos and this gives V8 better overall throughput on my machine. It looks like V8 rolls their own sin/cos (https://code.google.com/p/v8/source/detail?r=17594) which gives them more predictable performance. They self-host sin/cos which also avoids the call out from JIT code and all the overhead that that incurs. Since the sin/code code isn't all that complex, it seems like we could do even better with MSin/MCos MIR/LIR ops.},
	keywords = {mozilla, firefox, ff, math, sine, sin, cosine, cos, trig, bug, performance, perf, javascript},
	title = {{V8 is 2.8x faster at sin/cos}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=967709#c33},
	year = {2014}
}

@misc{bug:chromium:78263005,
	abstract = {Embed trigonometric lookup table.},
	keywords = {math, v8, chrome, sine, sin, cosine, cos, tan, tangent, trig, trigonometry, algorithm, algo, javascript},
	title = {{Reland: Embed trigonometric lookup table.}},
	url = {https://github.com/v8/v8/commit/33b5db090258c2a2dc825659c3ad109bd02110c1},
	year = {2013}
}

@misc{bug:kangax:compat-table:392,
	abstract = {Accuracy errors in the JavaScript standard Math library and associated shims.},
	keywords = {javascript, bug, math, standard, shims},
	title = {{Accuracy of Math.cbrt, Math.expm1, Math.log1p}},
	url = {https://github.com/kangax/compat-table/issues/392},
	year = {2015}
}

@misc{bug:mozilla:933257,
	abstract = {Attempts to move underlying implementations to fdlibm, but ended up reverting due to performance regressions.},
	keywords = {precision, math, javascript, standard, bug, firefox, ff},
	title = {{Address precision in new Math functions}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=933257},
	year = {2013}
}

@misc{bug:mozilla:892671,
	abstract = {...so that we know how sloppy the implementations are. The current tests are too lenient and would not detect significant regressions in precision. There is, too, room for improvement. acosh and asinh are quite sloppy on Windows. So is cbrt. By contrast, hypot is fine everywhere.},
	keywords = {precision, testing, javascript, mozilla, firefox, ff, math, standard, bug},
	title = {{Specify the tolerance in each new ES6 Math test}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=892671},
	year = {2013}
}

@misc{bug:mozilla:897634,
	abstract = {Two issues: 1. Precision when the argument is > 0.00001 but still smallish. The current code computes exp(x)-1 when |x| >= 0.00001. This loses some bits. The worst cases are:\n\njs> Math.expm1(1e-5)\n0.000010000050000166668   # system expm1\n0.000010000050000069649   # exp(x)-1\njs> Math.expm1(-1e-5)\n-0.000009999950000166666  # system expm1\n-0.000009999950000172397  # exp(x)-1\n\nI'm pretty sure we can safely use that approximation when exp(x) is outside the range (1/2, 2), that is, |x| >= log(2) ~= 0.69314.\n\njs> Math.expm1(0.69315)\n1.0000056388880587        # system expm1\n1.0000056388880587        # exp(x) - 1\n\nbut that's a much bigger range where we'll need to use a series approximation.\n\n2. Monotonicity. This one is a surprise to me. In bug 717379 comment 76, 4esn0k notes:\n\n> with current algorithm for expm1 (!HAVE_EXPM1), expm1 is not monotonic\n> Math.expm1(-1e-2) === -0.009950166250831893\n> Math.expm1(-0.009999999999999998) === -0.009950166250831945\n> so\n> Math.expm1(-1e-2) > Math.expm1(-0.009999999999999998)\n\nThese arguments are outside the ±0.00001 threshold, so the non-monotonicity is happening in the exp(x) - 1 part of the range. So... I guess this means exp() itself is not monotonic on 4esn0k's platform. It's hard to guard against that.\n\nThe Taylor series approximation we use near 0 is monotonic if the C++ stack provides monotonic multiplication and addition.},
	keywords = {precision, math, standard, javascript, bug, firefox, ff},
	title = {{Fix Math.expm1 when !HAVE_EXPM1}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=897634},
	year = {2013}
}

@misc{bug:mozilla:717379,
	abstract = {Issue to implement ES6 math functions. Issue thread highlights how, because the specification is underspecified, developers considered approximations "good enough" and did not feel compelled to include exact tests.},
	keywords = {bug, javascript, standard, firefox, ff, math, es6, es2015},
	title = {{Implement the new ES6 math functions}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=717379#c5},
	year = {2012}
}

@misc{bug:v8:3511,
	abstract = {Here are some issues with Math.atanh. This provides a bit more detail than the info in https://code.google.com/p/v8/issues/detail?id=3266. Math.atanh(1e-10) -> 1.000000082640371e-10. It should be 1e-10.},
	keywords = {math, precision, v8, bug, javascript, chrome, atanh, trig},
	title = {{Math.atanh issues}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3511},
	year = {2014}
}

@misc{bug:v8:3509,
	abstract = {Here are some issues with Math.acosh. This provides a bit more detail than the info in https://code.google.com/p/v8/issues/detail?id=3266. Math.acosh(1+1e-10) -> 0.000014142136208733941. The correct answer is 1.4142136208675862d-5. Math.acosh(1.79e308) -> Infinity. The correct answer is about 710.4758.},
	keywords = {math, precision, v8, bug, javascript, chrome, acosh, trig},
	title = {{Math.acosh issues}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3509},
	year = {2014}
}

@misc{bug:v8:3496,
	abstract = {Here are some issues with Math.asinh. This provides a bit more detail than the info in https://code.google.com/p/v8/issues/detail?id=3266. Math.asinh(1e-50) -> 0. Should return 1e-50 since asinh(x) ~ x for small x. Math.asinh(1e200) -> Infinity. Should return 461.2101657793691e0 instead of overflowing. In fact, it should never overflow since asinh(most-positive-float) ~= 710.},
	keywords = {math, javascript, standard, v8, chrome, trig, bug, asinh},
	title = {{Math.asinh issues}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3496},
	year = {2014}
}

@misc{bug:v8:3266,
	abstract = {From looking at the code for the hyperbolics, I noticed some numerical issues. sinh: For small x, sinh is not accurate because exp(x) and exp(-x) are both close to 1. It also does more work than necessary computing both exp(x) and exp(-x). cosh: More work than necessary computing both exp(x) and exp(-x). tanh: Inaccurate for small x for the same reasons as sinh. |tanh(x)| <= 1, but the implementation will overflow for |x| > 710 or so. More work than necessary computing both exp(x) and exp(-x). asinh: Inaccurate for small x because it computes, essentially, log(1-x). Using log1p will help. Premature overflow because it computes sqrt(1+x^2). In fact, asinh should never overflow for any non-infinite argument. atanh: Inaccurate for small x because it basically computes log(1+2*x/(1-x)) ~ log(1+2*x). Using log1p will help.},
	keywords = {math, v8, chrome, bug, javascript, standard, hyperbolic, trig},
	title = {{Numeric issues in hyperbolic functions}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3266},
	year = {2014}
}

@misc{bug:esdiscuss:038525,
	abstract = {In ECMA-262, section 15.8.2, the note allows implementations to choose appropriate algorithms for the evaluation of the special functions and it is recommended but not required to use the algorithms from fdlibm netlib.org/fdlibm.Since this is a recommendation and not a requirement implementations compute incorrect results for some values. This produces things where Math.cos(Math.pow(2,120)) doesn’t even have the correct sign or basic identities like sin(-x) = -sin(x) don’t hold for all finite values of x. This spreadsheet gives some results from various browsers on some selected functions. This lack of precision makes it very difficult to port numerical applications from C or Java to Javascript. It also forces every serious numerical Javascript application to test against every browser and platform for correct behaviour. This seems a major disservice to the web platform and Javascript in particular. Since the specification recommends using the algorithms from fdlibm, which, I believe produces results that are accurate to < 1 ulp, why not make this a requirement? As the spreadsheet shows, many browsers already achieve correct results. Porting fdlibm to Javascript is not particularly difficult provided a couple of key routines are available. (My colleague has done this for the trig functions, except for the hairy case of the Payne-Hanek pi reduction routine.) Note also that Java requires that many special function be accurate to < 1 ulp. Specifying a similar requirement for Javascript should not be too onerous on existing implementations. Java is an existence proof that these requirements can work. While having an accuracy requirement is good in itself, it’s also important that the functions are semi-monotonic to match the mathematical functions. This is also a requirement in Java. It is known that applications using divided differences behave incorrectly when functions are not monotonic when they should be.},
	keywords = {math, javascript, standard, precision, bug},
	title = {{ES6 accuracy of special functions}},
	url = {https://mail.mozilla.org/pipermail/es-discuss/2014-July/038525.html},
	year = {2014}
}

@misc{bug:v8:3468,
	abstract = {In Chrome 37.0.2062.20 beta (64-bit) on linux, Math.exp(100) returns 2.6881171418161485e+43. The correct answer is 2.68811714181613544841262555158d43. The error is about 26 ulp (binary).},
	keywords = {math, bug, javascript, standard, v8, chrome},
	title = {{Math.exp(100) is inaccurate}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3468},
	year = {2014}
}

@misc{bug:esdiscuss:2014-07-31,
	abstract = {TC39 meeting where Math accuracy issues are discussed, including the need to a) mandate a minimum precision and b) bring in experts.},
	keywords = {math, javascript, tc39, bug, standard, precision},
	title = {{Precision of Math trig functions}},
	url = {https://esdiscuss.org/notes/2014-07-31},
	year = {2014}
}

@misc{bug:esdiscuss:038525:spreadsheet,
	abstract = {Spreadsheet showing cross-browser variability.},
	keywords = {bug, math, cross-browser, portability, javascript},
	title = {{Cross-browser trig function variability}},
	url = {https://docs.google.com/spreadsheets/d/1t2jrptAvaQetDIYPD8GKc90Dni2dT3FuHgKKFF-eJHw/edit#gid=0},
	year = {2014}
}

@misc{bug:v8:3599,
	abstract = {Math.pow(10, 308) returns 1.0000000000000006e308. The correct answer is 1e308. fdlibm's pow function does, in fact, return 1e308. The difference between what V8 returns and the correct answer is 3 ulp.},
	keywords = {math, javascript, v8, chrome, pow, exponentiation, precision},
	title = {{Math.pow(10,308) is inaccurate}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=3599},
	year = {2014}
}

@misc{bug:mozilla:618251,
	abstract = {From Shannon Hickey:\n\nvar oneWay:Number = Math.pow(10, 305);\nvar theOther:Number = 1e+305;\ntrace(oneWay);\ntrace(theOther);\ntrace(oneWay == theOther);\ntrace(oneWay - theOther);\n\nResults:\n\n1.00000000000000e+305\n1e+305\nfalse\n5.84718840683999e+289\n\nResult line 1 is unexpected. Result line 3 is odd. Result line 4 is completely crazy.\n\nMy analysis:\n\nPrimarily this looks like an inaccuracy in our code for Math.pow.  You will notice that the difference between the two numbers is in the 16th digit (305-289=16), which cannot be represented reliably by a Number:  Number only has 15 decimal digits of precision, generally.  The pow() code does specialize for integer exponents but there could be inaccuracies creeping in around the extremes of the floating-point range (which extends to e+308) - I'd have to dig deeper to understand precisely what's going on, though. The reason the result of Math.pow() is being written as 1.00000000000000e+305 and not (eg) 1.00000000000001e+305, which is presumably the more accurate representation, is a separate bug in the number formatter. For integer exponents our Math.pow implementation uses a standard doubling algorithm. It appears that that doubling algorithm accumulates error. We ought to be able to do better.  That said, 1e305 isn't exactly representable in a Number (it has 708 leading non-zero digits in the binary representation) so it's just a question of how good our approximation is.},
	keywords = {math, bug, javascript, firefox, ff, mozilla, pow, exponentiation, precision},
	title = {{Math.pow accumulates error}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=618251},
	year = {2010}
}

@misc{bug:paulmillr:es6-shim:334,
	abstract = {var isAsinhOK = Math.asinh(0.0002) >= 0.0001999999986666666 &&  Math.asinh(0.0002) <= 0.0001999999986666668; var isAtanhOK = Math.atanh(0.0002) >= 0.0002000000026666667 && Math.atanh(0.0002) <= 0.0002000000026666668; Both of these are true in shimmed Firefox 37 and Safari 8, both false in Chrome 41 and Chrome Canary 44. From kangax/compat-table#392 (comment)},
	keywords = {math, shim, javascript, precision, chrome, v8},
	title = {{Chrome 41: `Math.asinh` and `Math.atanh` are imprecise}},
	url = {https://github.com/paulmillr/es6-shim/issues/334},
	year = {2015}
}

@misc{bug:paulmillr:es6-shim:314,
	abstract = {Large relative error for `Math.expm1` and `Math.log1p`.},
	keywords = {math, shim, javascript, es6, es2015, bug, precision},
	title = {{Relative error is too big for Math.expm1 and Math.log1p}},
	url = {https://github.com/paulmillr/es6-shim/issues/314},
	year = {2015}
}

@misc{bug:tc39:test262:269,
	abstract = {Discussion on whether to include accuracy tests due to underspecified standard.},
	keywords = {math, javascript, tc39, precision, bug},
	title = {{Add new tests for Math built-ins}},
	url = {https://github.com/tc39/test262/pull/269},
	year = {2015}
}

@misc{bug:v8:4566,
	abstract = {Just read the recent analysis of PRNG and CSPRNG in V8 here: https://medium.com/%40betable/tifu-by-using-math-random-f1c308c4fd9d. It seems contributors read this as well, as the bug in the MWC1616 implementation seems to be at least looked at here:\n\n- https://codereview.chromium.org/1462293002\n- https://github.com/v8/v8/commit/623cbdc5432713badc9fe1d605c585aabb25876c \n\nIs there any additional information the V8 team can provide that alters the outcomes of the article substantially? Are there plans to improve the baseline PRNG algorithm used in Math.random() as suggested?},
	keywords = {math, javascript, v8, chrome, random, rand},
	notes = {See also: betable article: https://medium.com/%40betable/tifu-by-using-math-random-f1c308c4fd9d#.pxwdcvikc; hackaday article: http://hackaday.com/2015/12/28/v8-javascript-fixes-horrible-random-number-generator/; nextweb article: http://thenextweb.com/google/2015/12/17/google-chromes-javascript-engine-finally-returns-actual-random-numbers/#gref; V8 blog: http://v8project.blogspot.com/2015/12/theres-mathrandom-and-then-theres.html; V8 patch: https://github.com/v8/v8/commit/085fed0fb5c3b0136827b5d7c190b4bd1c23a23e.},
	title = {{replace MWC1616 used in PRNG Math.random()}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=4566},
	year = {2015}
}

@misc{bug:v8:1975,
	abstract = {The precision of some builtin trignometric functions (i.e. Math.pow(), Math.sin() and Math.tan()) is very low on some corner cases when compared to precomputed values.\n1) We should verify that the precomputed values are actually a good measure of what a good approximation of IEEE 754 arithmetic should return. The spec recommends (see section 15.8.2) using "fdlibm" as a reference implementation.\n2) We should verify that the test cases mentioned below actually perform correct precision measurement. The computation of the deviation itself can be tricky when it comes to floating point arithmetic.\n3) We should find out whether (and how) to improve our precision.},
	keywords = {math, javascript, v8, chrome, trig, trigonometric, precision},
	notes = {},
	title = {{Precision of trignometric functions is low}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=1975},
	year = {2012}
}

@misc{bug:webkit:36673,
	abstract = {When calling Math.random() in different workers, Math.random() is returning the same values in the same order in each worker. For example, when executing the following code (in an object) in webkit in multiple workers, the object's redness is set to the same value in each worker: this.redness = Math.round(255*Math.random());},
	keywords = {math, javascript, webkit, safari, random, rand},
	notes = {Patched here: https://trac.webkit.org/changeset/65947.},
	title = {{Math.random repeats values in different workers}},
	url = {https://bugs.webkit.org/show_bug.cgi?id=36673},
	year = {2010}
}

@misc{bug:webkit:26972,
	abstract = {it has been discovered that all of the major web browsers use a predictable pseudo-random number generator (PRNG).  please see reference [0]. the robust solution is to switch to a provably unpredictable PRNG such as Blum Blum Shub [1,2].},
	keywords = {math, javascript, webkit, safari, random, rand},
	notes = {},
	title = {{predictable random number generator used in web browsers}},
	url = {https://bugs.webkit.org/show_bug.cgi?id=26972},
	year = {2009}
}

@misc{bug:chromium:246054,
	abstract = {A few years ago, it was disclosed that all of the major browsers use predictable random number generators.  This paper describes one such problem with this: http://landing2.trusteer.com/list-context/publications/temporary-user-tracking-major-browsers-and-cross-domain-information-leakag. I reported this against webkit also a few years ago, but haven't seen any progress, so I assume it remains unaddressed.  I figure escalating to chromium security is the right thing to do at this point: https://bugs.webkit.org/show_bug.cgi?id=26972},
	keywords = {math, javascript, chromium, chrome, v8, random, rand},
	notes = {},
	title = {{predictable random number generator}},
	url = {https://bugs.chromium.org/p/chromium/issues/detail?id=246054},
	year = {2013}
}

@misc{bug:mozilla:681357,
	abstract = {It may be a good idea to implement fast (low precision) math functions in the platform and make them accessible via Javascript. This would be of great use in WebGL environments where performance is critical, but also in many other scenarios. An example of a fast math function is the "fast inverse square root", very popular from games like Quake 3. Other suggestions include: fast square root, sin, log2, pow2 and binomial coefficient (each of those being highly used in various 3D and 2D drawing algorithms).},
	keywords = {math, javascript, mozilla, firefox, fastmath, fast, precision},
	notes = {},
	title = {{Fast math functions accessible with Javascript}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=681357},
	year = {2011}
}

@misc{bug:mozilla:686708,
	abstract = {Returns the Number value that is closest to x and is equal to a mathematical integer. If two integer Number values are equally close to x, then the result is the Number value that is closer to +INFINITY. If x is already an integer, the result is x. - If x is -0, the result is -0. Math.round(-0); --> 0 (should be -0). Infinity/Math.round(-0) --> +Infinity (should be -Infinity)},
	keywords = {math, javascript, mozilla, firefox, round},
	notes = {},
	title = {{Math.round() does not handle -0 and -0.5 properly}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=686708},
	year = {2011}
}

@misc{bug:mozilla:703611,
	abstract = {If x is -Infinity and y<0 and y is not an odd integer, the result is +0. Tamarin produces a -0 for this case. Code: print(Infinity/Math.pow(-Infinity, -2)); Output:  -Infinity. Expected: Infinity},
	keywords = {math, javascript, mozilla, firefox, pow, power, exponentiation},
	notes = {},
	title = {{Math.pow(-Infinity, even int < 0) does not produce the correct value}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=703611},
	year = {2011}
}

@misc{bug:mozilla:1316557,
	abstract = {Math.pow(-999, -999) should return -0, but under some compiler flags we are returning 0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=24c5ecf54fb2&selectedJob=30562285. All failures on bug1314438.js are due to this. This is not related to the jits.},
	keywords = {math, javascript, mozilla, firefox, pow, power, exponentiation},
	notes = {},
	title = {{Math.pow sometimes returns incorrect results}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=1316557},
	year = {2016}
}

@misc{bug:v8:2890,
	abstract = {Math.round and Math.floor can deopt on minus zero, but we do not learn anything from the deopt.},
	keywords = {math, javascript, v8, chrome, floor, round},
	notes = {},
	title = {{Deopt loops involving Math.round / Math.floor}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=2890},
	year = {2013}
}

@misc{bug:v8:4059,
	abstract = {Closely related to issue 2890, but that bug has languished and I feel the ceil(0) case in particular should be dealt with. The problem is that Math.floor deopts on -0 (repeatedly) AND that Math.ceil is implemented as -Math.floor(-x). Just got hit by this again (very hot loop deopting because of ceil(0)). This is such a frustrating performance landmine, because ceil(0) seems SO innocent, and the workarounds are quite unappealing.},
	keywords = {math, javascript, v8, chrome, ceil, floor, round},
	notes = {},
	title = {{Math.ceil(0) deopt loops}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=4059},
	year = {2015}
}

@misc{bug:v8:958,
	abstract = {Math.round(x) is implemented as Math.floor(x + 0.5). This looses precision in some cases. var s = 0.49999999999999994; alert([s, s + 0.5, Math.round(s)]); // Alerts "0.49999999999999994,5,5", i.e., incorrectly rounds to 5, not 4.},
	keywords = {math, javascript, v8, chrome, round},
	notes = {},
	title = {{Math.round rounds incorrectly.}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=958},
	year = {2010}
}

@misc{bug:esdiscuss:2013-03-20,
	abstract = {I noticed Object.is being discussed recently, and this reminded me of a concern in definition of equality predicates: that there is more than one NaN value. I see that the current draft (March 8, 2013) section 8.1.5 discusses this, but it says that "to ECMAScript code, all NaN values are indistinguishable from each other." Depending on what you mean by “ECMAScript code”, this may be false given the Typed Arrays extension, which allows direct access to the bit-patterns of float values (the Typed Arrays spec permits, but does not require, replacing a NaN value with any other NaN value on read or write). In some browsers, namely current Safari and current Chrome (stable, not beta), there are at least two distinct observable patterns (apparently one for the NaN literal and propagation from operations on it, and one for operations on numbers that are undefined). Is this considered a problem?},
	keywords = {math, javascript, tc39, nan, ieee754, security},
	notes = {See also https://github.com/ljharb/get-nans/blob/master/index.js and https://github.com/tc39/ecma262/issues/635},
	title = {{Observability of NaN distinctions — is this a concern?}},
	url = {https://esdiscuss.org/topic/observability-of-nan-distinctions-is-this-a-concern},
	year = {2013}
}

@misc{bug:mozilla:322529,
	abstract = {},
	keywords = {math, firefox, mozilla, random, rand},
	notes = {},
	title = {{Upgrade Math.random() to the better XorShift128+ algorithm}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=322529},
	year = {2006}
}

@misc{bug:webkit:151641,
	abstract = {The GameRand-based RNG Safari/JSC uses is very weak. Furthermore, it only uses 32 bits of precision. I blogged about this here: http://jandemooij.nl/blog/2015/11/27/math-random-and-32-bit-precision/. V8 moved to a better RNG and we're switching the one in SpiderMonkey as well. JSC should probably do the same.},
	keywords = {math, webkit, safari, random, rand},
	notes = {See also https://jandemooij.nl/blog/2015/11/27/math-random-and-32-bit-precision/.},
	title = {{Use a better RNG for Math.random()}},
	url = {https://bugs.webkit.org/show_bug.cgi?id=151641},
	year = {2015}
}

@misc{bug:webkit:40367,
	abstract = {},
	keywords = {math, webkit, safari, 32-bit},
	notes = {},
	title = {{Math JavaScript Bug on Safari 5 (webkit 533.16) under "32bit" mode}},
	url = {https://bugs.webkit.org/show_bug.cgi?id=40367},
	year = {2010}
}

@misc{bug:mozilla:969203,
	abstract = {I just made a plain C program that generates random numbers and checks whether a math function commutes (it generates a million random float numbers and directly tests the property upon these inputs -- and it finds counter examples after only a few tries (<10), so this empirical method sounds acceptable). The functions that can precisely commute are cos, sin, floor, ceil, round (the former is not specialized in Ion at the moment, see also bug 930477). The ones that don't precisely commute and that we do optimize for now are log, tan, atan, asin, acos. pow isn't optimized and doesn't commute precisely neither, but it was planned at some point (see also bug 930477 once again). Removing these functions would imply that we can't use them in Odin too (otherwise there would be a difference of behaviour between Odin and no-asm modes). This is a shame as this added more expressivity to asm.js, since C code compiled with emscripten using float functions (as logf, for instance), could behave the same in JS and in native code, at the same speed. If we remove optimizations for these functions and still want to have them available in Odin, we'd have to: convert the float input to a double, call the double math function, then convert it back to a float, which is worse in terms of performance. But precision seems more important here, so that's clearly a question of tradeoff. What do you think?},
	keywords = {math, firefox, mozilla},
	notes = {},
	title = {{Float32: Take out all Math functions that don't properly commute}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=969203#c8},
	year = {2014}
}

@misc{bug:mozilla:967709,
	abstract = {On the attached microbenchmark, which just pounds on sin with non-repeating values, V8 is about 2.8x faster on my Linux machine.  (Our sin/cos just call in the C stdlib's sin/cos, so this is highly dependent on OS and stdlib version.  I'd appreciate seeing what numbers other people get.)  Profiling the box2d benchmark on awfy shows about 50% of its time is just calling sin/cos and this gives V8 better overall throughput on my machine.  It looks like V8 rolls their own sin/cos (https://code.google.com/p/v8/source/detail?r=17594) which gives them more predictable performance.  They self-host sin/cos which also avoids the call out from JIT code and all the overhead that that incurs.  Since the sin/code code isn't all that complex, it seems like we could do even better with MSin/MCos MIR/LIR ops.},
	keywords = {math, firefox, mozilla, speed, precision, accuracy, v8},
	notes = {},
	title = {{V8 is 2.8x faster at sin/cos}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=967709},
	year = {2014}
}

@misc{bug:mozilla:948321,
	abstract = {fdiv is part of the x87 instruction set that's much older than SSE2/divsd. x87 has its own stack and is a pain to use compared to SSE; we try to avoid it as much as possible. We do use it for the fisttp instruction for instance because there's no SSE equivalent on x86. Unfortunately, fdiv uses 80-bit double-extended precision and divsd/SSE2 uses 64-bit double precision. That's probably causing the difference here. This sucks because it's not very easy to work around I'm afraid. For differential testing we could try to use a compiler switch so that it's free to emit SSE2+ instructions; maybe that will keep it from emitting fdiv, or maybe it won't.. Is this also a problem with 64-bit builds?},
	keywords = {math, firefox, mozilla, divide, division},
	notes = {},
	title = {{Differential Testing: Different division results on x86 platforms}},
	url = {https://bugzilla.mozilla.org/show_bug.cgi?id=948321},
	year = {2013}
}

@misc{bug:v8:5086,
	abstract = {The ES2015 spec defines a bunch of Math builtins, like Math.exp, Math.log, Math.sin and so on, which we traditionally implemented in various, i.e. some funny mix of hand written assembly, C++, JavaScript and Hydrogen code. It's pretty obvious that this is not only hard to maintain, but also creates a difficult situation for TurboFan, where we'd have to replicate what Crankshaft does. The builtins like Math.sin and Math.cos that are implemented mostly in JavaScript and which have fast paths that can be inlined cause further trouble for TurboFan, because for the slow path they have to have a call to some other JS code in it, which blocks any kind of code motion or value numbering of that. So two uses of Math.sin in a row of the same value cannot be optimized. And there are further optimization obstacles with the current approach. So the unification idea for this years fixit is to have for each (interesting) Math builtin either a.) a dedicated TurboFan machine operator (i.e. Float64Log, Float64Exp, etc.), and which can either use machine specific code or call into the C++ implementation internally, or b.) if the operation can easily be implemented via existing TurboFan operators, desugar it to that, or c.) only offer a C++ implementation, wrapped by a proper C++ builtin. The C++ implementation should ideally use fdlibm where appropriate (i.e. no performance concerns), slightly adapted to JavaScript semantics if necessary. This should live in src/base.  The goal for the Fixit is to have math.js and fdlibm.js empty by the end of the quarter and removed all the inconsistent code stubs and builtins (i.e. MathPowStub is a prime example). Bonus points if all of this can be used by asm.js->wasm as well.},
	keywords = {math, javascript, v8, chrome, trig, trigonometric, stdlib},
	notes = {},
	title = {{Unify the implementation of the various Math builtins}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=5086},
	year = {2016}
}

@misc{bug:v8:5157,
	abstract = {Similar to what we did with the other Math builtins, we should have a single, uniform C++ implementation for Math.pow, maybe consisting of two parts, pow(double,double) and powi(double,int). The main complication here is that Math.pow is highly optimized and if we regress it even slightly we will eventually tank the imaging-darkroom benchmark in Kraken, which is essentially a microbenchmark for Math.pow.},
	keywords = {math, javascript, v8, chrome, pow, power, exponentiation},
	notes = {},
	title = {{Unify the implementation of Math.pow}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=5157},
	year = {2016}
}

@misc{bug:webkit:53598,
	abstract = {Note that changing the WebIDL draft is an valid option as well if these values can be justified as making more sense. Alternately, the Typed Array specification could indicate that no explicit bit pattern for NaNs can be guaranteed - IEEE 754 defines a variety of NaN values, and for allowing variability among platforms may allow higher performance implementations.},
	keywords = {math, javascript, v8, chrome, nan, ieee754, floating-point},
	notes = {},
	title = {{[V8] Incorrect behavior of NaNs in DataView (setting values, bit patterns)}},
	url = {https://bugs.webkit.org/show_bug.cgi?id=53598},
	year = {2011}
}

@misc{bug:v8:1101,
	abstract = {When we execute the following code, we get back 0xfff8000000000000 (-NaN):\n\nvar buf = new Uint8Array(8);\nvar dv = new DataView(buf.buffer);\ndv.setFloat64(0, NaN, true);\nalert(dv.getUint32(4, true).toString(16)); // High 32-bit\nalert(dv.getUint32(0, true).toString(16)); // Low 32-bit\n\n However, if we change NaN to parseFloat("NaN"), we get back the correct value 0x7ff8000000000000 (NaN). In addition, replacing NaN with 0/0 gives us the incorrect value 0xfff8000000000000. The above script works correctly in JSC.},
	keywords = {math, javascript, v8, chrome, nan, ieee754, floating-point},
	notes = {See also https://bugs.chromium.org/p/chromium/issues/detail?id=71979.},
	title = {{NaN is converted to 0xfff8000000000000 (-NaN)}},
	url = {https://bugs.chromium.org/p/v8/issues/detail?id=1101},
	year = {2011}
}