Re: [PATCH] SEQ BUG

[Paul Eggert]

Pádraig Brady <address@hidden> 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.

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.