[swift-evolution] [Discussion] stride behavior and a little bit of a call-back to digital numbers

[Howard Lovatt]

I think you have raised a valid concern. But would suggest a simpler
solution, remove stride for floating point. You can always write:

100.stride(through: 200, by 25).map { $0 / 100.0 }

On Sunday, 28 February 2016, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> As implemented, `stride` is broken for floating-point numbers. Instead of
> repeatedly adding the `by` interval, it should multiply the interval by
> successive integral values and add that to the base to avoid accruing
> error. Your proposal only papers over the problem.
>
> -Joe
>
>
> Agreed. This is "papering over the problem" of accumulated floating point
> error.  There are two issues being addressed:
>
> 1. Semantics of `through` do not match their promise of going through the
> end point rather than stopping at it or before.
> 2. Floating point strides accumulate errors by repeatedly adding the `by`
> interval.
>
> I mention issue 2 in the alternative implementations:
> https://gist.github.com/erica/03c398c06f6c47824429
>
>
>    - Counting expected iterations by forming (max - min) / by, e.g. (2.0
>    - 1.0) / 0.1, which is 10, and performing each step as a pro-rated
>    progression along those steps, which would remove most of the accumulated
>    floating point errors along the way.
>
>
> If you were addressing issue 2, what approach would you suggest:
>
> * Differentiating integer strides from floating point, and minimizing
> floating point errors?
> * Leaving the tech as-is with minimal code change with a relatively high
> benefit?
>
> In both cases, I'd still prefer the semantics to *go through* the end
> point, not just stop at it, which is issue 1.
>
> -- E
>
>

-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/e7bc8da8/attachment.html>