Your suggestion does make sense, but it's probably impractical at this
point, as it requires a rewrite of pretty much every function or piece of
code that deals with floats. It sounds like a noble cause, but one that
would have to wait for now :)
Zeev
At 21:12 10/12/2001, George Whiffen
Zeev Suraski wrote:
Your suggestion does make sense, but it's probably impractical at this
point, as it requires a rewrite of pretty much every function or piece of
code that deals with floats. It sounds like a noble cause, but one that
would have to wait for now :)
Zeev
Uhh shucks!
Rasmus,
You're right someone doesn't get it, but I'm still not convinced that it's me!!
I do understand that 0.1 cannot be finitely expressed in binary and in particular
that You can't
compare floating points in C.
But I don't want to do this! I want to compare php numbers, which can be
But I don't want to do this! I want to compare php numbers, which can be either
strings or floats,
in php! This already works fine when the php number is passed as a string, I just
want it to also
work when it's passed as a float/double!
Which is not possible.
floor(string(8.2 - 0.2))
Rasmus Lerdorf wrote:
But I don't want to do this! I want to compare php numbers, which can be either
strings or floats,
in php! This already works fine when the php number is passed as a string, I
just want it to also
work when it's passed as a float/double!
Which is not possible.
But my suggestion only produces rounding errors when the developer is trying to
operate on floats
with results of precision greater than 14 decimals. These developers should already
know they MUST
use bc or gmp in such cases.
You may say it should be up to the developer, but there is
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
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
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
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
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).
If you are dealing
On Thu, 06 Dec 2001 18:03:23 +
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
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.67
Not some long draw out number like 63.671 or even
63.669... If PHP
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.67
Not some long draw out number like 63.671 or even
63.669... If PHP uses precision past the 6 digit then it needs to
On Wed, Dec 05, 2001 at 12:09:33PM +0200, Zeev Suraski wrote:
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
On Wed, 5 Dec 2001, Matthew Hagerty wrote:
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
On Tue, Dec 04, 2001 at 05:38:10PM -0500, Matthew Hagerty wrote:
I'm going to stop ranting and go check PHP's source, make some tests in C
and such. But with this type of number representation, PHP becomes
inaccurate in all but the most simple use of numbers.
I find this surprising as
Hello,
this is how floating point numbers work.
3.55 as float is not 'exactly' 3.55, but it is stored in memory as an as
good as possible representation, something like 3.551 perhaps.
If you simply compare this:
3.550001 + 60.12001 != 63.69
so that's
Okay, then why when I ask PHP to show me the value of $fFloat1, do I get this:
printf(%f, $fFloat1); - 63.67
Not some long draw out number like 63.671 or even
63.669... If PHP uses precision past the 6 digit then it needs to
show me that it does.
I can't agree with your
However, even if the number is not stored as indicated, ie. 3.551
instead of a clean 3.55000, 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
20 matches
Mail list logo
