mbostock/d3 — pull request #1997 by GerHobbelt (2014-08-27 22:47:30+00:00)
Title: pullreq fixing #1994 + #1995 + tolerant format behaviour; includes test cases to prevent regressing

- fix #1994/#1972: the d3.format bug where scientific notation values are corrupted by the locale thousands separator action (e.g. d3.format(',f')(1e42)) when the value representation does not contain a decimal point as well.

- #1994: ditto where scientific notation values are printed in format modes which 'usually do not print the value as a scientific number' but the machine has to due to the very tiny or huge value presented to d3.format to print (such as type='f')

- tolerate the comma in the format spec for format types which do not use it (type=[boxX...]): see also next item

- fix #1995 the type=n format: to match the documentation (n === ,g), the 'n' type should also use the same value formatter as 'g': that formatter differs noticably from the 'default formatter' when large/tiny numbers are printed.

- tiny optimization: do not mix run-time types in the 'type' variable to help the JS JIT compilers' run-time type analysis (Chrome V8 et al) to produce optimized code: `type` is a string, `type_f` is the corresponding function.

- Tests have been added to cover all situations as the bug(s) were discovered due to the combination of
+ userland code constructing a user-driven d3.format string (which should tolerate simple 'illegal combinations' to simplify d3.format usage by not requiring the userland code to carry a rule matrix for filtering formats upon construction), and
+ userland data including very large and very small numbers being fed to these d3.format-generated formatters.

## Notes

#1996:
The 'p' percent type/mode performs a multiplication resulting in the ubiquitous floating point inaccuracy issues (http://dl.acm.org/citation.cfm?id=103162.103163) rearing their ugly head: see the commented out test case

```
//assert.strictEqual(f(3.1415e42), "3.1415e+44%"); // x86: 3.1415000000000002e+44% -- floating point inaccuracy kicking in...
```

which has been 'tweaked' to circumvent the issue **for this particular test case** (i.e. the problem is not gone, it is simply hiding)