Re: [PATCH] SEQ BUG

[Pádraig Brady]

Paul Eggert wrote:
> Pádraig Brady <address@hidden> writes:
> 
>> This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
> 
> I see some problems with that patch.
> 
> First, it continues to mishandle some similar cases.  For example,
> 'seq 0.1 1e-1 0.9' outputs only 0.1 through 0.8, i.e. it behaves
> differently from 'seq 0.1 0.1 0.9', which is counterintutive.  I can
> easily see getting some bug reports about that.

Agreed. The old behaviour is better than that.
Hmm, off the top of my head, I don't see any way to
approximate the precision of nums in the form 1e-1

> 
> Second, it mishandles some cases that the current code handles
> correctly.  For example, on my platform (Debian stable x86 with GCC
> 4.2) 'seq 922337203685477580.4 0.1 922337203685477580.5' currently
> outputs this:
> 
> 922337203685477580.4
> 922337203685477580.5
> 
> which is correct, but with the proposed patch it outputs this:
> 
> 922337203685477580.4
> 922337203685477580.5
> 922337203685477580.6
> 
> due to rounding errors in 'long double' arithmetic (which uses a 64
> bit fraction on my platform).

I don't think that is a normal use case for seq,
and I was basically sacrificing accuracy at this end.

> The "right" way to address this problem is to use arbitrary-precision
> decimal arithmetic.  By comparison, fiddling with fixed-width IEEE
> binary formats is problematic; it may fix some cases but it'll
> probably introduce other problems and it'll make it harder to explain
> the inevitable quirks.

Agreed.
I'll think a bit more, whether it's possible to handle the first case better.

thanks for the review!
Pádraig.