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

[Joe Groff]

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?

Arguably, floating point types shouldn't conform to Strideable at all, on
the general principle that genericizing arithmetic over ints and floats is
a trap. That would free floating point types to provide their own
specialized implementation of the stride methods. 

> 
> In both cases, I'd still prefer the semantics to *go through* the end
> point, not just stop at it, which is issue 1.

I'll have to defer to domain experts on this one. It seems superficially
appealing at least. If your only motivation is to get 1.0 through 2.0 by
0.1 to include 2.0, though, that feels like weak justification to me, since
that's a symptom of a different problem. 
> 
> -- E
> 
> 
>