Thanks for the explanation, I don't think that the change in floorDiv behaviour will cause JSR-310 a problem Stephen
On 22 February 2012 16:21, Roger Riggs <roger.ri...@oracle.com> wrote: > > On 02/22/2012 09:37 AM, Stephen Colebourne wrote: > > Can you explain why the mod implementation differs from that in JSR-310? > https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/MathUtils.java#L401 > > The code ((a % b) + b) % b; is short and involves no branches, which > should aid performance and inlining. Is this to do with accepting a > negative second argument? Performance testing? > > For floorMod, the numeric results are the same but the performance is > slightly better. > > The performance difference is very noticeable for long's, using > a single divide and a multiply with the branch is about 1.5 times as fast > as the alternative using two % operations. > > For int's the difference was minimal but still faster. I did not compare > against > floating point divide. > > Since it depends on the performance of the divide instruction it will > be sensitive to specific processors. For interpreters and devices > without floating point hardware (yes they exist) and slower hardware > minimizing > the number of divides makes sense. I would rather not try to tune for > specific hardware and leave that to the VM. > > > I'd like to see performance numbers comparing the two approaches, as > JSR-310 might need to continue using the double % version if it is > faster. > > Similarly, the proposed floorDiv requires evaluation of the complex if > statement every time, whereas the JSR-310 one only requires an if > check against zero. Whats the rationale for the difference, which is > intuitively (non-proven) slower., > > For floorDiv, the results are different when the sign of the divisor is > negative. > Using the definition of the largest integer less than the quotient with the > arguments (4, -3) should be -1.3333, the largest integer less than that is > -2. > The JSR 310 expression (a/v) evaluates to -1. > > I choose to be consistent with the Math.floor behavior. > > Roger > > > > > thanks > Stephen > > > On 22 February 2012 14:24, Roger Riggs <roger.ri...@oracle.com> wrote: > > Hi, > > 6282196 There should be Math.mod(number, modulo) methods > <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282196> > > Requests that floor and modulus methods be provided for primitive types. > Floor division is pretty straight-forward, rounding toward minus infinity. > For modulus of int and long, the sign and range follow the exiting floor > method > in java.util.Math and satisfy the relation that mod(x, y) = (x - floorDiv(x, > y) * y). > > Please review and comment, > http://cr.openjdk.java.net/~rriggs/6282196.1/ > > Thanks, Roger > > >
