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]
