Re: PHP can't compare...

On Thu, 06 Dec 2001 18:03:23 +0000 George Whiffen <george@intellnet.net.uk> 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 pajoye@tuxfamily.org