bug#23110: seq apparent bug

[Ruediger Meier]

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