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 

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^.]


Reply via email to