Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20050207210519.2101.qmail@lists.php.net>
To: internals@lists.php.net
References: <20050207203954.52626.qmail@lists.php.net> <20050207204629.63824.qmail@lists.php.net>
Date: Mon, 7 Feb 2005 22:04:46 +0100
Lines: 37
Subject: Re: is the bankers' round() algorithm implemented well?
From: r.korving@xit.nl ("Ron Korving")

I just did a long test from 1 - 10000 and I noticed that every time the
number was increased with one bit (starting with 2048, then 4096, then 8192)
behaviour changes. You were right, my bad.

Makes me wonder though, what's the point of a bankers' algorithm if .005 can
never be reached, only approached? :) This unpredictable rounding behaviour
is a real b*tch, but what can you do :)

Ron

"Sara Golemon" <pollita@php.net> wrote in message
news:20050207204629.63824.qmail@lists.php.net...
> > I understood that round() is using the so called Bankers' round
algorithm.
> > But I notice it's inconsistent. The banker's algorithm is magically
> > activated only for numbers beyond 2047.0. Before 2047, the "classic"
> > 5-is-rounded-up method is used.
> >
>
> Floating point numbers are........ imprecise.
>
> What you see as 2047.005, the computer might see as
> 2047.0049999999999999123869128  or perhaps as
2047.005000000000000012396291
>
> When I only care about a certain accuracy (such as with monetary amounts)
I
> 'solve' this quirk of the CPU by adding a miniscule fudge factor:
>
> round($someval + 0.000000001, 2)
>
> PHP doesn't do this automatically because sometimes a plus-fudge is
> appropriate, sometimes a negative-fudge is better.
>
> -Sara