Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37410
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain proposaltech.com from 68.142.198.200 cause and error)
Reply-To: truth@proposaltech.com
To: internals@lists.php.net
In-Reply-To: <481B6068.9060402@lerdorf.com>
References: <001401c8ac74$dda6d060$98f47120$@com>
	 <fe05d1540805021004s3fd152d6m48770f6948098689@mail.gmail.com>
	 <1209749793.1075.54.camel@inspiron.local> <481B5F45.4030106@gmail.com>
	 <481B6068.9060402@lerdorf.com>
Content-Type: text/plain
Date: Fri, 02 May 2008 13:03:45 -0700
Message-ID: <1209758625.1075.87.camel@inspiron.local>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Float comparison
From: truth@proposaltech.com (Todd Ruth)

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 seems like a really bad idea 
> > to me ;)
> 
> Yup, it would be a fatal flaw in the language if that ever came to be.
> 
> -Rasmus

Most people don't care about floating numbers beyond a certain 
number of digits.  If precision were the only ini setting that
gave us an idea of how much the person cared, I think it would
be fair to use the setting or introduce a new setting.  As it
happens, there is another setting.  How would you feel about
this returning true:

php -dserialize_precision=1 -r 'var_dump(1.4 == 1.1);'

Setting serialize_precision to 1 is a very strong statement of
not caring about those digits.  Personally, I don't care about
more than about 6 digits and I don't do much math, so I could
set it to 8 digits and be happy.  Not everyone has the luxury
of controlling ini settings, but for those that do, this
would be much nicer than having
(string)(float)$s === (string)$f
and as you point out, the casts aren't perfect anyway.  (In my
case, the casts are somewhat appropriate, because I'm checking
whether a user input is the same as the default that was provided.
The default came from casting the result of a computation to a
string.  Yes, there are other more efficient ways to deal with 
that too.)

If that still doesn't feel right, how about:

php -dcomparison_precision=1 -r 'var_dump(1.4 == 1.1);'

could return true.  The default for comparison_precision would
be the same as the default for precision.

It could be interesting to apply comparison_precision when a float 
is used as an array index...  I'm not sure whether that would do 
BC harm off the top of my head.  There may be other cases where 
floats are used as an r-value that this might help.  I suppose 
anything involving a float that does not lead to the production of 
a new float would be well served by this.  For example, $z=$x+$y 
shouldn't use this feature at all because all of $x's and $y's bits 
should be used and all of the bits of $z should be kept for now.  
in_array() would be friendly to use this feature though.

Better?

(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 discussing don't exist.  I don't think
that implies that improvements should not be made.)

- Todd