<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 class=""><br class=""></div><div class="">-Joe</div></div></div></blockquote></div><br class=""><div class="">Agreed. This is "papering over the problem" of accumulated floating point error. There are two issues being addressed:</div><div class=""><br class=""></div><div class="">1. Semantics of `through` do not match their promise of going through the end point rather than stopping at it or before.</div><div class="">2. Floating point strides accumulate errors by repeatedly adding the `by` interval.</div><div class=""><br class=""></div><div class="">I mention issue 2 in the alternative implementations: <a href="https://gist.github.com/erica/03c398c06f6c47824429" class="">https://gist.github.com/erica/03c398c06f6c47824429</a></div><div class=""><br class=""></div><div class=""><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255); margin-bottom: 0px !important;" class=""><li style="box-sizing: border-box;" class="">Counting expected iterations by forming <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', 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;" class="">(max - min) / by</code>, e.g. <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', 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;" class="">(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 class=""><br class=""></div><div class="">If you were addressing issue 2, what approach would you suggest:</div></div><div class=""><br class=""></div><div class="">* Differentiating integer strides from floating point, and minimizing floating point errors?</div><div class="">* Leaving the tech as-is with minimal code change with a relatively high benefit?</div><div class=""><br class=""></div><div class="">In both cases, I'd still prefer the semantics to *go through* the end point, not just stop at it, which is issue 1.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></body></html>