I don't think that a PR like the one you raise is likely. Mostly all other
languages behave in the same way. Even other software components, such as
databases, often have this issue, unless you use string base representation.
Zeev
At 20:03 06/12/2001, George Whiffen 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.
>
>2. Zeev is worried that a string based type would create performance problems.
>
>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.
>
>4. bc calculations/comparisons are safe.
>
>5. Something funny is already happening in php with decimals i.e. print 1
>* 0.1 is always 0.1 and
>never 0.10000001 or whatever else has the same binary representation.
>
>
>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
> - maximum values could be practically limited to a billion or so
>
>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?
>
>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.
>
>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!
>
>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?
>
>
>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!
>
>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...
>
>
>
>George
>
>Matthew Hagerty wrote:
> >
> > At 12:09 PM 12/5/2001 +0200, Zeev Suraski wrote:
> > >At 00:38 05/12/2001, Matthew Hagerty wrote:
> > >>Okay, then why when I ask PHP to show me the value of $fFloat1, do I get
> > >>this:
> > >>
> > >>printf("%f", $fFloat1); -> 63.670000
> > >>
> > >>Not some long draw out number like 63.67000000001 or even
> > >>63.66999999999... If PHP uses precision past the 6 digit then it needs
> > >>to show me that it does.
> > >>
> > >>I can't agree with your reason because computers are not that imprecise.
> > >
> > >They are. Generally, the equality operator on floats is inaccurate by
> > >definition, you learn that in Numeric Analysis 101 :) Comparing floating
> > >point numbers should only be done by comparing ranges. E.g.,
> something like
> > >
> > >abs($num1-$num2)<0.00001
> >
> > Yes, I'm finding this out... It was my own ignorance that let me shoot my
> > mouth off. I should know better, but frustration set in early.
> >
> > <snip>
> > >>However, even if the number is not stored as indicated, ie. 3.55000000001
> > >>instead of a clean 3.550000000, then why does PHP take the liberty to
> > >>chop off that precision when converting to a string? And why is that
> > >>precision not put back on when going back to a double? It is not put
> > >>back on because PHP can represent 3.55 as a clean 3.5500000000, so the
> > >>assignment of floats, ie. $fFloat = 3.55;, is coded in error in PHP's
> > >>internals!?
> > >
> > >There's no clean 3.55, there simply isn't. It's just how computers
> > >work. The only way to do what you're asking for is to switch to a whole
> > >different string-based representation, which is going to slow things down
> > >very considerably.
> >
> > My tests in C revealed that with floats (4 byte floats) the math works, I
> > guess the precision can be kept under control, but when using doubles I get
> > the same results as I got with the PHP code.
> >
> > Why was the decision made to have all "float" types in PHP set to
> > doubles? Doubles are good for really big numbers, but floats come in handy
> > at times too (like this) where the added precision becomes more of a
> > hindrance. Any chance in getting both 4-byte floats and 8-byte doubles
> > into PHP?
> >
> > The issue that kicked this whole thing off came about because I have to
> > deal with money values. PHP only has integers and doubles for dealing with
> > numbers, not counting boolean (unless I missed one), so you can't really
> > reliably represent, say $3.55. Money math is a tricky beast and values
> > need to be kept under control. It would be nice to have a fixed precision
> > type similar to SQL's numeric or number types. I can get by with bcmath
> > for now, but a built-in type that takes care of this kind of thing
> > automatically would be really nice!
> >
> > >It was annoying to discover this reality for me as well when I took this
> > >course a few years ago, but it's reality all the same. You can search the
> > >Web for this issue, e.g.
> > >http://www.google.com/search?q=%22never+compare%22+%22floating+point+nu
> mbers%22
> > >
> > >Zeev
> >
> > Thanks for the education, sorry about all the fussing!
> >
> > Matthew
>
>--
>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]
--
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]
