[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] SEQ BUG
From: |
Pádraig Brady |
Subject: |
Re: [PATCH] SEQ BUG |
Date: |
Fri, 22 Jun 2007 23:41:24 +0100 |
User-agent: |
Thunderbird 1.5.0.8 (X11/20061116) |
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.
- Re: [PATCH] SEQ BUG, (continued)
- Re: [PATCH] SEQ BUG, Pádraig Brady, 2007/06/19
- Re: [PATCH] SEQ BUG, Paul Eggert, 2007/06/19
- Re: [PATCH] SEQ BUG, Pádraig Brady, 2007/06/20
- Re: [PATCH] SEQ BUG, Pádraig Brady, 2007/06/20
- Re: [PATCH] SEQ BUG, Paul Eggert, 2007/06/22
- Re: [PATCH] SEQ BUG, Pádraig Brady, 2007/06/22
- Re: [PATCH] SEQ BUG, Paul Eggert, 2007/06/22
- Re: [PATCH] SEQ BUG, Jim Meyering, 2007/06/22
- Re: [PATCH] SEQ BUG, Micah Cowan, 2007/06/22
- Re: [PATCH] SEQ BUG, Paul Eggert, 2007/06/22
- Re: [PATCH] SEQ BUG,
Pádraig Brady <=
- Re: [PATCH] SEQ BUG, Paul Eggert, 2007/06/22
- Re: [PATCH] SEQ BUG, Jim Meyering, 2007/06/23
Re: SEQ BUG, John Cowan, 2007/06/07