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? Perofmance testing? 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. 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 > >
