<div dir="ltr"><div><div>One such safe guard could be:</div><div>(length (for/list ([i (in-range (inexact->exact .1) (inexact->exact .8) (inexact->exact .1))]) i)) ; 7</div></div><div><br></div><div>But of course that slows things down.</div><div><br></div><div>Btw, the reason it outputs 8 in the bad case is because on my machine:<br></div><div><div>(for/sum ([i 8]) .1) ; 0.7999999999999999</div></div><div><br></div><div>which is then below the .8 threshold.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 3:41 PM, Laurent <span dir="ltr"><<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I've discovered a rather troubling behaviour when using `in-range` with floating point numbers, which I think is worth knowing in case you hadn't consider the issue before:<br></div><div><br></div><div>On my machine, I get the following:</div><div><div><br></div><div>(length (for/list ([i (in-range .1 .7 .1)]) i)) ; 6</div><div>(length (for/list ([i (in-range .1 .8 .1)]) i)) ; 8 (!)</div></div><div><br></div><div>But:</div><div><div>(length (for/list ([i (in-range 1/10 7/10 1/10)]) i)) ; 6</div><div>(length (for/list ([i (in-range 1/10 8/10 1/10)]) i)) ; 7</div></div><div><br></div><div><br></div><div>Would it be a good idea to safe-guard these kinds of cases directly in `in-range`?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div><br></div>