sprintf rounding with FreeBSD and perl 5.8.x

[cherbst]

I'm getting a weird result with some rounding in a sprintf with perl
5.8.8:

c = 2.47 / 100; # => 0.0247
sprintf("%.1f", 18500 * c); # => 457.0 (NOT on FreeBSD)
sprintf("%.1f", 18500 * 0.0247); # => 456.9

FreeBSD gives 456.9 for both sprintfs, I was able to reproduce it on a
fresh FreeBSD 6.3 install with the perl binary package, and from a
compiled binary.

On Linux perl 5.8.8 gives 457.0, and I get that answer on everything
else I tried (ruby and python on Linux and FreeBSD). I tried using
each of the methods Math::Round, but that is different from sprintf on
Linux, and that is the behavior I was trying to get. Is anybody aware
of something like an unusual CFLAG that might be getting passed when
perl is compiled on FreeBSD?

 

[J. Gleixner]

I'm getting a weird result with some rounding in a sprintf with perl
5.8.8:

c = 2.47 / 100; # => 0.0247
sprintf("%.1f", 18500 * c); # => 457.0 (NOT on FreeBSD)
sprintf("%.1f", 18500 * 0.0247); # => 456.9

That's not valid perl, so I have no idea how you're getting a result.

 

[cherbst]

That's not valid perl, so I have no idea how you're getting a result.

I had omitted the sigils, runs OK otherwise:

---

#!/usr/bin/perl -w

use strict;

my $c = 2.47 / 100; # => 0.0247
printf("%.1f\n", 18500 * $c); # => 457.0 (NOT on FreeBSD)
printf("%.1f\n", 18500 * 0.0247); # => 456.9

---

 

[RedGrittyBrick]

I'm getting a weird result with some rounding in a sprintf with perl
5.8.8:

c = 2.47 / 100; # => 0.0247

Odd comment! What do you mean "0.0247"?

$c = 2.47 / 100;
does not produce the result 0.0247, since 2.47 and .0247 aren't
representable in finite binary digits:

$ perl -e 'printf("%.20f\n%.20f\n", 2.47, 0.0247);'
2.47000000000000019540
0.02469999999999999973

hence ...

$ perl -e 'printf("%.20f\n%.20f\n", 2.47 / 100, 0.0247);'
0.02470000000000000320
0.02469999999999999973

sprintf("%.1f", 18500 * c); # => 457.0 (NOT on FreeBSD)
sprintf("%.1f", 18500 * 0.0247); # => 456.9

$ perl -e 'printf("%.20f\n%.20f\n", 18500*(2.47/100), 18500*0.0247);'
456.95000000000004547474
456.94999999999998863132

$ perl -e 'printf("%.1f\n%.1f\n", 18500*(2.47/100), 18500*0.0247);'
457.0
456.9

FreeBSD gives 456.9 for both sprintfs, I was able to reproduce it on a
fresh FreeBSD 6.3 install with the perl binary package, and from a
compiled binary.

Maybe printing the intermediate results to more digits (as above) would
shed some light?

On Linux perl 5.8.8 gives 457.0, and I get that answer on everything
else I tried (ruby and python on Linux and FreeBSD). I tried using
each of the methods Math::Round, but that is different from sprintf on
Linux, and that is the behavior I was trying to get. Is anybody aware
of something like an unusual CFLAG that might be getting passed when
perl is compiled on FreeBSD?

Not I, but I'd guess there is something interesting to see in
perl -V
on your BSD and Linux systems.

 

[cherbst]

Odd comment! What do you mean "0.0247"?

$c = 2.47 / 100;
does not produce the result 0.0247, since 2.47 and .0247 aren't
representable in finite binary digits:

Yes, I took a crash course in floating point problems over the last
few days. All I'm really trying to get at is why perl on FreeBSD is
different from everything else (ruby and python on Linux and FreeBSD).

Not I, but I'd guess there is something interesting to see in
perl -V
on your BSD and Linux systems.

They *are* different, I hadn't used -V before:

Linux:
Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP THREADS_HAVE_PIDS
USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
FreeBSD:
Compile-time options: MYMALLOC PERL_MALLOC_WRAP USE_64_BIT_INT
USE_LARGE_FILES USE_PERLIO

USE_64_BIT_INT looks interesting, still trying to hunt down where it's
set (not Makefile, not config.sh...)

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to

USE_64_BIT_INT looks interesting, still trying to hunt down where it's
set (not Makefile, not config.sh...)

Assuming IEEE complience (should be taken as given), only NVsize
should matter. See the beginning of the thread on milliseconds for
details.

Hope this helps,
Ilya