The default behaviour is to only use a minus sign for negative numbers.
However, when this behaviour was explicitly specified using "-", this
caused positive numbers to become negative.
Fixes#2072.
Rather than always escaping keys with a null-prefix, only escape keys that can
conflict with built-in properties (either on Object, d3_Map or d3_Set). By only
prefixing these special keys, we can avoid the cost of constructing new strings
in the common case.
To check whether a key is special, we check whether it is in an empty map
instance. In addition, keys that are already null-prefixed must be prefixed a
second time to correctly unescape.
Preallocate the keyValues array and use a single Map with the
sentinel value `true` to represent a previously seen key.
Before:
selection.data(values, key) (enter) 1.5ms/op.
selection.data(values, key) (update) 1.7ms/op.
After:
selection.data(values, key) (enter) 0.81ms/op.
selection.data(values, key) (update) 1.1ms/op.
Due to the tests using two different copies of d3 (one loaded via require, and
the other via smash), the instanceof check in the d3.lab constructor was
returning false when testing for d3.hcl, and this constructor was therefore
never tested.
* uninterpolate:
The use of a reciprocal in d3_uninterpolateNumber to avoid division
results in a small loss of precision (the following is a paraphrase):
function d3_uninterpolateNumber(a, b) {
var k = b - a ? 1 / (b - a) : 0;
return function(x) { return (x - a) * k; };
}
For x = a, there is no problem, since u = (a - a) * k = 0 * k = 0 as
expected. For x = b, we have u = (b - a) * k, and since k cannot
represent 1 / (b - a) exactly, we don’t get u = 1, but something very
close to 1.
Instead, if we perform the division within the generated function, we
can ensure we always get u = 1 for x = b:
function d3_uninterpolateNumber(a, b) {
var k = b - a || Infinity;
return function(x) { return (x - a) / k; };
}
Again, for x = a, we simply have u = (a - a) / k = 0. For x = b, we
have u = (b - a) / k = (b - a) / (b - a) = 1.
* interpolate:
Similarly, for d3_interpolateNumber, we have a small loss of precision,
this time due to subtraction. Paraphrased:
function d3_interpolateNumber(a, b) {
var d = b - a;
return function(t) { return a + t * d; };
}
There is no issue for t = 0, because we always get i = a + 0 * d = a.
However, for t = 1, we get i = a + d, which might not be exactly equal
to b as desired. The following will return precisely b for t = 1:
function d3_interpolateNumber(a, b) {
return function(t) { return a * (1 - t) + b * t; };
}
Very small or large numbers use exponent notation when converted to
strings. If grouping is enabled and there is no decimal, the exponent
wasn’t being ignored, so the group separator was in the wrong place.
This also fixes a bug relating to padding and thousands grouping: the
padding calculation assumed a grouping of [3].
Fixes#1972, #1994.
Fixes#1968. For example, when switching from a linear scale to a
logarithmic scale, some of the exiting ticks might be positioned at
Infinity in the new scale (zero and negative numbers). This can cause a
warning to be logged in the console due to the resulting invalid
transform attribute. The warning doesn’t prevent the rest of the axis
from functioning normally (even though it is logged as an “error”), but
it is preferable to avoid setting invalid attributes.
There was a bug when parsing positive time zone offsets with a non-zero
number of minutes: the use of Math.floor on negative numbers rounded in
the wrong direction. Replacing Math.floor with (x | 0) correctly
truncates positive and negative values.
Slice is shorter and more intuitive: negative arguments are treated as
being relative to the end of the string, similar to arrays.
The only place it made sense to keep substring was in
d3_locale_numberFormat, where the first argument can be negative but
substring automatically treats this as zero.
Fixes a regression introduced when XDomainRequest support was added in
2eeb2057b2. XDomainRequest only supports
request.responseText, not request.response, but XMLHttpRequest throws an
error if request.responseText is read for non-text response types.
A status code of 0 can mean either a local file was accessed, or there
was an error. The response is checked to see if the error flag was set:
* In the case of request.responseType being "text" or "",
request.responseText should be "". Unfortunately it’s impossible to
distinguish between an empty local text file and an error state, but
wanting to load empty local files seems rare.
XDomainRequest doesn’t have a responseType and it only has
responseText, so we handle it here too.
* For other response types, request.response should be null. At the
moment, Safari 7.0.5 doesn’t respect this, e.g. the response will be a
zero-length blob for the "blob" response type if the local file wasn’t
found, but this seems to be fixed as of WebKit r171650.
Mike Bostock
Jason Davies
John Firebaugh