Paolo Benvenuto wrote:
> while "seq 1.1 9.1 gives only 8 lines:
> 1.1
> 2.1
> 3.1
> 4.1
> 5.1
> 6.1
> 7.1
> 8.1
Just noting that this is architecture dependent. 64-bit hosts in
particular will probably get this "right" while 32-bit hosts will have
the above output.
> That's confusing. I expect seq behaves the same way in the two cases.
Thanks for the report. This behavior is however as documented in the
coreutils seq documentation. This following is from the coreutils
info documentation.
$ info coreutils seq
Be careful when using `seq' with a fractional INCREMENT, otherwise
you may see surprising results. Most people would expect to see `0.3'
printed as the last number in this example:
$ seq -s' ' 0 .1 .3
0 0.1 0.2
But that doesn't happen on most systems because `seq' is implemented
using binary floating point arithmetic (via the C `double' type) -
which means some decimal numbers like `.1' cannot be represented
exactly. That in turn means some nonintuitive conditions like
`.1 * 3 > .3' will end up being true.
To work around that in the above example, use a slightly larger
number as the LAST value:
$ seq -s' ' 0 .1 .31
0 0.1 0.2 0.3
In general, when using an INCREMENT with a fractional part, where
(LAST - FIRST) / INCREMENT is (mathematically) a whole number, specify
a slightly larger (or smaller, if INCREMENT is negative) value for LAST
to ensure that LAST is the final value printed by seq.
Allowing fractional values is probably one of those features that
should never have been implemented at all. People do not intuitively
understand floating point numbers. But floating point numbers are
there and so will continue to surprise people.
Bob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
