This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [java] Fix BigDecimal ROUND_HALF_EVEN


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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]