Re: PHP can't compare...

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! And I had this "great" plan worked out: 1. functions ------------ Only make one minimal change to the functions we need to change e.g. floor, ceil, as follows:- Set a new flag on the call to zend_parse_parameters_ex e.g. ZEND_PARSE_DOUBLE_CONVERT to request that any double parameters are taken down to "safe" precision. 2. zend_parse_parameters_ex --------------------------- Check for this new flag, ZEND_PARSE_DOUBLE_CONVERT, and if set do a convert on any doubles requested in the type_spec with a convert_to_double(convert_to_string(*var)) or something similar. 3. operators, ==, ===, >= etc. ----------------------------- I don't know where to find zend_operators.c or its equivalent on cvs, but looking at an old 4.0.2 source, I got the feeling a few little tweeks to the handling of doubles in "compare_function" might do the trick for all the operators in one go. I guess it's a lousy plan... George P.S. Many thanks for restoring my sanity. Now I've just got to work out how to apologise to Rasmus and Pierre-Alain for being such a pain on this issue! P.P.S. I can't seem to get to the php-dev newsgroup. > At 21:12 10/12/2001, George Whiffen wrote: > >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. > > > > > > > floor(string(8.2 - 0.2)) == 8.) > > > > > > Sure, this will work for exactly the same reason that > > > floor(round(8.2 - 0.2) == 8.0) will work. What you are implying is that > > > we should always be doing an implicit round() which is not a good idea. > > > This should be something that is up to the developer. > > > > > > > So why doesn't php do this cast/round for me? That's my question. > > > > > > Because that would impose rounding errors and remove the develpor's > > > flexibility for controlling this exactly. > > > > > > -Rasmus > > > >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 no discretion > >that you are leaving with > >the developer that can be meaningfully used! > > > >Instead you are saying that we cannot protect users who are using less > >than 14 decimals through > >rounding because of the potential loss of control for developers who are > >using 14 decimals or more > >who have ALREADY been told NOT to use this function! > > > >This strikes me as frankly bizarre! The current situation benefits noone! > >My suggestion benefits > >EVERYONE except the small set of developers using medium/high precision (> > >14 decimals) for whom > >these functions are already inappropriate. They, therefore, lose > >nothing! The rest do gain, a lot! > > > >REMEMBER: This is emphatically NOT the same case as rounding floats on > >general arithmetic functions > >where the rounding errors can easily propagate, rounding then would be a > >VERY BAD THING. This > >rounding will NEVER "pollute" a float, since the functions/operators do > >not return floats! > > > > > >George > > > >-- > >PHP Development Mailing List <http://www.php.net/> > >To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > >For additional commands, e-mail: php-dev-help@lists.php.net > >To contact the list administrators, e-mail: php-list-admin@lists.php.net