On 03/23/2012 07:01 AM, Damian Conway wrote: > Patrick correctly observed: > >> On Rakudo on my system, sqrt(2) indeed produces a Num, >> but since floating point arithmetic doesn't result in >> sqrt(2) / 1 == 2 / sqrt(2), no geometric sequence is deduced >> and the sequence fails with "unable to deduce sequence". > > Although, arguably, that might be considered a bug. > > Not that sqrt(2) / 1 should == 2 / sqrt(2) of course, but that, when > deducing a sequence we know we're comparing quotients, so 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". ;-)
But unless we twist smartmatching semantics for that purpose, it means we cannot do the same fuzziness for the endpoint, condemning people to write infinite loops instead of failing fast. So I'm firmly against such magic. All the previous iterations of the sequence operator had some additional degrees of magic, and we've come to regret all of them. This discussion makes me think that maybe deducing geometric sequences is too much magic as well. Cheers, Moritz
