The output of that code is *still* not nice, even today. Try it and you'll see.

I ran that code in multiple versions of Perl that I had handy. The output was the intuitive ("nice") version, even when I ran the code with twice as many iterations.

Note that your stance would produce 16 digits of noise for even trivial cases like print 0.1+0.2.

Yes, there is no one obvious best value for how many digits to show by default. C says 6, for example. So, you give a "slippery slope" argument, dodge one argument by concentrating on tangential aspects of the phrasing, and make a false assumption about whether I ran the code. Not much to refute here.

The output was the intuitive ("nice") version

Did you look at the intermediate values ? (That's what your original complainants were doing.)

C:\_32\pscrpt>perl -le "print $];"
5.024000

C:\_32\pscrpt>perl -V:archname
archname='MSWin32-x86-multi-thread-64int';

C:\_32\pscrpt>perl -V:nvtype
nvtype='double';

C:\_32\pscrpt>type try.pl
use warnings;
use strict;

my $x = 0;
for( 1..100 ) {
    $x += 0.01;
    print "$x\n" if length $x > 4;
}

C:\_32\pscrpt>perl try.pl
0.810000000000001
0.820000000000001
0.830000000000001
0.840000000000001
0.850000000000001
0.860000000000001
0.870000000000001
0.880000000000001
0.890000000000001
0.900000000000001
0.910000000000001
0.920000000000001
0.930000000000001
0.940000000000001
0.950000000000001
0.960000000000001
0.970000000000001
0.980000000000001
0.990000000000001

C:\_32\pscrpt>
[download]

Those are actually correct values (rounded to 15 decimal digits of precision) for a perl whose nvtype is an 8-byte double.

And it's also to be expected (given perl's current practice) that the next (and last) value to be calculated is printed as "1" - because 1.0000000000000007 rounded to 15 decimal digits of precision is exactly that.

Cheers,
Rob

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.

- tye