Paul Eggert wrote: > Pádraig Brady <[EMAIL PROTECTED]> writes: > >> I haven't time to look at this now, >> but will soon. > > Thanks. > >> A couple of points came to mind. >> >> Is it OK to look at just 1 value "after" last? > > It should not be necessary to look 2 values "after" last. The problem > we're trying to address is the bug where "seq" doesn't print "last". > Looking just 1 value "after" last should suffice to detect the bug. > >> Aren't you susceptible to whatever rounding >> printf does internally? > > Yes, that's quite true. One can easily construct examples where the > revised "seq" is mathematically incorrect, due to this problem. > For example, on x86: > > $ seq -f %.20g 0 0.1 1.3 > 0 > 0.1 > 0.2 > 0.30000000000000000001 > 0.40000000000000000001 > 0.5 > 0.60000000000000000002 > 0.69999999999999999999 > 0.80000000000000000001 > 0.90000000000000000003 > 1 > 1.1 > 1.2 > > This problem arises because 1.3 is internally represented as > 1.29999999999999999995663191310057982263970188796520233154296875, > which when formatted using %.20g displays as "1.3"; but 0.1 is > internally represented as > 0.1000000000000000000013552527156068805425093160010874271392822265625, > when you multiply that by 13 and round you get > 1.300000000000000000065052130349130266040447168052196502685546875, > which when formatted using %.20g displays as "1.3000000000000000001"; > so "seq" decides that the "after" value is too large and does not > display it.
Here is another way of triggering the same issue. Comparing the output from both patches, seq-pb prints an extra value (which is arguably more correct): $ ./seq-paul .1 .10000000000000000000 .9 | tail -1 0.80000000000000000001 $ ./seq-pb .1 .10000000000000000000 .9 | tail -1 0.90000000000000000003 However seq-pb incorrectly prints an extra value here. Operating up at the end of the range is unlikely, but still... $ ./seq-paul 922337203685477580.4 0.100 922337203685477580.5 922337203685477580.375 922337203685477580.500 $ ./seq-pb 922337203685477580.4 0.100 922337203685477580.5 922337203685477580.375 922337203685477580.500 922337203685477580.562 > > However, I don't think it's a serious problem worth fixing, since it > should be clear to the user by looking at the intermediate values that > rounding errors are causing the problem. We cannot avoid rounding > errors in general, unless we switch to an arbitrary-precision package. > > Also, for this example the original "seq" is buggy in the same way. > If you look at the source code of the change I proposed, it's easy to > prove that the revised version will never print fewer numbers than the > original, so it can't possibly exhibit the bug in places where the > original does not already exhibit the bug. That's a nice property. > > The only bug that it could possibly introduce, is printing an extra > value that the user does not want printed. I can't easily think of a > case where that would happen, though I suppose it's possible. So Paul, Thank you for the explanation and fixing this up. You rock. Pádraig. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
