<div dir="ltr">Silvio, Brandon, Ben: thanks for your instructive comments. Please allow me to dwell on this issue for 5 more minutes - I'm really interested in your opinion. Do you think it would be bad if we changed the definition of numericEnumFromThenTo e1 e2 e3 in such a way that the resulting list would never contain elements that are greater than e3 (in the e1 <= e2 case)? <br><div><br></div><div>I'm asking because you can actually be bitten by this quirk of enumerated lists of Doubles (and Floats) even if you don't use floating-point literals explicitly. Consider the following (this is how I stumbled upon this issue actually):</div><div><br></div><div><div><font face="monospace, monospace">-- "odd semi-factorial" of n      </font></div><div><font face="monospace, monospace">osf n = product [1, 3 .. n]</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">-- "even semi-factorial" of n</font></div><div><font face="monospace, monospace">esf n = product [2, 4 .. n]    </font></div></div><div><br></div><div>Load this into GHCi and then go:</div><div><br></div><div><div><font face="monospace, monospace">*Main> osf 4</font></div><div><font face="monospace, monospace">3</font></div><div><font face="monospace, monospace">*Main> esf 4</font></div><div><font face="monospace, monospace">8</font></div><div><font face="monospace, monospace">*Main> osf 4 / esf 4</font></div><div><font face="monospace, monospace">1.875</font></div></div><div><br></div><div>This last result looks total nonsense at first glance - it took me a good 15 minutes to realize what was going on. Of course, if I provide reasonable type signatures (e.g., Integer -> Integer) for osf and esf, then the problem goes away. </div><div><br></div><div>Still, to me this strange result is a lot more surprising and unexpected than the fact that e.g., [1.0, 1.1 .. 2.3] would not actually contain (a value close to) 2.3 if we changed the definition of numericEnumFromThenTo. After all, it's fairly common knowledge that floating-point arithmetic is inexact and you're not supposed to rely on precise equality of two floating-point values, or you shouldn't be surprised if basic mathematical identities don't hold for floating-point values (e.g., 1 + 2*0.1 /= 1 + 0.1 + 0.1). Whereas the apparent "change" in the value of osf 4 from one line to the next above is more baffling I believe. But what do you think?</div><div><br></div><div>Regards,</div><div>Bence</div><div><br></div></div>