GNU bug report logs - #23110
seq apparent bug

Previous Next

Full log

View this message in rfc822 format

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23110 <at> debbugs.gnu.org
Subject: 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

Previous Next

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