Prev: Newbie: Regular expresion
Next: CGI and UTF-8
From: Shiping Zhang on 22 Sep 2009 13:08 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 22 Sep 2009 13:34 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 22 Sep 2009 15:52 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 22 Sep 2009 17:16 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 22 Sep 2009 17:42
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. |