interpolateTypedArray

[Fil]

fixes #39

test: https://observablehq.com/d/d966cf85471db4f7

[mbostock]

What do you think about folding this into interpolateArray (so that interpolateArray checks the type of the target array b) rather than adding a new interpolateTypeArray method?

[Fil]

That detection is now made at the level of interpolate; having it at the level of interpolateArray would mean we have it twice (not a big deal).

Another consequence is that it would prevent the use of interpolateArray to coerce to a standard array (but this is something that we should not recommend in any way). The typical example for this is d3.interpolate([0.9], Uint8Array.from([0]))(0.1): d3.interpolateArray gives Array[0.81], the new method gives Uint8Array[0].

Internally, interpolateArray and interpolateTypedArray have a different machinery: to interpolate typed arrays we have no intermediate array of interpolators, only a for loop on the two arrays (we can't even use an array of the differences, because of unsigned types). So that function will still be here, only not exposed as a separate method. But it simplifies the API and does "the right thing", so overall it's probably better to fold this into interpolateArray.

[mbostock]

It also occurs to me that we could have an interpolateNumberArray that works on all types arrays but also works on a generic array, coercing the elements to numbers in the same fashion as interpolateNumber and avoiding the need to create an interpolator function per element. Then if you wanted the “fast” interpolator for a generic array, you could opt-in to interpolateNumberArray instead of interpolateArray.

[Fil]

I think I would advertise interpolate (a, Float64Array.from(b)) as the faster solution (rather than add another API method).