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 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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
