If you go with BigDecimal, be aware that it breaks the
equals-hashcode-compareTo contract, in that "2.0" does not equal()
"2.00"<http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html#equals%28java.lang.Object%29>,
and they will almost always have different hashCodes, even though
compareTo() will tell you they are equal.

This can cause problems if you put BigDecimals in a Set or Map and expect
them to behave intuitively.

Siggy


On Thu, Mar 27, 2014 at 1:18 PM, Raymond Shpeley <[log in to unmask]>wrote:

> On Mon, 24 Mar 2014 19:30:39 -0700, Warren Henning
> <[log in to unmask]> wrote:
>
> >will Java's built-in BigDecimal class suffice, or do you need something
> >more specialized?
> >
>
> BigDecimal and BigInteger look like they would provide some rudimentary
> support. Oracle's documentation doesn't show too much in the way of
> functionality for typical experimental math support.  Compare ARPREC
> (http://crd-legacy.lbl.gov/~dhbailey/mpdist/) for example, from Bailey's
> page,
> which uses the Fourier transform for digits > 1000, PSLQ, etc. So, it's
> not just
> a matter of support for big numbers but performance tradeoffs and best
> practices.
>
> Anyway, without a Java library like ARPREC maybe I'll need to start with
> BigDecimal and BigInteger and add on the other tools I need as well as
> tweeking where needed. Maybe I could rely on GP to do the evaluation and
> use
> BigDecimal and BigInteger as primitives. It should even be cleaner that
> way.
>
> Thanks Warren for pointing out BigDecimal.
>



-- 

Ph.D student in Computer Science
George Mason University
http://mason.gmu.edu/~escott8/