> But unless we twist smartmatching semantics for that purpose,
No!
Please, no.
;-)
> 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.
> So I'm firmly against such magic.
But that's the point: it's not magic. It's correct numerical computation
under the limitations of floating-point arithmetic. As discussed in
every numerical computing textbook for the last half a century.
Note that this problem occurs for *arithmetic* deductions as well.
If either number is floating point, some loss of precision in the
difference between them is almost inevitable, especially if the two
numbers are very close.
For example:
1, 1.000000000001, 1.000000000002 ... *
won't deduce a correct arithmetic sequence either (on most hardware).
In fact that example would be slightly more likely to imply a geometric
sequence, since a division operation loses fewer significant digits than
a subtraction when the arguments are both so close to 1.0)
> 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.
Damian
