I guess you didn't understand any of the explanations you got to this.
#6220 is not a bug. Computers can not represent floating point values
accurately, only to a certain level of precision. Ergo there is no such
thing as precisely 0.1 and any function, such as floor(), which relies on
a number being precisely greater than some floating point number is never
going to work without a little help from the programmer. Bug #6220 is at
best a documentation issue. PHP could not possibly do anything to
accurately guess the intention of the programmer when it comes to this.
You, as a programmer, will have to add the appropriate fuzz factor when
using functions such as floor(), ceil() and round().
-Rasmus
On Fri, 7 Dec 2001, George Whiffen wrote:
> Pierre/Rasmus/Zeev,
>
> After a little more thought, it seems to me that, my problem, Bug 6220 and Matthew's
>original
> problem at the start of this thread are all REAL LIVE BUGS. As Pierre suggested,
>php seems to
> handle floating points fine 99% of the time with in its documented precision (14
>decimal digits or
> so depending on platform). This is perfectly suitable for nearly any kind of money,
>there's no
> problem there.
>
> The real problem is that floor, int, and the comparisons are going beyond this
>precision. Explicit
> string casts solve this by forcing the floats back to our guaranteed precision at
>which point
> everything works fine!
>
> I can only guess that internally php carries around as much float precision as it
>can to maintain
> accuracy on a series of calculations hence
>
> sprintf("%.50f",(0.7 + 0.1) * 10) is 7.9999999999999991118215802998747676610947
> and
> sprintf("%.50f",3.55 + 60.12) is 63.6699999999999945998752082232385873794556
>
> Comparison of these floats with 8 and 63.67 respectively fails at this level of
>precision but is
> fine at 14/15 digits.
>
> I can see why php would want to carry the extra precision around through
>calculations but not when
> the float is going in as the argument of an integer returning function/operator such
>as floor(),
> int(), == or ===. In these cases I take it as a straightforward bug to use more
>precision than we
> are supposed to be offering. If someone really wants 32 digit precision on
>comparisons, int, floor
> etc. it should be up to them to go off and explicitly ask for bccomp rather than
>leaving the likes
> of me to wonder how to explain that 8.2 minus 0.2 is not 8.
>
> Does that sound ok, or am I exhibiting even more ignorance...
>
> Unfortunately for me, the one thing I am fairly sure of, is that mysql is completely
>up the spout!!!
> SELECT IF(0.8 = 0.6 + 0.2,'good database','bad database');
> returns 'bad database' even if you replace the constants with explicit decimal
>fields.
>
> So many, many apologies and much grovelling for ever suggesting that msyql managed
>to get it right
> while you didn't! Can we re-open 6220 as a bug and attach int, == and === to any
>solution?
>
> Chastened,
>
> George
>
> Pierre-Alain Joye wrote:
> >
> > On Thu, 06 Dec 2001 18:03:23 +0000
> > George Whiffen <[EMAIL PROTECTED]> wrote:
> >
> > > Matthew,
> > >
> > > You are absolutely right, we have to do something about handling money better
>before anyone else
> > > notices that 0.7 plus 0.1 is not 0.8 with php! (I've already had an e-commerce
>user notice that
> > > their account balance is misquoted because 82 - 2 became 79 because of this).
> > >
> > > Looking through this thread it seems :
> > >
> > > 1. Floating points are not accurate, floating point arithmetic is not accurate
>enough for money
> > > calculations.
> > Wrong, It is fully useable for money. But not for mid-hi precision, use BCmath.
> >
> > > 2. Zeev is worried that a string based type would create performance problems.
> > Don't need to convert to string (huh php don't take really care about type).
> >
> > > 3. The standard approach when programming in low-level languages such as C or
>Java, is to convert to
> > > "pennies" and rely on integer arithmetic.
> > Sure, best way and solve the round problem, I never used more than 5 digits for
>the floating part of a number for money numbers (bank rates and stock calculation).
> >
> > > 4. bc calculations/comparisons are safe.
> > Sure :)
> >
> > > My questions are:
> > >
> > > 1. Is it useful to cut down the "money" problem to the bare esentials? e.g.
> > > - only handle addition/subtraction/multiplication
> >
> > > - never worry about more than 2 decimal places
> > five is sometimes a must 3 needed especially with euro convertion.
> >
> > > - maximum values could be practically limited to a billion or so
> > As explained in the documentation or type ranges.
> >
> > > 2. Could we use integer arithmetic for money, given the above restrictions? We
>only have to spot a
> > > "money" field and carry out integer arithmetic rather than floating point
>arithmetic. Of course we
> > > need to multiply the operands by 100 before the addition and divide by 100 at
>the end. Would that
> > > bring back the floating point problem in a new guise?
> > Sure it does. This tip were usefull in the past with old rdms systems and improbe
>indexes with actual system (as far you need indexes on amounts).
> >
> > > 3. How does mysql get away with it? I've never had a smidgeon of trouble with
>mysql adding
> > > decimals. In fact, my "safe" fall back for my bug will be to get mysql to do
>all the arithmetic
> > > rather than php.
> > Mysql does not any calculation except when you use function and/or operator.
> > Try this :
> > select 1.0120000000000001/1
> > and then
> > select 1.01200000000000001/1
> >
> > Damned 2nd one failed...
> >
> > > 4. How bad could performance get? How much non-integer, non-money, floating
>point calculation is
> > > really done in php code? Apart from some gd stuff, I can't think when I ever
>actually do a
> > > non-integer, non-money calculation!
> > If high precision floating numbers is your need use bcmath or develop your own php
>modules using a dedicated langage or libraries. Float numbers are not finites. See
>the last Zeev post for the link about explanations.
> >
> > > 5. If actual overall impact on php applications is not too bad, (even if we slow
>floating point by a
> > > factor of ten), could we just use bc routines for all floating point? Perhaps
>it could be a
> > > configuration option, with the default as precise calculation i.e. use bc, and
>an option for "fast"
> > > i.e. non-bc calculation?
> > You don't slow down your app. Integer process are generally faster (both in rdbms
>and cpu).
> > Except if you have a P4 and you use the Intel Compiler... ;))
> >
> > > Let me say again, if we want to be treated seriously as a credible HIGH LEVEL
>language, let alone a
> > > reliable e-commerce platform it is NOT ACCEPTABLE that (int) 10 * 0.7 + 0.1 is
>7. It doesn't matter
> > > how much documentation we create, it's just not on as default behaviour. So we
>have to do something!
> > Damned .........
> >
> > > The alternative is that sooner or later we'll be reading a press release from
>Seattle that runs
> > > something like this...
> > >
> > > PHP dangerous for e-commerce
> > > Reports are coming in of serious failings at e-commerce sites using php. These
>result from
> > > fundamental weaknesses in php's basic arithmetic on monetary figures.
>Accounting integrity is
> > > acknowledged to be completely compromised if developers rely on default php
>arithmetic. Even
> > > calculations such as 8.20 - 0.20 are not dependable. The problems are
>particularly dangerous
> > > because they are intermittent. Php's development team have been aware of this
>for over a year and
> > > despite their much vaunted "open source rapid response", there is no fix, nor
>even any intention of
> > > a fix to this problem. Instead they choose to highlight weaknesses in their
>underlying C platform.
> > >
> > > Bigsoft CEO, Robert Doorways comments : This totally vindicates our view that
>Open Source
> > > technologies must not be relied upon for professional corporate applications.
>Only the most
> > > experienced and highly resourced software suppliers have the understanding and
>capability to deliver
> > > to the corporate market. We fully sympathise with customers who have been taken
>in by the
> > > exaggerated claims of the Open Source movement. We have set up a special php
>translation facilities
> > > for everyone who wants to convert their php applications to a more stable
>language. At BigSoft we
> > > have been counting our own and especially other people's money from our earliest
>days, and are
> > > specialists in big money calculations...
> > OK but php is fully Y2K compliant ;)).
> >
> > hth
> >
> > pa
> > --
> > Pierre-Alain Joye
> > Freelance
> > Developpements et Services web/intranet
> > [EMAIL PROTECTED]
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
