<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 5:16 PM, Erica Sadun via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><h1 style="font-size:2.25em;margin-right:0px;margin-bottom:16px;margin-left:0px;line-height:1.2;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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;;background-color:rgb(255,255,255);margin-top:0px!important">Decoupling Floating Point Strides from Generic Implementations</h1><ul style="padding:0px 0px 0px 2em;margin-top:0px;margin-bottom:16px;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)"><li>Proposal: SE-00XX</li><li>Author(s): <a href="http://github.com/erica" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank">Erica Sadun</a></li><li>Status: TBD</li><li>Review manager: TBD</li></ul><p style="margin-top:0px;margin-bottom:16px;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)">Swift strides create progressions along &quot;notionally continuous one-dimensional values&quot; using a series of offset values. This proposal replaces the Swift&#39;s generic stride implementation with seperate algorithms for integer strides (the current implementation) and floating point strides.</p></div></blockquote><div>&lt;snip&gt;</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><p style="margin-top:0px;margin-bottom:16px;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)">If one were looking for a quick and dirty fix, the same kind of math used in this rough solution (<code style="font-family:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;border-radius:3px;background-color:rgba(0,0,0,0.0392157)">let value = start + count * interval</code>) could be adopted back into the current generic implementation.<br></p></div></blockquote><div><br></div><div>I would rather see this solution adopted.  Yes, it&#39;s inexact, but it&#39;s about as exact as you can get with floating point numbers, and anyone working with floating point numbers knows that you&#39;re not going to get an exact decimal back.  At least it avoids accumulated errors and guarantees that the proper number of values will be returned, to the limits of floating point precision.</div><div> </div><div>The problem with de-generifying Strideable is that oftentimes you may start out working with integers and then find you need to change to floats to accommodate a new requirement.  That could have very inconvenient ripple effects if stride, arithmetic, etc. are not generic.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.225;font-size:1.75em;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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;;background-color:rgb(255,255,255)"><a href="https://gist.github.com/erica/cf50f3dc54bb3a090933#alternatives-considered" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"><u></u><u></u><u></u><u></u></a>Alternatives Considered</h2><div style="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">While precision math for decimal numbers would be better addressed by introducing a decimal type and/or warnings for at-risk floating point numbers, those features lie outside the scope of this proposal.</div><div><br></div></div></blockquote></div><br></div></div>