patch ping Re: [java] Fix BigDecimal ROUND_HALF_EVEN

Tue Jul 1 01:54:00 GMT 2003

Hey, folks. Could someone take at this? I had posted a modified
patch for fixing the above in
http://gcc.gnu.org/ml/java-patches/2003-q2/msg00392.html
BTW, I was unable to get mauve snapshot running. It wouldn't
configure at all for me.
Thanks,
Jerry Quinn
Per Bothner writes:
 > Tom Tromey wrote:
 > 
 > >>>>>>"Jerry" == Jerry Quinn <jlquinn@optonline.net> writes:
 > > 
 > > 
 > > Jerry> The following program should output 0.21 after scaling, but
 > > Jerry> outputs 0.20. The attached patch fixes the bug.
 > > 
 > > I don't know this code very well, so I'm reluctant to approve the
 > > patch. Per, could you look at it?
 > 
 > I can't say I understand the code very well either.
 > The test for 'roundDigit > 5' in case ROUND_HALF_DOWN
 > looks suspicious also.
 > 
 > It might be possible to simplify and optimize the code.
 > I'd remove the "+ 1" in the setting of 'power', and
 > then just set unrounded to to parts[0]. I'd drop
 > roundDigit, whihc which makes me feel very uncomfortable,
 > and just compare the remainder (parts[1]) with valIntVal:
 > 
 > For simplicity, assume all the numbers are positive.
 > Then for ROUND_FLOOR or ROUND_DOWN, ignore the remainer.
 > Then for ROUND_CEILING, ROUND_UP, add one to unrounded
 > iff the remainder is non-zero.
 > 
 > Otherwise, double the remainder, and compare it with valIntVal.
 > If the doubled remainder is less than valIntVal, ignore it.
 > If it is greater, treat as ROUND_UP. If it is equal,
 > it depends on the rounding mode in the obvious manner.
 > 
 > Adjust as appropriate if this and/or val are negative.
 > 
 > Does this logic seem correct? If so, do we have a volunteer
 > to try implementing (and testing) it?
 > -- 
 > 	--Per Bothner
 > per@bothner.com http://per.bothner.com/
 > 
 >