[9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal, RoundingMode) produces incorrect result

Paul Sandoz paul.sandoz at oracle.com
Fri Feb 6 08:51:20 UTC 2015


On Feb 6, 2015, at 2:43 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Paul,
> 
> On Feb 5, 2015, at 6:06 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> I don't claim to understand the fine details of these methods but i can see how the new method avoid loosing bits.
>> 
>> 4947     private static long[] divRemNegativeLong(long n, long d) {
>> 4948         if (n >= 0) {
>> 4949             throw new IllegalArgumentException("Non-negative numerator");
>> 4950         } else if (d == 1) {
>> 4951             return new long[]{0, n};
>> 4952         }
>> 
>> Why not use an assert instead of an IAE since this is an internal method.
> 
> I had actually wondered whether this could just be a “trusted” method since the check of the first parameter is already done in the calling code, then the if-branch could be removed altogether, but I suppose the assert is safer.

Yes, asserts are good here, they will be enabled when testing.

> 
>> Also the case of d ==1 could be pulled out just like for the case of tmp being +ve: 
>> 
>>  if (v1 == 1) {
>>    q1 = tmp;
>>    r_tmp = 0;
>>  } else if (tmp >= 0) {
>>    ...
>>  } else {
>>    ...
>>  }
>> 
>> then the asserts would be:
>> 
>>  assert n < 0 :  n;
>>  assert d != 1 : d;
> 
> Thanks for the suggestions. Please see updated patch:
> 
> http://cr.openjdk.java.net/~bpb/8066842/webrev.01/
> 

+1, but you should remove the "@throws IAE" on divRemNegativeLong before you push.

Paul;.



More information about the core-libs-dev mailing list