Hello Todd,
please read that article to get at least a minimum understanding of what
float values are. Speaking of comparisons and floating point values you
might want to consider using fixed point values. That is you decide how
many digits you want for your fractions. Another option is to use
Marcus Boerger wrote:
Maybe you should have a look into PHP's bcmath extension.
PHP's arbitrary precision math handlers are woefully inadequate. I mean,
you can't even take the nth root or a logarithm with bcmath! (gmp isn't
much better).
(However, this has nothing to do with the floating point
to the float-string code, I'd really appreciate
j
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: May 4, 2008 7:06 AM
To: Todd Ruth
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Float comparison
Hello Todd,
please read that article to get at least
If someone could point me to the float-string code, I'd really appreciate
http://lxr.php.net/source/ZendEngine2/zend_operators.c#1075
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
@lists.php.net
Subject: Re: [PHP-DEV] Float comparison
If someone could point me to the float-string code, I'd really appreciate
http://lxr.php.net/source/ZendEngine2/zend_operators.c#1075
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On Sun, 4 May 2008, Jonathan Bond-Caron wrote:
Thanks, I made some tests after looking at
http://lxr.php.net/source/php-src/main/spprintf.c#712
At first glance, I am utterly confused,
ini_set('precision', 100);
setlocale(LC_ALL, 'fr_FR.UTF-8');
echo 0.3; //
On 2 May 2008, at 18:07, Stanislav Malyshev wrote:
Hi!
Is it not possible to overload operators?
Though this would probably even more work to do.
Well, overloading operators in theory would be less work to do,
technically, since extension points would be easier to identify.
However, I'm
On Sat, May 03, 2008 at 02:04:35AM +0100, Richard Quadling wrote:
2008/5/3 Stanislav Malyshev [EMAIL PROTECTED]:
Is it not possible to overload operators?
Though this would probably even more work to do.
Overloading of operators implies strong typing, eg overload + for type money to
be
On Sat, May 3, 2008 at 10:31 AM, Philip Olson [EMAIL PROTECTED] wrote:
On 2 May 2008, at 18:07, Stanislav Malyshev wrote:
Hi!
Is it not possible to overload operators?
Though this would probably even more work to do.
Well, overloading operators in theory would be less work
On Fri, 2008-05-02 at 23:52 -0400, Cristian Rodríguez wrote:
Todd Ruth escribió:
Most people don't care about floating numbers beyond a certain
number of digits.
That's the main flaw in your suggestion, most people.. the language
should be correct, do the real right thing.
Would
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison
I'd like to know if there are reasons not to change the default behavior
when comparing floats.
i.e. This would seem logical to me:
$test =
On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron [EMAIL PROTECTED] wrote:
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison
I'd like to know if there are reasons not to change the default behavior
when comparing
Hi,
Jonathan Bond-Caron wrote:
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison
I'd like to know if there are reasons not to change the default behavior
when comparing floats.
i.e. This would seem logical to me:
I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
== doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.
It could be worse, however. At least the cast to
: internals@lists.php.net
Subject: Re: [PHP-DEV] Float comparison
On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron [EMAIL PROTECTED]
wrote:
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has
been
mentioned before -- float comparison
I'd like to know
Hi Todd,
On Fri, May 2, 2008 at 7:36 PM, Todd Ruth [EMAIL PROTECTED] wrote:
I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
== doesn't exist
We are not the ones to consider that, that's a fact since the very
first
Todd Ruth schrieb:
I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
== doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.
It could be worse, however.
Stefan Walk wrote:
And you'll quickly see that the cast to string before comparision is a
bad idea, because:
$ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);'
bool(true)
Having display settings affect comparisions seems like a really bad idea
to me ;)
Yup, it would be a fatal
On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
Stefan Walk wrote:
And you'll quickly see that the cast to string before comparision is a
bad idea, because:
$ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);'
bool(true)
Having display settings affect comparisions
Hi Todd,
On Fri, May 2, 2008 at 10:03 PM, Todd Ruth [EMAIL PROTECTED] wrote:
(BTW, Pierre, the statement X considers the fact that S1
to mean that S2 is a statement _agreeing_ with S1. It calls
into question whether S1 implies S2. I agree a perfect solution
to the problems we're
On Fri, May 02, 2008 at 01:03:45PM -0700, Todd Ruth wrote:
On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
Stefan Walk wrote:
And you'll quickly see that the cast to string before comparision is a
bad idea, because:
$ php -dprecision=1 -r 'var_dump((string)1.4 ==
2008/5/3 Alain Williams [EMAIL PROTECTED]:
On Fri, May 02, 2008 at 01:03:45PM -0700, Todd Ruth wrote:
On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
Stefan Walk wrote:
And you'll quickly see that the cast to string before comparision is
a
bad idea, because:
$ php
Hi!
What about introducing a money or currency numeric type which
guarantees say accuracy to 8DP?
Funny thing - I blogged about it about a year ago:
http://php100.wordpress.com/2007/03/31/making-with-php/
There's some interesting discussion in comments about how people solve it.
--
Stanislav
2008/5/3 Stanislav Malyshev [EMAIL PROTECTED]:
Hi!
What about introducing a money or currency numeric type which
guarantees say accuracy to 8DP?
Funny thing - I blogged about it about a year ago:
http://php100.wordpress.com/2007/03/31/making-with-php/
There's some interesting
Hi!
Solvable in userland easily enough, but having a native money type,
especially when dealing with inter-currency conversions, then accuracy
is paramount.
Adding native primitive type is expensive - there's a lot of places in
engine and various functions that have to deal with primitive
2008/5/3 Stanislav Malyshev [EMAIL PROTECTED]:
Hi!
Solvable in userland easily enough, but having a native money type,
especially when dealing with inter-currency conversions, then accuracy
is paramount.
Adding native primitive type is expensive - there's a lot of places in
engine
Hi!
Is it not possible to overload operators?
Though this would probably even more work to do.
Well, overloading operators in theory would be less work to do,
technically, since extension points would be easier to identify.
However, I'm not sure we'd want to open that can of worms :)
--
Todd Ruth escribió:
Most people don't care about floating numbers beyond a certain
number of digits.
That's the main flaw in your suggestion, most people.. the language
should be correct, do the real right thing.
--
Progress is possible only if we train ourselves to think about
28 matches
Mail list logo
