-
Notifications
You must be signed in to change notification settings - Fork 13
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?