JDK-8023217 : Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-08-19
  • Updated: 2019-03-08
  • Resolved: 2016-05-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b120Fixed
Related Reports
Relates :  
JDK-8075806 - divideExact is missing in java.lang.Math
Relates :  
JDK-8158128 - regression: java/time/test/java/time/TestClock_System.java fails at test_OffsetRegular()
Relates :  
JDK-8157527 - Replace @since 1.9 with @since 9 on new math methods
Description
First of all - a big thank you is in order for getting the increment, decrement and negate Exact methods into java.math. This will help us a lot in Nashorn once we get these intrinsifed (even now it helps and gives me performance) 

I also talked to Stephen Coleburne (JSR-310) about our various java.math use cases this weekend.

It would be great if we could get a couple of more last minute changes into java.math, no biggie if it's too late or anything, but it would further simplify the needs of both Nashorn and JSR-310, the date/time API.

    public static int floorMod(long a, int b) {
        return (int) (((a % b) + b) % b);
    }

and 

    public static int floorDiv(int a, int b) {
        return (a >= 0 ? a / b : ((a + 1) / b) - 1);
    }

Which would safe a cast in several common JSR-310 cases and also can intrinsify well

Finally: Furthermore, a variant of multiplyExact with the signature (long, int) would be useful. 

This is by no means something that we require, but it would be nice to have it in 8 if there is still time and you figure that the motivation for it is strong enough. If not, feel free to defer.

Thanks again for your prompt help with the other enhancements.
Comments
Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035468.html Review reprise: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041247.html
18-05-2016
For floorDiv the return type should match the first argument (the dividend), the result will at most require the same number of bits. For floorMod the return type should match the 2nd argument (the divisor), the result will require at most the same number of bits as the divisor. This matches the use cases in java.time and that would remedy the observed runtime exceptions.
21-09-2015
As it would be consistent with the other proposed methods, presumably instead of public static int floorDiv(int a, int b) {} a floorDiv variant with this signature public static int floorDiv(long a, int b) {} was intended, i.e., first parameter long instead of int.
20-08-2015
The implementation of floorDiv() proposed in the description appears to be incorrect. For example consider the counterexample a = 33, b = -7. The floating point quotient is 33./-7 = -4.714285714285714, the floor of which is -5. The expression a >= 0 ? a / b : ((a + 1) / b) - 1 however reduces in this case to a / b = 33 / (-7) = -4.
19-08-2015
I don't understand the proposed addition of floorDiv() here. A method with the same signature already exists in java.lang.Math public static int floorDiv(int x, int y) {} but the implementation is different from that proposed in the issue description.
14-08-2015
Well, I could always use these features if they are there, that's for sure. So if It's not a lot of work, I would like them for 9
12-03-2015
Deferring this to Java 9 unless a more compelling justification is forthcoming or more development time becomes available.
23-08-2013
You would save at least a cast for some common cases in JSR-310, and I would be able to do a weaker multiply in Nashorn, but the gain for me would probably be negligible. Stephen Colebourne would advocate that it's worth it for him, but I can certainly do without them if I have to.
20-08-2013
Would there be any performance improvement facilitated by these additional methods?
20-08-2013