GNU bug report logs - #23110
seq apparent bug

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23110 in the body.
You can then email your comments to 23110 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Маренков Евгений <hotpil <at> mail.ru>
To: bug-coreutils <at> gnu.org
Subject: seq apparent bug
Date: Thu, 24 Mar 2016 18:28:32 +0300

[Message part 1 (text/plain, inline)]

 Dear all,

I have recently noticed an apparent bug in 'seq'. If one runs
seq -w 2 1 10
everything works fine.
But 
seq -w 2 0 10
falls into endless loop ...

Best regards
Evgeny

[Message part 2 (text/html, inline)]

Message #8 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Маренков Евгений
 <hotpil <at> mail.ru>, 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 24 Mar 2016 18:44:04 +0100

On 03/24/2016 04:28 PM, Маренков Евгений wrote:
> I have recently noticed an apparent bug in 'seq'. If one runs
> seq -w 2 1 10
> everything works fine.
> But 
> seq -w 2 0 10
> falls into endless loop ...

Thanks for the report.
However, I don't think this is a bug but more a misunderstanding
on your side how seq works.  It's clearly documented that the
second number (if 3 are given) is the increment.  As you passed
0 as value, the target 10 is never reached, and therefore seq
continues to produce output.  Thus, it exactly does what you
told it to do.  What else would you expect?

Have a nice day,
Berny

Message #11 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Leslie S Satenstein <lsatenstein <at> yahoo.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>, 
 Маренков Евгений <hotpil <at> mail.ru>, 
 "23110 <at> debbugs.gnu.org" <23110 <at> debbugs.gnu.org>
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 24 Mar 2016 19:11:39 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Should not an increment of zero be flagged as an error, and not ignored?
 Regards 
 Leslie
 Mr. Leslie Satenstein
Montréal Québec, Canada



      From: Bernhard Voelker <mail <at> bernhard-voelker.de>
 To: Маренков Евгений <hotpil <at> mail.ru>; 23110 <at> debbugs.gnu.org 
 Sent: Thursday, March 24, 2016 1:44 PM
 Subject: bug#23110: seq apparent bug
   
On 03/24/2016 04:28 PM, Маренков Евгений wrote:
> I have recently noticed an apparent bug in 'seq'. If one runs
> seq -w 2 1 10
> everything works fine.
> But 
> seq -w 2 0 10
> falls into endless loop ...

Thanks for the report.
However, I don't think this is a bug but more a misunderstanding
on your side how seq works.  It's clearly documented that the
second number (if 3 are given) is the increment.  As you passed
0 as value, the target 10 is never reached, and therefore seq
continues to produce output.  Thus, it exactly does what you
told it to do.  What else would you expect?

Have a nice day,
Berny





  

[Message part 2 (text/html, inline)]

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: bug-coreutils <at> gnu.org
Cc: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Маренков Евгений <hotpil <at> mail.ru>,
 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Wed, 6 Apr 2016 19:19:27 +0100

On Thursday 24 March 2016, Bernhard Voelker wrote:
> On 03/24/2016 04:28 PM, Маренков Евгений wrote:
> > I have recently noticed an apparent bug in 'seq'. If one runs
> > seq -w 2 1 10
> > everything works fine.
> > But
> > seq -w 2 0 10
> > falls into endless loop ...
>
> Thanks for the report.
> However, I don't think this is a bug but more a misunderstanding
> on your side how seq works.  It's clearly documented that the
> second number (if 3 are given) is the increment.  As you passed
> 0 as value, the target 10 is never reached, and therefore seq
> continues to produce output.  Thus, it exactly does what you
> told it to do.  What else would you expect?

This sounds all true, however then these one should also run forever:
$ seq 10 0 2

Man page says:
    INCREMENT is usually positive if FIRST is smaller than LAST,
    and INCREMENT is usually negative if FIRST is greater than LAST.

This implicates IMO that seq should try to count _down_ if FIRST > LAST 
and INCREMENT=0

Moreover I'd say this one does not need to loop endless:
$ seq 0 0 0


BTW maybe it would be an improvement to handle epsilon related endless 
loops like this
$ seq 1 0.00000000000000000000000000000001 2


cu,
Rudi

Message #20 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org
Cc: hotpil <at> mail.ru
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 7 Apr 2016 11:02:03 +0200

tags 23110 notabug
close 23110
thanks

On 04/06/2016 08:19 PM, Ruediger Meier wrote:
> This sounds all true, however then these one should also run forever:
> $ seq 10 0 2
> 
> Man page says:
>     INCREMENT is usually positive if FIRST is smaller than LAST,
>     and INCREMENT is usually negative if FIRST is greater than LAST.
>  
> This implicates IMO that seq should try to count _down_ if FIRST > LAST 
> and INCREMENT=0

Admittedly, the above documentation aims at useful constellations where
seq really operates as a sequence generator - maybe the wording around
"... usually ..." could be improved here.

In this case, it's not a matter of how increment is treated, but more
when seq ends - which is documented quite clearly both in the --help
output (and therefore in the generated man page), and in the Texinfo
manual:

  http://www.gnu.org/software/coreutils/seq

  The sequence of numbers ends when the sum of the current number
  and increment would become greater than last, [...]

> Moreover I'd say this one does not need to loop endless:
> $ seq 0 0 0

Why? The sum of 0+0 will never become _greater_ than 0.
Likewise for the OPs case ("seq -w 2 0 10"): the sum will never become
greater than 10.

Thus saying, I think this issue is more a confusion regarding the
expectations from the tool.  I don't see why an increment of 0 should
be treated special here.

Therefore, I'm marking this issue as "not a bug", and closing it.
As always, further discussion may continue here, and we can re-open
this issue if needed ... especially if someone proposes a better
wording for the above documentation snippet. ;-)

Have a nice day,
Berny

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 7 Apr 2016 10:46:10 +0100

On Thursday 07 April 2016, Bernhard Voelker wrote:
> tags 23110 notabug
> close 23110
> thanks
>
> On 04/06/2016 08:19 PM, Ruediger Meier wrote:
> > This sounds all true, however then these one should also run
> > forever: $ seq 10 0 2
> >
> > Man page says:
> >     INCREMENT is usually positive if FIRST is smaller than LAST,
> >     and INCREMENT is usually negative if FIRST is greater than
> > LAST.
> >
> > This implicates IMO that seq should try to count _down_ if FIRST >
> > LAST and INCREMENT=0
>
> Admittedly, the above documentation aims at useful constellations
> where seq really operates as a sequence generator - maybe the wording
> around "... usually ..." could be improved here.
>
> In this case, it's not a matter of how increment is treated, but more
> when seq ends - which is documented quite clearly both in the --help
> output (and therefore in the generated man page), and in the Texinfo
> manual:
>
>   http://www.gnu.org/software/coreutils/seq
>
>   The sequence of numbers ends when the sum of the current number
>   and increment would become greater than last, [...]
>
> > Moreover I'd say this one does not need to loop endless:
> > $ seq 0 0 0
>
> Why? The sum of 0+0 will never become _greater_ than 0.
> Likewise for the OPs case ("seq -w 2 0 10"): the sum will never
> become greater than 10.
>
> Thus saying, I think this issue is more a confusion regarding the
> expectations from the tool.  I don't see why an increment of 0 should
> be treated special here.
>
> Therefore, I'm marking this issue as "not a bug", and closing it.
> As always, further discussion may continue here, and we can re-open
> this issue if needed ... especially if someone proposes a better
> wording for the above documentation snippet. ;-)

I understand that this issue is not a bug. But it wouldn't be also not a 
bug if coreutils would behave like BSD:

$ seq 1 0 10 ; echo $?
seq: zero increment
1

This is much more useful and safe. Scripts which invoke an endless loop 
by using seq have almost certainly made something wrong. Endless loop 
and 100% CPU usage could be avoided.

People who _want_ endless trivial "sequences" are using yes(1).

cu,
Rudi

Message #26 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 7 Apr 2016 16:40:46 +0200

[Message part 1 (text/plain, inline)]

reopen 23110
thanks

On 04/07/2016 11:46 AM, Ruediger Meier wrote:
> I understand that this issue is not a bug. But it wouldn't be also not a 
> bug if coreutils would behave like BSD:
> 
> $ seq 1 0 10 ; echo $?
> seq: zero increment
> 1

Ah, okay: as there's prior art in the BSDs [0], the attached
proposes the same for GNU coreutils.

[0] http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-7/src/usr.bin/seq/seq.c

Have a nice day,
Berny

[0001-seq-do-not-allow-0-as-increment-value.patch (text/x-patch, attachment)]

Message #29 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 7 Apr 2016 19:18:16 +0100

On 07/04/16 15:40, Bernhard Voelker wrote:
> reopen 23110
> thanks
>
> On 04/07/2016 11:46 AM, Ruediger Meier wrote:
>> I understand that this issue is not a bug. But it wouldn't be also not a
>> bug if coreutils would behave like BSD:
>>
>> $ seq 1 0 10 ; echo $?
>> seq: zero increment
>> 1
>
> Ah, okay: as there's prior art in the BSDs [0], the attached
> proposes the same for GNU coreutils.
>
> [0] http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-7/src/usr.bin/seq/seq.c
>

I see FreeBSD has seq since 9.0.

I agree that we should avoid repeating output with "0" STEP.

Do we want to deal with these cases spinning the cpu?

  seq 1 nan 1
  seq 1 .0000000000000000000000000000001 1

As an aside, I see FreeBSD requires the STEP to be in the right direction
when FIRST != LAST, or it will also exit with error.
GNU will just output nothing in that case.

cheers,
Pádraig.

Message #32 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Fri, 8 Apr 2016 13:57:37 +0100

On 07/04/16 15:40, Bernhard Voelker wrote:
> reopen 23110
> thanks
>
> On 04/07/2016 11:46 AM, Ruediger Meier wrote:
>> I understand that this issue is not a bug. But it wouldn't be also not a
>> bug if coreutils would behave like BSD:
>>
>> $ seq 1 0 10 ; echo $?
>> seq: zero increment
>> 1
>
> Ah, okay: as there's prior art in the BSDs [0], the attached
> proposes the same for GNU coreutils.
>
> [0] http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-7/src/usr.bin/seq/seq.c

<Resend since I don't see this on the lists after a day>

I see FreeBSD has seq since 9.0.

I agree that we should avoid repeating output with "0" STEP.

The patch is fine as is and good to push.

Do we want to deal with these cases spinning the cpu,
in further patches?

   seq 1 nan 1
   seq 1 .0000000000000000000000000000001 1

As an aside, I see FreeBSD requires the STEP to be in the right direction
when FIRST != LAST, or it will also exit with error.
GNU will just output nothing in that case.

cheers,
Pádraig.

Message #35 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Fri, 8 Apr 2016 12:45:17 -0700

On 04/08/2016 05:57 AM, Pádraig Brady wrote:
> Do we want to deal with these cases spinning the cpu,
> in further patches?
>
>    seq 1 nan 1

NaN should be an error in any of the operands.

> seq 1 .0000000000000000000000000000001 1

For this I suggest the following heuristic. When inferring a format that 
would apply to two or more lines of output, try formatting the first two 
lines and report an error if they are the same. That would catch the 
seeming infinite loop (and at any rate, inadequate output) in this example.

>
> As an aside, I see FreeBSD requires the STEP to be in the right direction
> when FIRST != LAST, or it will also exit with error.
> GNU will just output nothing in that case. 

Outputting nothing sounds better. 'seq 1 0' is like 'for (i = 1; i <= 0; 
i++) ...'

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Fri, 8 Apr 2016 22:51:54 +0200

On Friday 08 April 2016, Paul Eggert wrote:
> On 04/08/2016 05:57 AM, Pádraig Brady wrote:
> > Do we want to deal with these cases spinning the cpu,
> > in further patches?
> >
> >    seq 1 nan 1
>
> NaN should be an error in any of the operands.
>
> > seq 1 .0000000000000000000000000000001 1
>
> For this I suggest the following heuristic. When inferring a format
> that would apply to two or more lines of output, try formatting the
> first two lines and report an error if they are the same.

Hm, I think printing identical lines is a valid use case:
$ seq -f "%0.1f" 0 0.02 0.1
0.0
0.0
0.0
0.1
0.1
0.1

> That would 
> catch the seeming infinite loop (and at any rate, inadequate output)
> in this example.

I would check it before the loop like this

if ((first + inc) == first)
	/* exit error */ 


Note this still wouldn't catch this one
 seq 0 .0000000000000000000000000000001 1

But this would run millions of years anyway even if the increment would  
work and moreover maybe the user _wants_ an effective endless (non 
trivial) sequence like this
 seq 0 1 999999999999999999999999999999


> > As an aside, I see FreeBSD requires the STEP to be in the right
> > direction when FIRST != LAST, or it will also exit with error.
> > GNU will just output nothing in that case.
>
> Outputting nothing sounds better. 'seq 1 0' is like 'for (i = 1; i <=
> 0; i++) ...'

I also guess that some people may have used this coreutils feature 
already in scripts:

# do nothing if inc = -1
for i in `seq 0 $inc 100`;do something; done

cu,
Rudi

Message #41 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Fri, 8 Apr 2016 15:21:17 -0700

On 04/08/2016 01:51 PM, Ruediger Meier wrote:
> On Friday 08 April 2016, Paul Eggert wrote:
>> For this I suggest the following heuristic. When inferring a format 
>> that would apply to two or more lines of output, try formatting the 
>> first two lines and report an error if they are the same. 
> Hm, I think printing identical lines is a valid use case:
> $ seq -f "%0.1f" 0 0.02 0.1
> 0.0
> 0.0
> 0.0
> 0.1
> 0.1
> 0.1

Sure, but the heuristic I suggested was for inferred formats only. It 
was not intended for formats explicitly specified via -f.

> I would check it before the loop like this
>
> if ((first + inc) == first)
> 	/* exit error */

I think I'd prefer testing what the user would see, instead of testing 
some internal variable.

> maybe the user _wants_ an effective endless (non
> trivial) sequence

If we make an increment of zero an error, then there's no way for the 
'seq' user to say they want an endless identical sequence. But there's 
always the 'yes' program for that.

Message #44 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Sat, 9 Apr 2016 08:18:22 +0200

On Saturday 09 April 2016, Paul Eggert wrote:
> On 04/08/2016 01:51 PM, Ruediger Meier wrote:
> > On Friday 08 April 2016, Paul Eggert wrote:
> >> For this I suggest the following heuristic. When inferring a
> >> format that would apply to two or more lines of output, try
> >> formatting the first two lines and report an error if they are the
> >> same.
> >
> > Hm, I think printing identical lines is a valid use case:
> > $ seq -f "%0.1f" 0 0.02 0.1
> > 0.0
> > 0.0
> > 0.0
> > 0.1
> > 0.1
> > 0.1
>
> Sure, but the heuristic I suggested was for inferred formats only. It
> was not intended for formats explicitly specified via -f.
>
> > I would check it before the loop like this
> >
> > if ((first + inc) == first)
> > 	/* exit error */
>
> I think I'd prefer testing what the user would see, instead of
> testing some internal variable.
>
> > maybe the user _wants_ an effective endless (non
> > trivial) sequence
>
> If we make an increment of zero an error, then there's no way for the
> 'seq' user to say they want an endless identical sequence. But
> there's always the 'yes' program for that.

I've ment effective (feels like) endless.

$ seq  0 1 1.0e+100

would run more than 10^93 seconds on my system (about 10^83 times the 
age of the universe). The increment sum-up would become imprecise and 
behave like zero much earlier.

cu,
Rudi

Message #47 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady
 <P <at> draigBrady.com>, 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Sat, 9 Apr 2016 10:49:10 +0200

On 04/08/2016 09:45 PM, Paul Eggert wrote:
> On 04/08/2016 05:57 AM, Pádraig Brady wrote:
>> Do we want to deal with these cases spinning the cpu,
>> in further patches?
>>
>>    seq 1 nan 1
> 
> NaN should be an error in any of the operands.

+1

>> seq 1 .0000000000000000000000000000001 1
> 
> For this I suggest the following heuristic. When inferring a format that 
> would apply to two or more lines of output, try formatting the first two 
> lines and report an error if they are the same. That would catch the 
> seeming infinite loop (and at any rate, inadequate output) in this example.

The only way to avoid this at all is to extend seq_fast() also for arbitrary
numbers, i.e., re-write the code to do the math all in the string format the
user wants.

Today, it's hard to explain why "seq 1 1 100000000" needs only 0.6s while
"seq 1 2 100000000" takes 24s although the increment is doubled.  Okay, one
could extend fast_seq() to work for all_digits_p(step).  As it only the
plus operation (or minus, well), wouldn't it be faster to manually calculate
all as strings, no matter if step is 1 or 0.00000000000000000000000000123?
Besides, the output could be buffered to save writes.

>> As an aside, I see FreeBSD requires the STEP to be in the right direction
>> when FIRST != LAST, or it will also exit with error.
>> GNU will just output nothing in that case. 
> 
> Outputting nothing sounds better. 'seq 1 0' is like 'for (i = 1; i <= 0; 
> i++) ...'

+1

Have a nice day,
Berny

Message #50 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 14 Apr 2016 18:37:51 +0200

[Message part 1 (text/plain, inline)]

On 04/07/2016 08:18 PM, Pádraig Brady wrote:
> I agree that we should avoid repeating output with "0" STEP.

Thanks.  I improved the error diagnostic by outputting the original
value from the user:

[PATCH 1/2] seq: do not allow 0 as increment value

> Do we want to deal with these cases spinning the cpu?
> 
>    seq 1 nan 1

This is addressed with the second patch:

[PATCH 2/2] seq: do not allow NaN arguments

>    seq 1 .0000000000000000000000000000001 1

I consider this a bug in seq: from mathematical point of view, the above
should just output "1" and then exit, because after adding that tiny number
the next number would be greater than LAST.

IMO we should enhance seq_fast() to do all the Math when no special
output format is given.
WDYT?

> As an aside, I see FreeBSD requires the STEP to be in the right direction
> when FIRST != LAST, or it will also exit with error.
> GNU will just output nothing in that case.

I think GNU seq's behavior is okay, and therefore I agree with Paul in
http://lists.gnu.org/archive/html/bug-coreutils/2016-04/msg00032.html

Have a nice day,
Berny

[0001-seq-do-not-allow-0-as-increment-value.patch (text/x-patch, attachment)]

[0002-seq-do-not-allow-NaN-arguments.patch (text/x-patch, attachment)]

Message #53 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 14 Apr 2016 17:47:39 +0100

The 2 patches look good.

On 14/04/16 17:37, Bernhard Voelker wrote:
>> >    seq 1 .0000000000000000000000000000001 1
> I consider this a bug in seq: from mathematical point of view, the above
> should just output "1" and then exit, because after adding that tiny number
> the next number would be greater than LAST.

right

> IMO we should enhance seq_fast() to do all the Math when no special
> output format is given.
> WDYT?

It would be good to expand seq_fast to more cases.

thanks!
Pádraig

Message #56 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Ruediger Meier <sweet_f_a <at> gmx.de>, 23110 <at> debbugs.gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#23110: seq apparent bug
Date: Thu, 14 Apr 2016 19:19:30 +0200

On 04/14/2016 06:47 PM, Pádraig Brady wrote:
> The 2 patches look good.

thanks for the review, pushed.

> On 14/04/16 17:37, Bernhard Voelker wrote:
>>>>    seq 1 .0000000000000000000000000000001 1
>> I consider this a bug in seq: from mathematical point of view, the above
>> should just output "1" and then exit, because after adding that tiny number
>> the next number would be greater than LAST.
> 
> right
> 
>> IMO we should enhance seq_fast() to do all the Math when no special
>> output format is given.
>> WDYT?
> 
> It would be good to expand seq_fast to more cases.

I'll try to come up with something (which may take some time).

Have a nice day,
Berny

Message #59 received at 23110 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 23110 <at> debbugs.gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Sat, 27 Oct 2018 16:06:06 -0600

tags 23110 fixed
close 23110
stop

(triaging old bugs)

On 2016-04-14 11:19 a.m., Bernhard Voelker wrote:
> On 04/14/2016 06:47 PM, Pádraig Brady wrote:
>> The 2 patches look good.
> 
> thanks for the review, pushed.
> 

closing as "fixed".

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.