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

[Erica Sadun]

I'd really dislike any solution that makes Swift programming worse than where it currently is. 

-- E


> On Feb 27, 2016, at 6:28 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> 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 <mailto: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 <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/20160227/98d83e5b/attachment.html>