patch ping Re: [java] Fix BigDecimal ROUND_HALF_EVEN

[Jerry Quinn <jlquinn at optonline dot net>]

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