Bug 463556 - Weird output of seq command for some sequences of floats
Weird output of seq command for some sequences of floats
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-23 17:09 EDT by Need Real Name
Modified: 2008-10-15 22:00 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-15 22:00:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2008-09-23 17:09:19 EDT
Program doesn't work as it should:

$ seq -0.01 0.1 1
-0,01
0,09
0,19
0,29
0,39
0,49
0,59
0,69
0,79
0,89
0,99

man page:
 seq [OPTION]... FIRST INCREMENT LAST
Comment 1 Kamil Dudka 2008-09-23 17:45:56 EDT
What is the expected output? I can't see the bug...
Comment 2 Need Real Name 2008-09-23 17:50:28 EDT
> man page:
> seq [OPTION]... FIRST INCREMENT LAST

The last number should be LAST.
Comment 3 Ondrej Vasik 2008-09-24 04:30:29 EDT
Ok, last number should be LAST, but increment should be INCREMENT... therefore you are in deadlock and there is no way out. Info pages are usually more complex than man pages in the case of coreutils and they are recommended in coreutils man pages. So please consider to use them... They say "`seq' prints the numbers from FIRST to LAST by INCREMENT." That's exactly what is the output. I really can't see a bug. It simply did what you requested - sequence from -0.01 to 1 with increment 0.1 - next number would be bigger than 1 so seq stopped. NOTABUG for me, please provide any relevant informations why should seq work like you want.
Comment 4 Need Real Name 2008-09-24 13:28:51 EDT
Then why this:

$ seq -0.1 0.1 1
-0,1
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0

$ seq -0.1 0.1 2
-0,1
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0
1,1
1,2
1,3
1,4
1,5
1,6
1,7
1,8
1,9
Comment 5 Ondrej Vasik 2008-09-24 16:09:54 EDT
Thanks, that one report makes sense, but is about different thing. It seems to be about handling floats on some architectures/systems ... I guess that issue was already fixed by upstream (in middle april this year, http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=4827dd27b0c655a685947aaa01426a5ecba179f3) and should be fixed in Fedora Rawhide, but unfortunately I can't check it at the moment. Will check it tomorrow (10PM here now) and possibly make an update for F-9.
Comment 6 Ondrej Vasik 2008-09-25 05:52:15 EDT
I'm able to reproduce the issue on i386 architecture even with the latest upstream seq. Solution is quite easy - to simply add/substract DBL_EPSILON when deciding if  the number is out of range. Solution proposed to upstream, we will see if it is harmless...
Comment 7 Jim Meyering 2008-09-25 09:17:53 EDT
Thanks to Ondrej for discovering that it's locale-dependent:

   $ LC_ALL=C seq -0.1 0.1 2|grep 2.0 || echo bug
   2.0
   $ LC_ALL=cs_CZ.UTF-8 seq -0.1 0.1 2|grep 2.0 || echo bug
   bug

Here's the fix I expect to use:

diff --git a/src/seq.c b/src/seq.c
index 55518df..b5f0651 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -309 +309 @@ print_numbers (char const *fmt, struct layout layout,
-             if (xstrtold (x_str + layout.prefix_len, NULL, &x_val, c_strtold)
+             if (xstrtold (x_str + layout.prefix_len, NULL, &x_val, strtold)
Comment 8 Jim Meyering 2008-09-26 17:54:16 EDT
Patch and test case pushed and posted upstream:

http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14613
Comment 9 Need Real Name 2008-09-27 08:06:29 EDT
Thanks :)
Comment 10 Fedora Update System 2008-10-10 03:54:43 EDT
coreutils-6.10-31.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/coreutils-6.10-31.fc9
Comment 11 Fedora Update System 2008-10-15 22:00:56 EDT
coreutils-6.10-33.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.