> 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