Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of brent@worden.org designates
 205.158.62.196 as permitted sender)
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
From: "Brent Worden" <brent@worden.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Tue, 09 Aug 2005 07:15:59 -0600
Subject: Re: [math] Rounding implementation in MathUtils
Message-Id: <20050809131559.D2A6FEE39B@ws6-1.us4.outblaze.com>

All done.

Brent Worden

----- Original Message -----
From: "Brent Worden" <brent@worden.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [math] Rounding implementation in MathUtils
Date: Mon, 08 Aug 2005 13:53:28 -0600

>=20
> I started working on this today.  I've resorted to rolling our own roundi=
ng=20
> functions instead of relying on BigDecimal for conversions.  I will keep =
all=20
> the rounding options supplied by BigDecimal.
>=20
> Hopefully, I can get this done today.
>=20
> Brent Worden
>=20
> ----- Original Message -----
> From: "Phil Steitz" <phil.steitz@gmail.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Subject: [math] Rounding implementation in MathUtils
> Date: Mon, 8 Aug 2005 07:22:17 -0700
>=20
> >
> > Can someone else pls have a look at
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=3D35904
> >
> > This is holding up the 1.1 release.  I like the support for all of the
> > rounding modes that we get by using BigDecimal and - though I have not
> > verified this - I would expect the results to be exact over a wider
> > range of <value, scale> combinations than direct implementation would
> > give.  On the other hand, we have the string conversion and object
> > creation overhead.  I haven't done any microbenchmarks, but if someone
> > else has the time, it might be good to look at direct impl of, say,
> > ROUND_HALF_UP vs. the current impl.  Opinions please...
> >
> > I am inclined to close this as FIXED (once more tests have been
> > added).  Note that this will commit us to supporting all of the
> > rounding modes, even if we decide to replace the implemenation later.
> >   Some of these - e.g. ROUND_NOT_NECESSARY -  may have funny semantics
> > for some double / float values.   Additional unit tests to document /
> > demonstrate / validate exactly how all of these modes work will be
> > needed in any case.
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org