On 03/08/14 15:31, Andrea Faulds wrote: >> Your missing the point I was trying to make. That "(int)(3 / 2)" >> > essentially goes wrong only on 64bit systems is the bug that needs >> > fixing. > (int)(3 / 2) works fine, (int)(PHP_INT_MAX / 3) does not. > > It’s not a bug, it’s entirely intentional and expected behaviour. You’re > doing a floating-point division then casting to integer, which will sometimes > lead to a loss of precision. > > And no, having a division wrapped in (int) work differently from a normal > division isn’t a good idea. That means the operator acts differently based on > context. It would mean $a = PHP_INT_MAX / 3; $a = (int)$a; would do something > entirely different from $a = (int)(PHP_INT_MAX / 3);
It may be 'entirely intentional' but that both 32bit and 64bit systems have a binary64 format double may then be wrong? Since most of the processors we are working on these days have quadruple and better precision available, if the '64bit' configuration switched to binary128 floating point, then things work in the same way that they do on 32bit platforms. It's cherry picking individual elements which hides the other aspects of an overview of the problem, and looking at the ranges involved with BIGINT, one either handles the processing via the intdiv() approach, but fixing the range problem on float is an alternative for PHPNext? Of cause no longer relying on 'second' as a base unit is another option, and day based calendar functions will outlive the 52bit rollover ... What ever happened to the x86 80bit precision floating point which had a 64bit fraction ;) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
