Re: Floating-point equality (was Re: How to make a new operator.)
On 03/25/2012 06:55 AM, Moritz Lenz wrote: > I don't know if the majority of the perl6-language posters have realized > it yet, but both Perl 6 and the its implementations are quite mature > these days. Mature enough that such proposals should be prototyped as > modules, and thoroughly tested on lots of existing code before taken > into consideration for ... inclusion into the spec. Sometimes I do finish my sentences with several hours delay, sorry for that. Cheers, Moritz
Re: Floating-point equality (was Re: How to make a new operator.)
On 03/25/2012 05:59 AM, David Green wrote: > 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.2) # false Note that neither 22/7 nor 0.002 are floating-point values. I don't know if the majority of the perl6-language posters have realized it yet, but both Perl 6 and the its implementations are quite mature these days. Mature enough that such proposals should be prototyped as modules, and thoroughly tested on lots of existing code before taken into consideration for Niecza supports operator adverbs, and supports them on user-defined operators, so there's nothing to stop you from trying it. Cheers, Moritz
Floating-point equality (was Re: How to make a new operator.)
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.2) # 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
