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
