-
Notifications
You must be signed in to change notification settings - Fork 10
Description
Many languages include a way to sample numbers along by the amount of samples instead of a step e.g. numpy.linspace. This is particularly useful for graphs and scientific computing.
Most languages/libraries include this as a separate function, but I think it's fairly arbitrary distinction (e.g. range being in the standard library and linspace in an external library), and works out nicely here as conceptually it's also iterates over numbers in a range from start to end and the with the optionOrStep argument we can "overload" with another property that is mutually exclusive with step it and inclusive also makes sense as an option.
I'm sure about the name, I'll go with length here, count also sounds reasonable but I think it's slightly nicer if it matches length property on arrays.
inclusive has different semantics and defaults to true:
Iterator.range(start, end, { length })-> (start, ..., end)Iterator.range(start, end, { count, inclusive: false })-> (...)
The only mention I saw of this is #64 with this example:
Iterator.range(0, sampleCount).map(i => start + (end - start) * i / sampleCount)This is fairly verbose and not immediately readable to people not familiar with lerping.
But more importantly it's error prone. In fact this already has a mistake in it - it needs i / (sampleCount - 1) to include the end.
A theoretical Math.lerp doesn't make it much better:
Iterator.range(0, sampleCount).map(i => Math.lerp(start, end, i / (sampleCount - 1)))Compared to:
Iterator.range(start, end, { length: sampleCount })I don't think this necessarily needs to be part of this proposal, and if IIUC stage 2 is too late for that?
But this brings up a bigger point for future compatibility: If optionOrStep is an object, it currently ignores unknown keys so it cannot be added in the future because old behavior can suddenly change, and new behavior will give an incorrect results on old runtimes and impossible to feature detect.
Will throwing on unknown keys solve this? Is this precedence for this with other options style arguments in other functions?