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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
