On Mon, 16 Aug 2021 15:24:29 -0700 Anthony Martin wrote: > But really, if you're playing games at the boundaries > of floating point precision, you're bound to lose. I > suggest we either a) do nothing and leave the loop > exactly as it is described in the manual but add a note > in the BUGS section, or b) go back to the v8 method > that calculates the number of steps in the loop before > executing it. Even with the latter method you can see > odd results due to precision limitations but at least > there will be no infinite loops. > > I vote for "a". I vote for 'b', at the toss of a coin. I've spent some time bikeshedding this sickly program, and attached is the sickly result. It does neat things like `seq -w 003` printing out 001, 002, 003. It probably shouldn't do that, though. It also doesn't use exponential notation to print out numbers. This allows seq to not be limited from -999999 to 999999. Even still, the result doesn't feel quite right. Implementing a floating point number parser in seq is weird. Invalid number combinations cause it to crash. The following does not print out 0.3 in either implementation: seq 0.1 0.1 0.3 The only way to correctly print out decimals is by nesting seq: for(i in `{seq 0 9}) for(j in `{seq -w 0 9}) echo $i.$j Therefore, I propose replacing floating point with integers. If we're lucky, seq can count decimals using integers. We can also implement hexadecimal counting. Thanks, Amavect