This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [java] Fix BigDecimal ROUND_HALF_EVEN
- From: Per Bothner <per at bothner dot com>
- To: tromey at redhat dot com
- Cc: Jerry Quinn <jlquinn at optonline dot net>, java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Tue, 10 Jun 2003 09:22:50 -0700
- Subject: Re: [java] Fix BigDecimal ROUND_HALF_EVEN
- References: <E19MZLG-0001QR-00@localhost> <87ptlssd21.fsf@fleche.redhat.com>
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/