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

[William Dillon]

I hope I’m not missing something, but I think Erica’s point on #1 is really important. When I originally learned about stride I assumed that the meaning of though was entirely different than what it really was. Erica’s idea brings it inline with my expectation based on its name.

Ignoring floating point entirely (which is still problematic):

print(Array(1.stride(through: 16, by: 7)))   
// prints [1, 8, 15]
// I would expect [1, 8, 15, 22]
print(Array(1.stride(to: 16, by: 7)))        
// prints [1, 8, 15]
The only cases where through behaves as I expect in the integer case is when the stride is a factor of through.

I do understand why someone would want to have a stride that ends on the terminal number if it equal, and not go over, but it feels like a label such as including, or something similar, would be more appropriate.

- Will





On February 27, 2016 at 5:06:36 PM, 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

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/9a3d153c/attachment.html>