Originally we were using Welford’s algorithm, but this is primarily
useful when computing the variance in a numerically stable manner, since
Welford’s approach requires an incremental mean.
I’ve removed a test for the mean of more than one instance of
Number.MAX_VALUE as this is unlikely to occur in practice; most likely
this was the reason I used Welford’s algorithm in the first place.
There’s a paper [1] comparing various algorithms for computing the mean,
and Welford’s is actually slightly less accurate than the naïve
approach. There are some more accurate approaches but I think it’s
overkill for d3.mean.
[1] Youngs, Edward A., and Elliot M. Cramer. "Some results relevant to
choice of sum and sum-of-product algorithms." Technometrics 13.3 (1971):
657-665.
Related: #1842.
I’m not entirely sure this is the most useful behavior, but since typeof null is
"object" and +null is 0, interpolating to null is equivalent to interpolating to
the number zero.
Rather than overload the meaning of precision to bias the selection of the SI
prefix, always use the standard SI prefix, and use the precision in the same
sense as with fixed digits: the number of digits after the decimal point.
For reasons that I can’t recall, the SI-prefix behavior was different for small
numbers (between -1 and 1) than it was for large numbers. This commit enforces
consistent behavior, so that the coefficient is always in the range [1, 1000),
like in engineering notation.
For example, the old d3.format("s") would display 0.01 as "0.01", whereas the
new behavior displays it as "10m".
When a SI-prefix format (type "s") is passed to scale.tickFormat, compute a
suitable SI-prefix based on the maximum value in the range, and then use that
prefix for all ticks rather than computing the SI-prefix on a per-tick basis.
For backwards-compatibility, bisector checks the arity of the specified
function, and if the function only takes a single argument, it is wrapped with a
suitable comparator.
Fixes#1766. Unlike d3.bisector(accessor), this allows you to define a bisector
that works in reverse order.
An awkward aspect of implementing bisection on top of a comparator is that it is
often the case that the sorted array contains objects (e.g., rows from a TSV),
while the search value is a primitive value (e.g., a number). Thus, you want to
apply an accessor to the array elements but not to the search value.
The solution here is to invoke the comparator deterministically: the first
argument is always an element from the array, and the second argument is always
the search value. This lets a comparator apply an accessor to array elements but
not to search values.
When d3.js is loaded, it now prefers the AMD define function or module.exports
if available; the global `d3` is only set if neither of these are available. A
side benefit of this change is that browserify, bower and component can now load
the D3 library directly rather than needing a custom definition.
ljani
Mike Bostock
Jason Davies
Jim Kang
Roger Bramon
Fabricio Tavares de Oliveira
jbblanchet
Stuart Glaser
Daniel Goldbach