Hi Jordan, > I think this makes much more sense if PHP programmers had internal access > to the float type in PHP, but that's not the case. You cannot choose > between float representations, you cannot easily examine the mantissa bits > directly. In the absence of stuff like that, I think the argument to treat > PHP floats as if they were decimals for the purposes of rounding is much > stronger. > > That said, this sort of 'intelligent' rounding certainly introduces a large > number of edge cases. Additionally, if PHP programmers expect decimal > rounding to "just work", then it feels like anywhere that it doesn't work > the way they think it should is a bug, which isn't necessarily true.
Yes, that's a valid concern. Therefore, I am also proposing to add a function similar to round to BCMath. In a sense, we can think that we are looking for the same functionality in round() that we should be looking for in BCMath. > I'm unsure whether or not this change actually improves anything. Is it > more correct from a technical perspective? Absolutely. Does it provide a > benefit for PHP programmers? That I am much less certain about. In terms of "not lying about the results", this RFC makes us more precise about dealing with FP. However, in terms of benefits for users, there may not be any significant benefits. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
