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

Brian Burkhalter brian.burkhalter at oracle.com
Fri Feb 6 01:43:55 UTC 2015


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.

> 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/

Brian


More information about the core-libs-dev mailing list