<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="">Say you wanted to stride through a singly-linked list, it would actually be beneficial to support only forward strides, the same is true of sequences, as you either may not know what the endpoint is, or would have to step through the whole sequence to find it (plus buffer every value in order to do-so safely).<br class=""></div></blockquote><div class="">What if you are already somewhere in the middle (perhaps landed there by means of some other reference/link) of that linked list and want to stride backward? </div><br class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">A consistent behavior with signed distances is so important that we are currently struggling with an interesting issue with floating point types, which is that due to rounding error 10.0 + a - a != 10.0 for some values of a.<br class=""></blockquote></div></blockquote><div class="">Of course ! </div><div class="">This is known (in computer domain) since ca. 1938.. (Konrad Zuse, with 22-bit floats) </div><div class="">(btw I am glad that computer development in this critical war times especially in</div><div class="">nazi-Germany was extremely slow, relatively speaking, just imagine...) </div><div class=""><br class=""></div><div class="">So, this should come as no surprise. </div><div class="">Precision loss occurs with all arithmetic operations on floats. </div><div class="">(in the above case probably the intermediate </div><div class="">expression evaluation around the != , </div><div class="">Compiler optimization may also cause</div><div class="">even further reduction of floating point precision )</div><div class=""><br class=""></div><div class="">Obviously, when working with floating point numbers </div><div class="">one must always be aware of this and design/program </div><div class="">accordingly. This should become second nature.</div><div class=""><br class=""></div><div class="">E.g. it is perfectly acceptable and known (also in classical for-loops) </div><div class="">that </div><div class=""> (0.0…1.0).by(0.1)</div><div class="">is not guaranteed to reach the humanly expected value of 1.0.</div><div class=""><br class=""></div><div class="">Due to the nature of what mostly is done in the floating point numbers domain, </div><div class="">this does not often cause problems (e.g like working with a slide ruler) </div><div class=""><br class=""></div><div class="">if it is important to reach the “expected end” then one could</div><div class="">-add a precision loss compensating value like so </div><div class=""> (v1…v2 + 0.1) </div><div class="">-or generate the desired float sequence within an integer loop **</div><div class=""><br class=""></div><div class="">The whole point with stride() here is perhaps because the attempt</div><div class="">to treat Continuous Data (floats) as Discrete Data (Integers) ? </div><div class=""><br class=""></div><div class="">What about range operator? </div><div class=""> with floats, (a…b) will never work correctly (accept this as normal, inherent with floats) </div><div class=""><br class=""></div><div class="">I’d suggest </div><div class=""> (a<.<b) or (b<..<a) , depending on whether a < b or b < a</div><div class=""><br class=""></div><div class="">In the stride function, swap a and b depending on the sign of the step value </div><div class="">(see a previous email from me for an example, I also had</div><div class="">a bounds tolerance factor implemented in that code</div><div class="">as an attempt to cope with float boundary “problems” )</div><div class=""><br class=""></div><div class="">** The whole problem would disappear if one would generate the desired float collection within an integer iteration</div><div class="">e.g.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""></blockquote> for i in 0..<10 <br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""></blockquote> {<br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""></blockquote> ar.append(vstart + Double(i) * vstep)<br class=""> }<div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><a href="https://en.wikipedia.org/wiki/Floating_point" class="">https://en.wikipedia.org/wiki/Floating_point</a>,</div><div class="">especially the topic "Minimizing the effect of accuracy problems” might be interesting here.<div class=""><br class=""></div><div class="">n.b. in Pascal, the for loop has also a “downto” keyword.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Kind regards</div><div class=""><br class=""></div><div class="">TedvG<br class=""><div class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></div></body></html>