Revert fancy range behavior.

[andreasplesch]

While the new range() function is improved, it still produces an extra element for some fractional step sizes.

 range(0, 1, 1/49).length;
50

Also see d3/d3#2524

A fix may have to take into account limited floating point precision, in a similar way to pull request
d3/d3#2526

The problem is

(1-0)/(1/49)
49.00000000000001

which is upped to 50 by Math.ceil().

[andreasplesch]

The workaround used in d3/d3#2524 still applies:

eps=1e-15;
range(0, 64).forEach(function(m){rmax=Math.pow(2,m);
  range(1, 1000).forEach( function(d) {rmax=Math.pow(2,m);
  if (range(0, rmax*(1-eps), rmax/d).length !== d) {console.log(d) ;}})})

does not find mismatches in firefox; still need to test in chrome.

This suggests a similar fix, eg. adjust stop by (1-eps) * stop .

Thinking a bit more about it, it is probably necessary to adjust the difference between start and stop, rather than just stop; eg. use (stop - start)*(1-eps) to determine n.

[andreasplesch]

Here is a gist which does some checks of the range() function.

http://bl.ocks.org/andreasplesch/ada4b4e89738d4e5d4af

It turns out the workaround is useful but not very good for larger offsets (larger numbers) even when using the (stop-start)*(1-eps) adjustment .

[andreasplesch]

Well, I decided to go back to integer ranges.

Perhaps it is worthwhile to add to the documentation that if the number of elements in the generated array is expected to be exactly n, then one should use something like

// var step = (stop - start)/n;
var step = mystep;
d3.array(0, n).map( function(d) {return start + d * step;};

or perhaps provide this as another range function, say d3.nrange(), which takes start, step and number of elements n.

[mbostock]

Hmm. I’m tempted to remove the scale hack entirely, since it only works for some cases and makes the behavior harder to understand.

In general, you shouldn’t expect range(0, 1, 1/n) to return exactly n results because of the limitations of floating point. Using range(0, n).map(function(i) { return i / n; }) is recommended, and I’m in favor of documenting this recommendation.

[mbostock]

Related d3/d3#494, D3 version 2.7.5, commit d3/d3@87f48b7.

[andreasplesch]

Perhaps with the original commit above I now can understand what the conversion to integer is about but it did make the behaviour more opaque. I would say remove it, and perhaps emphasize the limitations a bit more in the documentation.
It took me a little to figure out that the range() behaviour was the issue when I originally used it for
http://bl.ocks.org/andreasplesch/49b2130b15425c1eebc0/
and got some weird results.
So documentation would be great. I tried to keep the additions in my pull request #6 concise but feel free of course to edit as you feel appropriate. I left the start value in there since for some it may not be too trivial to have seen in an example.

[mbostock]

Re-opening this request, because I think you are right that we should remove the fancy behavior.

[mbostock]

Fixed in 0.1.2; see d2364d4.