I don't know how many people here remember the thread on weird math
but here's the question that I posed awhile back...
I've got a script that takes numbers similar to those below and then
rounds
them and adds them together using code similar to what is below.
#!/usr/bin/perl -w
use
# An example that tells it all:
# 1 + 1/20 = 1.05= 1.00 0011 : bit52 = 0, bit53 = 1
# 1 + 1/40 = 1.025 = 1.000 0011: bit52 = 0, bit53 = 0
# 1 + 1/80 = 1.0125 = 1. 0011 : bit52 = 1, bit53 = 0
# 1 + 1/160 = 1.00625 = 1.0 0011 : bit52 = 1, bit53 = 1
# where
#
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2003 2:56 PM
To: Bill Stephenson
Cc: mac osx list
Subject: Re: Weird math...
On Mon, 13 Oct 2003, Bill Stephenson wrote:
I've got a script that takes numbers similar to those below and then
rounds
them and adds them together using code similar
in.
Dan
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2003 2:56 PM
To: Bill Stephenson
Cc: mac osx list
Subject: Re: Weird math...
On Mon, 13 Oct 2003, Bill Stephenson wrote:
I've got a script that takes numbers similar
Fixed-point math (generally with 4
decimal places and an implied decimal point on a 32 or 64 bit integer) is
more appropriate in those cases.
Math::BigFloat, perhaps?
I've got a script that takes numbers similar to those below and then rounds
them and adds them together using code similar to what is below.
#!/usr/bin/perl -w
use strict;
my $item_1 = 1.655;
my $item_2 = 1.755;
my $rnd_1 = (sprintf qq~%.2f~, $item_1);
my $rnd_2 =
On Mon, 13 Oct 2003, Bill Stephenson wrote:
I've got a script that takes numbers similar to those below and then rounds
them and adds them together using code similar to what is below.
[snip]
The code above prints this result (system 10.1.5, perl 5.6.0):
1.66, 1.75
But shouldn't it be:
on 10/13/03 1:56 PM, Dan Sugalski at [EMAIL PROTECTED] wrote:
Welcome to the wonderful world of inexact representations.
snip
Thank you!! I'll read up on this today, and hopefully the workarounds will
suffice for my customers.
--
Bill Stephenson
www.PerlHelp.com
1-417-546-5593
At 03:24 PM 10/13/2003, Bill Stephenson wrote:
on 10/13/03 1:56 PM, Dan Sugalski at [EMAIL PROTECTED] wrote:
Welcome to the wonderful world of inexact representations.
snip
Thank you!! I'll read up on this today, and hopefully the workarounds will
suffice for my customers.
Have you seen this
Here is a little Perl routine that shows exactly what is going on.
#!/usr/bin/perl -w
$bigtwo = 2**32;
while ($a = DATA) {
$b = (sprintf %.0f, $a * $bigtwo)/$bigtwo;
$up_or_down = $b = $a ? round up : round down;
print $a $up_or_down\n;
}
__END__
1.655
on 10/13/03 3:07 PM, John Delacour at [EMAIL PROTECTED] wrote:
Don't ask me why but this does solve your problem (which happens also
in 5.8.0):
@ls = qw(1.655 1.755) ;
for (@ls) {
$_ += 0.01;
printf %.2f$/ , $_;
}
JD
Thanks JD! That seems to work pretty good. I still
You are wrong about the 64 bit part, Edward, no matter what the Perl books say.
The precision, eps, of a machine is the smallest positive number such that
1 + eps 1 in machine arithmetic. For example, if
1.01 1 but 1.001 = 1 (binary),
then the precision of the machine is
On Mon, 13 Oct 2003, Vic Norton wrote:
You are wrong about the 64 bit part, Edward, no matter what the Perl
books say.
Never tell an Apple employee they are wrong, especially on a statement of
machine or software capability. Unless you are sure. And even then,
double check two or three
13 matches
Mail list logo