>> In sum, I think the rule that if a mathematical operation involves a float, >> the result should be a float ought to be kept. > > Yes, it is a must.
Well, I'm not so sure about that. If you look at the docs of pow(), it describes the return type as "base raised to the power of exp. If the result can be represented as integer it will be returned as type integer, else it will be returned as type float.". That's not the current behavior. pow((float) 2, 1) returns float(2). If you want to update the docs instead of the code, then that's fine. However, this can lead to precision loss in a number of cases (like pow(2, (float) 55) which is not representable exactly by a float, and hence cause data-loss. Whereas converting to an integer allows (on 64 bit platforms) an exact representation. I'm not suggesting changing addition to follow these rules, but to bring pow() into alignment with the documentation. And I think because of the nature of pow(), the likelihood that you'll have precision loss is a lot higher than other areas... But if the sentiment is strong against it, then an update of docs is in order... Additionally, I thought the whole point of type juggling in PHP was such that the type didn't matter? So that a float and an int are the same from a usage standpoint? But this is a case where the exact same input (just type is different) leads to different output. Which I believe is inconsistent and incorrect. But if the consensus is otherwise, that's fine... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
