On 2012-March-23, at 12:01 am, Damian Conway wrote: > [...] we ought to allow for the inevitable loss of significant digits within > the two preliminary division ops, and therefore compare the results with an > suitably larger epsilon. > That would not only be computational more justifiable, I suspect it might > also produce more "least surprise". ;-)
I think that comparisons for floating-point values should take some kind of 'significance' adverb and complain if it's missing. Having to be explicit makes for the least surprise of all. π == 22/7 # error π == 22/7 :within(0.002) # true π == 22/7 :within(0.00002) # false Probably with something like 'use epsilon :within(0.0002)' as way to declare the fuzziness for a given scope if you have a lot of comparisons. And of course you could use (the equivalent of) 'use epsilon :within(0)' to say, "I know what I'm doing, just give me straight what I ask for and I'll take the consequences." Alternatively, maybe have float-comparisons give an error or warning, and introduce an "approximation operator": π == ~22/7 :within($epsilon). (Except "~" is already taken!) [I was going to suggest that as a way to handle stopping points in a sequence: 1, 3, 5 ... ~10, but that still wouldn't work without treating the Num::Approx values as a special case, which defeats the purpose. Though with a postfix "up from" operator, you could say: 1, 3, 5 ... 10^.] -David
