From: Shiping Zhang on
Is this a bug in perl?

$v = sprintf "%.1f", 2.25;
print $v, "\n";

The above code produced 2.2

$v = sprintf "%.1f", 2.35;
print $v, "\n";

The above code produced 2.4

I tested several versions, they all behaved the same.
From: J�rgen Exner on
Shiping Zhang <spz1st(a)gmail.com> wrote:
>Is this a bug in perl?
>
>$v = sprintf "%.1f", 2.25;
>print $v, "\n";
>
>The above code produced 2.2

I cannot reproduce this observation. For me it prints 2.3.
( v5.10.0 built for MSWin32-x86-multi-thread)

>$v = sprintf "%.1f", 2.35;
>print $v, "\n";
>
>The above code produced 2.4
>
>I tested several versions, they all behaved the same.

However more than likely you don't even need the sprintf() assignment
with separate print(), a simple
printf "%.1f", 2.35;
will most likely behave exactly the same.

If so then try
printf "%.40f", 2.25;
and
printf "%.40f", 2.35;
on your Perl installation. This will most likely demonstrate the reason
for your observation. For an explanation please
- see "perldoc -q 999"
- re-read your notes from "Introduction into Computer Numerics"
- check the NG archives for dozens and dozens of similar posts and the
replies to them

jue
From: Shiping Zhang on
On 9ÔÂ22ÈÕ, ÏÂÎç1ʱ08·Ö, Shiping Zhang <spz...(a)gmail.com> wrote:
> Is this a bug in perl?
>
> $v = sprintf "%.1f", 2.25;
> print $v, "\n";
>
> The above code produced 2.2
>
> $v = sprintf "%.1f", 2.35;
> print $v, "\n";
>
> The above code produced 2.4
>
> I tested several versions, they all behaved the same.

Okay, it's not a bug. This is due to limitation of machine (binary)
representation of floating point numbers. A test C program behaved
the same.
From: sln on
On Tue, 22 Sep 2009 12:52:36 -0700 (PDT), Shiping Zhang <spz1st(a)gmail.com> wrote:

>On 9��22��, ����1ʱ08��, Shiping Zhang <spz...(a)gmail.com> wrote:
>> Is this a bug in perl?
>>
>> $v = sprintf "%.1f", 2.25;
>> print $v, "\n";
>>
>> The above code produced 2.2
>>
>> $v = sprintf "%.1f", 2.35;
>> print $v, "\n";
>>
>> The above code produced 2.4
>>
>> I tested several versions, they all behaved the same.
>
>Okay, it's not a bug. This is due to limitation of machine (binary)
>representation of floating point numbers. A test C program behaved
>the same.

Right, a binary thing! But more than that, different results across
different floating point hardware, firmware, libs.

You would think all things being equal, the same error pattern should
be had on all machines.

The good news is that internal fp operations wash out those discrepenccies
well past the number of digits of which the real universe can actually
be measured by physical means. Ie, its not right/wrong unless you can
prove it is/isn't. There are probably wider (bit-wise) floating point
registers available for calculations on scientific principles that can't
be proven.

c:\>perl -e "for(2.15,2.25,2.35,2.45,2.55,2.65) {$v = sprintf \"%.1f\", $_;
print \"$v\n\"}"
2.1
2.3
2.4
2.5
2.5
2.6

-sln
From: John Stanley on

On Tue, 22 Sep 2009, Shiping Zhang wrote:

> On 9月22日, 下午1时08分, Shiping Zhang <spz...(a)gmail.com> wrote:
>> Is this a bug in perl?
>>
>> $v = sprintf "%.1f", 2.25;
>> print $v, "\n";
>>
>> The above code produced 2.2
>>...

> Okay, it's not a bug. This is due to limitation of machine (binary)
> representation of floating point numbers. A test C program behaved
> the same.

I don't think I missed class that day, but what binary representation of
floating point CANNOT represent the base ten number "2.25"? That's 10.01
base two.



 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Newbie: Regular expresion
Next: CGI and UTF-8