On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds <a...@ajf.me> wrote: > Hi Pavel, >
Hi, thanks for explaining some things. > > It can *sometimes* be a lossless conversion. Only sometimes. > > For float to int conversion: > > * Floats have the special values INF, NAN and -NAN, which cannot be preserved > * Floats have negative zero, which also cannot be preserved > * Fractional components cannot be preserved > * Floats sacrifice precision to allow a wider range of values. They work with > significant figures (scientific notation), unlike integers which always offer > full precision. So a particular float value isn’t necessarily equivalent to a > particular integer value, you have to invent precision to do the conversion. > 2e10 is dealt with as if it’s 2 with 10 zeroes after it, but it’s just a > number beginning with 2 that has a magnitude of roughly 10^10. If you convert > it to the integer value 20 000 000 000, you’ve just invented values for those > trailing digits - those digits weren’t necessarily zero, we just don’t know > what those digits are. Someone who’s an expert on floating-point might need > to correct me here, but I think this is correct to some extent. What I’m > saying is that float->integer conversion is inherently imprecise. > > For int to float conversion: > > * Values beyond 2^53 or below -2^53 cannot be represented as floats without a > loss of precision > > Some strongly-typed languages allow these conversions implicitly, but I’m not > sure that’s a good thing or something we should want to copy. Loss of > precision isn’t good. If you ask for strict typing, you probably want to > avoid it, and should get strict typing. > >> And being able to pass a float(1.5) to int and lose the 0.5 value >> doesn't make sense as well, because data will get lost. Neither of >> those feels somehow "predictable" and "natural”. > > Sure, but it is our existing behaviour. > Yeah, as I said, implicit float to int is IMHO bad and I personally don't like it much, because data loss sucks. But being consistent with existing behavior is probably the right way to do stuff. About the problem with int to float and loss of precision beyond 2^53: I didn't realize that, was thinking just about 32bit integers when I wrote that. But now I wonder how other languages do it, when they are implicitly converting 64bit integers to double precision floating point numbers. > > Unfortunately we don’t have safe casting functions because they were > rejected. Alas. > >> So, I think it would be best to choose just one of these two >> approaches and either loosen it a little or make it more strict (so >> data loss doesn't happen). But I guess this approach would be >> inconsistent with how the built-in PHP functions work? > > While it never went to a vote, the Scalar Type Hinting with Casts RFC, which > proposed stricter weak casts, was not well-received. The Safe Casting > Functions RFC was rejected when it went to a vote. > Oh, I didn't know that stricter weak casts were not well-recieved, because I didn't read internals mailing list back then. But if that's the case, I would gladly see the weak variant of this RFC accepted. Have you thought about splitting this RFC into two? One for adding the weak version and another one for adding the declare strict statement? > > The Scalar Type Hinting with Casts RFC didn’t do that, it was also based on > values. > > In a dynamically-typed language like PHP, I don’t see why it needs to be > type-based rather than value-based. > Maybe I wrote it wrong; I knew the old RFC had conversions based on values. I just thought the rules based on types (you definitely know what you need to convert and what not before calling a function) would make much more sense, but the problem with 2^53 means that the typed-based conversions are not a great solution either. Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
