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

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