A couple of things:
(a) doubles are actually more accurate than floats (more digits). Because
of that, they're more prone to the exact comparison errors :) I wouldn't
hold my breath about float getting into the language...
(b) To do what you want, you can still use bcmath or one of the other math
libraries, which perform operations on strings.
Zeev
At 19:20 05/12/2001, 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+numbers%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]
