I think you have raised a valid concern. But would suggest a simpler solution, remove stride for floating point. You can always write:<div><br></div><div>100.stride(through: 200, by 25).map { $0 / 100.0 }<br><br>On Sunday, 28 February 2016, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div>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.</div><div><br></div><div>-Joe</div></div></div></blockquote></div><br><div>Agreed. This is &quot;papering over the problem&quot; of accumulated floating point error.  There are two issues being addressed:</div><div><br></div><div>1. Semantics of `through` do not match their promise of going through the end point rather than stopping at it or before.</div><div>2. Floating point strides accumulate errors by repeatedly adding the `by` interval.</div><div><br></div><div>I mention issue 2 in the alternative implementations: <a href="https://gist.github.com/erica/03c398c06f6c47824429" target="_blank">https://gist.github.com/erica/03c398c06f6c47824429</a></div><div><br></div><div><ul style="padding:0px 0px 0px 2em;margin-top:0px;color:rgb(51,51,51);font-family:&#39;Helvetica Neue&#39;,Helvetica,&#39;Segoe UI&#39;,Arial,freesans,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255);margin-bottom:0px!important"><li>Counting expected iterations by forming <code style="font-family:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">(max - min) / by</code>, e.g. <code style="font-family:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">(2.0 - 1.0) / 0.1</code>, 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.</li></ul><div><br></div><div>If you were addressing issue 2, what approach would you suggest:</div></div><div><br></div><div>* Differentiating integer strides from floating point, and minimizing floating point errors?</div><div>* Leaving the tech as-is with minimal code change with a relatively high benefit?</div><div><br></div><div>In both cases, I&#39;d still prefer the semantics to *go through* the end point, not just stop at it, which is issue 1.</div><div><br></div><div>-- E</div><div><br></div></div></blockquote></div><br><br>-- <br>-- Howard.<br>