Paul Eggert wrote: > Pádraig Brady <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
