I checked 50 iterations (as hinted at by the text) and 100 iterations (as shown with the code). You claimed my code showed ugly values, and yet your current demonstration actually shows the opposite. Had I chosen between 80 and 99 iterations, I might have seen ugly values (if our Perl versions are similar enough). I didn't try any of those. It was just a quick example. But now we see that your claim was actually false. But why don't we discuss something of more import instead of picking nits about some trivial example?

The sweet spot for this feature (which you view as a bug) is a relatively small number of values each with a relatively small number of digits after each decimal point. So 80 is pushing "a small number of values" a bit. I'd actually prefer one more digit of blur so even a few hundred such numbers would likely be handled. I don't mind at all if a few thousand values is too much to be handled by this feature.

I find that summing a few dozen numbers, each with only a few digits after the decimal is a pretty darn common scenario when doing rather informal calculations with Perl. And I have personally benefited quite a few times from not having to bother to force a particular format upon the output in such scenarios.

I recall it even being a pain to get as nice of output when using a specific printf format. A quick test just now shows that '%.6g' seems to produce as nice of output as the default these days. I don't know if that is a change since long ago, or if I just failed to find that solution, or if my current quick check is overlooking cases that had caused me problems previously.

But I still find it more appropriate to put the onus on those wanting 17 full digits of precision in their output (who I find to be much more likely to be knowledgeable about such things) than to force casual Perl users to jump through such hoops.