On 03/23/2012 09:14 AM, Damian Conway wrote:
>> it means we cannot do the same fuzziness for the endpoint,
> Except that we will be encouraging people to use: * >= $END
> as their standard endpoint pattern, which will provide
> most of the necessary fuzz.

and which will still surprise those people who are surprised
by floating point inaccuracies.

>> This discussion makes me think that maybe
>> deducing geometric sequences is too much magic as well.
> Geometric sequence inference is fine on Ints and Rats.
> But, if we can't perform inferences involving Nums in a sound numerical
> way (and it may well be that we can't, without taking a noticeable
> performance hit), then I think that we would be better off limiting the
> deduction of *both* arithmetic and geometric sequences to starting lists
> that contain only Ints and Rats.

Floating point numbers *can* represent a huge number of commonly used
values without errors, and you can do error-free arithmetic operations
on many of them. Excluding Nums from automatic deduction feels like an
unnecessary pessimization or stigmatization, especially if you consider
that writing a number like 0.001 in your program gives a Rat by default
not a Num.

Most of the time you only get a Num in Perl 6 if you consciously decide
to write one, in which case you should also be well aware of the
limitations of FP math.

At least in #perl6 I've never seen anybody try to write an auto-deduced
sequence, and fail because of floating-point errors.


Reply via email to