Clarify meaning

kgryte · kgryte · commit c90651f87899 · 2017-06-16T21:52:27.000-07:00
diff --git a/FAQ.md b/FAQ.md
@@ -171,7 +171,7 @@ Despite the disadvantages articulated above, this project __does__ include Node.
 
 ### Why reimplement and provide custom Math implementations?
 
-1. [ECMA-262][ecma-262] does not mandate specific algorithms (only recommends `libm`). Accordingly, JavaScript implementors are free to choose any algorithm, which means that numeric computation results often differ across environments. This renders JavaScript not amenable to reproducible computation.
+1. [ECMA-262][ecma-262] does not mandate specific algorithms (only recommends `libm`). Accordingly, JavaScript implementors are free to choose any algorithm, which means that numeric computation results often differ across environments. This renders the standard JavaScript math library not amenable to reproducible computation.
 1. [ECMA-262][ecma-262] does not require a minimum [precision][mdn-math]. As a result, JavaScript implementors make non-transparent trade-offs between speed and accuracy, frequently favoring speed above all else. While traditional web applications may not require highly accurate Math results, many numeric computation applications do. And because the implementations are not transparent, debugging accuracy issues in numeric computation applications which use native Math built-ins is considerably more difficult.
 1. Because native Math functions are implementation dependent, numeric computation applications are __not__ portable. By creating a set of standard Math implementations, we ensure that results on one platform are reproducible on every other platform.
 1. Native math functions frequently have bugs (see [docs/native_math_bugs.md][native-math-bugs]).
