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  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.  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.
If there are a lot of matching numbers, it’s faster to do direct string equality comparisons than it is to coerce to a number and compare numerically.
Fixes #1823; spurious closePath events were being generated for degenerate polygons due to generation of empty polygons and rings in rare cases.
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.
The point of this method is to pick the right precision for you!
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.
Fixes #1717. Turns out, -1 % 1 is 0!
This ensures that if the touch target is removed from the DOM during a zoom gesture, the zoom behavior continues to receive events; touch events, unlike other events, are always dispatched to the target of the touchstart event rather than the window.
Rather than starting the ticks on the minimum domain value, round up based on the step size. Fixes #1757.
… Tests pass. http://jsperf.com/rgb-str-vs-regex
The Lambert conic conformal projection extends to infinity along the outer edge of the projection, and thus the latitude must be clamped either at -π/2 or +π/2 depending on the parallels. Fixes #1802.
This was fixed in 2010, so I think it’s safe to remove the workaround now.
This way, it’s easier to tell whether the touch changed during the event. This also fixes #1600 because the drag behavior now only dispatches a drag event on elements that moved, even if multiple touches are active.
The drag behavior no longer crashes when the element being dragged is removed from the DOM. In addition, the new d3.touch method extracts a single identified touch from the current touch event, making it more efficient during multitouch. The drag behavior now assigns touchmove and touchend listeners on the target element of the touchstart event, rather than the window.
The drag behavior registers a touchend listener for each started touch; however, a touchend event is dispatched to ALL listeners when any touch ends, not just for the corresponding starting touch. The drag behavior must therefore detect whenever the ending touch is the corresponding starting touch, and ignore other ending touches. This fixes the drag behavior during multitouch, as discussed in #1786.