On 24.10.2014 20:13, Andrea Faulds wrote: >> On 24 Oct 2014, at 19:06, Marc Bennewitz <php@mabe.berlin> wrote: >> >> >> On 24.10.2014 01:53, Andrea Faulds wrote: >>>> On 23 Oct 2014, at 20:50, Marc Bennewitz <php@mabe.berlin> wrote: >>>> >>>> You addresses data loss on convert float to int. >>>> Do you also address data loss on int to float? >>>> >>>> |to_float(||9223372036854774784) -> pass |as it results in >>>> 9223372036854774784 >>>> |to_float(|||9223372036854774785|) -> |fail as it results in >>>> 9223372036854774784 >>> Floats aren’t expected to be precise, so I don’t see why this shouldn’t >>> pass. It’s a loss of data, sure, but merely of precision, which is expected >>> here. The reason I have to_int fail is because float overflow to int >>> completely mangles your input. >>> ... It’s a loss of data ... >> And that is the point! If you don't care about loss of data we have more >> than enough functions including default casting (float) operator to cast >> to float. > Floats are special, they are not expected to be precise. If we reject this, > then perhaps we should also reject 0.1, because it can’t be precisely > represented by a float? It's a difference casting string to float or int to float. Floats are often used to make sure an argument is a valid number but this results in data loss incl. on internal functions. take this simple example:
echo number_format(9223372036854774785); > -- > Andrea Faulds > http://ajf.me/ > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
