Re: [PATCH] SEQ BUG

[Pádraig Brady]

Paul Eggert wrote:
> 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.

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.