If you go with BigDecimal, be aware that it breaks the
equals-hashcode-compareTo contract, in that "2.0" does not equal()
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.


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