Precision lost (1e-324 + 1e-324) === (1e-324) behavior
Jack-Works opened this issue · comments
What if the yielded number is too small and loosing precision?
Prior discussion: #7. Prior discussion is too long and mixed two cases of "dead loop" so I decided to split them into two issues.
There were many possible behaviors suggested in #7 for this situation. By studying this behavior in other languages, I found there isn't too much example we can learn from (most of the languages I studied seems like doesn't support range for floating-point numbers). I personally have no preference in this situation so I'm open to this and happy to see the consensus reached in some way.
| Language | Behavior |
|---|---|
| This proposal | Not decided yet |
Swift (StrideTo) |
Emit nothing |
(The full table at https://github.com/tc39/proposal-Number.range/blob/master/compare.md#too-small-floating-point-error-behavior)
What precisely is the scenario you're interested in here? Following your link, I assume it's something like the Swift example: for i in stride(from: 1e323, to: (1e323 + 1e-323 * 2), by: 1e-323).
Like #33, this already has a reasonable answer from just following the current proposed spec. If step is very small (less than 1ulp around start), the range can emit the same value multiple times, but eventually start + (step * currentCount) will yield a larger Number, and eventually it will hit or exceed end and the range will be finished, after approximately (end-start)/step iterations.
Alternately, if start and step are close enough that they collapse to the same Number, the range will just end immediately after emitting nothing.
Like #33, I don't think we should try for any "smarter" behavior; the current spec is well-defined, well-behaved, and understandable.
Yes, I agree. This problem disappeared after we switch from + semantics to * semantics. I think it's resolved now.
I'll mark it as resolved. If anyone has new concerns welcome to leave comments.