seq command has problems near its max integer

[Kevin O'Gorman]

I can use seq(1) to generate sequences of large numbers if I use the default increment:

$ seq 170141183460469231731687303715884105721 170141183460469231731687303715884105725
170141183460469231731687303715884105721
170141183460469231731687303715884105722
170141183460469231731687303715884105723
170141183460469231731687303715884105724
170141183460469231731687303715884105725
$

However, if I use an increment of 2 (which should stop 2 short of the max int,) it starts with the max integer+1 (2^127) and outputs it forever:
$ seq 170141183460469231731687303715884105721 2 170141183460469231731687303715884105725 | less
170141183460469231731687303715884105728
170141183460469231731687303715884105728
170141183460469231731687303715884105728
170141183460469231731687303715884105728
.
.
.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: coreutils 8.28-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 24 20:17:15 2018
SourcePackage: coreutils
UpgradeStatus: Upgraded to bionic on 2018-08-19 (66 days ago)

[Kevin O'Gorman (kogorman-pacbell)]

It's worse than I thought. Increments of 2 fail even when aa factor of 100 away from the limit:

kevin@plato-x:~$ seq 170141183460469231731687303715884105721 1 170141183460469231731687303715884105725 | head -10
170141183460469231731687303715884105721
170141183460469231731687303715884105722
170141183460469231731687303715884105723
170141183460469231731687303715884105724
170141183460469231731687303715884105725
kevin@plato-x:~$ seq 1701411834604692317316873037158841051 2 1701411834604692317316873037158841055 | head -10
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
1701411834604692317282285392020635648
kevin@plato-x:~$

[C de-Avillez (hggdh2)]

Hello Kevin, and thank you for opening this bug and helping make Ubuntu better.

The info page for seq (info seq) has the following note:

" On most systems, seq can produce whole-number output for values up to
at least 2^{53}. Larger integers are approximated. The details differ
depending on your floating-point implementation. *Note Floating
point::. A common case is that ‘seq’ works with integers through
2^{64}, and larger integers may not be numerically correct:

     $ seq 50000000000000000000 2 50000000000000000004
     50000000000000000000
     50000000000000000000
     50000000000000000004

   However, note that when limited to non-negative whole numbers, an
increment of 1 and no format-specifying option, seq can print
arbitrarily large numbers.

   Be careful when using ‘seq’ with outlandish values: otherwise you may
see surprising results, as ‘seq’ uses floating point internally. For
example, on the x86 platform, where the internal representation uses a
64-bit fraction, the command:

     seq 1 0.0000000000000000001 1.0000000000000000009

   outputs 1.0000000000000000007 twice and skips 1.0000000000000000008."

Now, 2^64 is 18446744073709551616, which is *much* smaller than the values you are using. So... you are in the boundary of the map, where it is written "here be dragons."

I ran 'seq' with your initial value, and increment of 1, and varying end-values, all larger than the initial value. All seemed to work correctly. But the moment I changed the increment... things went south very fast (including what seemed as an infinite loop, with 'seq' outputting the same value over and over).

I am in a mind of closing this bug INVALID, but wanted to have your input before that.

Thank you.

[Kevin O'Gorman (kogorman-pacbell)]

I dont usually read info pages since I have trouble navigating them. But
reading what you quoted made clear what happened.

I would personally have preferred it if seq would notice when the increment
is not doing anything, and instead of producing infinite output, complained
and quit as it does when the starting value is too large. The fact that it
does that in one case is part of why I thought it was a bug to not do it in
another.

But to be honest, I'd have implemented unlimited integers rather than using
floating point, perhaps by making it use Python under the covers, since
that's how Python normally works. Well maybe I wouldn't do it that way in
coreutils.... But I'd do it. It's not that hard if you're not doing
multiply or divide.

On Mon, Oct 29, 2018 at 4:00 PM C de-Avillez <email address hidden> wrote:

> Hello Kevin, and thank you for opening this bug and helping make Ubuntu
> better.
>
> The info page for seq (info seq) has the following note:
>
> " On most systems, seq can produce whole-number output for values up to
> at least 2^{53}. Larger integers are approximated. The details differ
> depending on your floating-point implementation. *Note Floating
> point::. A common case is that ‘seq’ works with integers through
> 2^{64}, and larger integers may not be numerically correct:
>
> $ seq 50000000000000000000 2 50000000000000000004
> 50000000000000000000
> 50000000000000000000
> 50000000000000000004
>
> However, note that when limited to non-negative whole numbers, an
> increment of 1 and no format-specifying option, seq can print
> arbitrarily large numbers.
>
> Be careful when using ‘seq’ with outlandish values: otherwise you may
> see surprising results, as ‘seq’ uses floating point internally. For
> example, on the x86 platform, where the internal representation uses a
> 64-bit fraction, the command:
>
> seq 1 0.0000000000000000001 1.0000000000000000009
>
> outputs 1.0000000000000000007 twice and skips 1.0000000000000000008."
>
> Now, 2^64 is 18446744073709551616, which is *much* smaller than the
> values you are using. So... you are in the boundary of the map, where it
> is written "here be dragons."
>
> I ran 'seq' with your initial value, and increment of 1, and varying
> end-values, all larger than the initial value. All seemed to work
> correctly. But the moment I changed the increment... things went south
> very fast (including what seemed as an infinite loop, with 'seq'
> outputting the same value over and over).
>
> I am in a mind of closing this bug INVALID, but wanted to have your
> input before that.
>
> Thank you.
>
> ** Changed in: coreutils (Ubuntu)
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1799868
>
> Title:
> seq command has problems near its max integer
>
> Status in coreutils package in Ubuntu:
> Incomplete
>
> Bug description:
> I can use seq(1) to generate sequences of large numbers if I use the
> default increment:
>
> $ seq 170141183460469231731687303715884105721
> 170141183460469231731687303715884105725
> 170141183460469231731687303715...

[C de-Avillez (hggdh2)]

Closing INVALID, then, given this is a known, documented limitation.