On Tue, 31 Aug 2021 07:22:17 GMT, Raffaello Giulietti
<github.com+70726043+rgiulie...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/Math.java line 1501:
>>
>>> 1499: // if the signs are the same and modulo not zero, round up
>>> 1500: if ((x ^ y) >= 0 && (q * y != x)) {
>>> 1501: return q + 1;
>>
>> In `floorDiv()` this line is `r--` and there is only one return statement in
>> the method. I think the accepted convention is to return as soon as possible
>> like is done here, so perhaps it would be good to change `floorDiv()` to
>> match? In any cases the two should be consistent.
>
> Yes, I tend to return as soon as possible (btw, it's a q (for quotient)
> rather than a r (for remainder).
> I can of course modify the floorDiv() family to match this convention but I
> would like not to open an issue just for that. What is best?
I think it's fine to make small changes like this without opening another issue.
>> src/java.base/share/classes/java/lang/Math.java line 1591:
>>
>>> 1589: * is zero exactly when {@code x % y} is zero as well.</li>
>>> 1590: * <li>If neither of {@code ceilMod}(x, y) or {@code x % y} is
>>> zero,
>>> 1591: * their results differ exactly when the signs of the
>>> arguments are the same.<br>
>>
>> I would say "If neither `ceilMod(x, y)`nor `x % y` is zero". Also same
>> question as above: by "exactly when" do you intend "if any only if"?
>
> OK, but for consistency then even floorMod() should be changed. Would this
> require another JBS issue (or CSR)?
If the specifications of the new methods are consistent with their respective
`floorX()` analogs then they are fine as-is and no need to change the analogs
to match.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5285
