[Bug 1799868] Re: seq command has problems near its max integer

2018-11-01 Thread C de-Avillez
Closing INVALID, then, given this is a known, documented limitation.

** Changed in: coreutils (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799868

Title:
  seq command has problems near its max integer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1799868/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1799868] Re: seq command has problems near its max integer

2018-11-01 Thread Kevin O'Gorman
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  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 5000 2 5004
>  5000
>  5000
>  5004
>
>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.001 1.009
>
>outputs 1.007 twice and skips 1.008."
>
> 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
>   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)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1799868/+subscriptions
>


-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.


** Attachment added: "unnamed"
   https://bugs.launchpad.net/bugs/1799868/+attachment/5207860/+files/unnamed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799868

Title:
  seq command has problems near its max integer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1799868/+subscri

[Bug 1799868] Re: seq command has problems near its max integer

2018-10-29 Thread C de-Avillez
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 5000 2 5004
 5000
 5000
 5004

   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.001 1.009

   outputs 1.007 twice and skips 1.008."

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 a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799868

Title:
  seq command has problems near its max integer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1799868/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1799868] Re: seq command has problems near its max integer

2018-10-24 Thread Kevin O'Gorman
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:~$

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799868

Title:
  seq command has problems near its max integer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1799868/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs