What am I doing? (numerical mathematics, related to BigDecimal)

[Stefan Ram]

I admit that I actually do not know what I am doing,
possibly someone can explain this to me.

I wanted to use »java.math.BigDecimal« for some calendar
calculations so as to never have to worry again about any
limitations.

Eventually, it all worked, but I have a loop, where I
keep incrementing certain dates based on previous calculations.
BigDecimal tries to keep track not only of the values, but
also of their precision. A certain variable I use in the loop,
will take values as follows in some cases (simplified):

1.0
2.00
3.000
4.0000
5.00000
6.000000
7.0000000
...

This means, that the loop will become slower and slower
and eventually stop due to lack of memory for all those »0«.

No, my naïve idea is to add a step to my date package where
I do what a human would do when calculating with a pencil:
discard all the trailing »0« from the results of my
BigDecimal calculations.

But from the point of numerical mathematics, what am I doing,
when I am doing this?

Is it a mistake to do this?

Has anyone else already had this effect and are there other or
better solutions for it?

 

[markspace]

also of their precision. A certain variable I use in the loop,
will take values as follows in some cases (simplified):

An SSCCE would help here.

In the meantime, I'd suggest you use the BigDecimal methods that take a
MathContext. MatchContext allows you to specify the number of digits,
so you never have to worry what BigDecimal is going to do, it does what
you said.

I played around with BigDecimal a while back, and I found that the
MathContext is required. BigDecimal assumes "UNLIMITED" as a context,
and you'll get an OutOfMemoryException as soon as you try something like
1/3 because it repeats infinitely. You have to use a context to limit
the number of digits.

I just used one of the pre-fab ones that are static inside BigDecimal:

BigDecimal.DECIMAL128 and
BigDecimal.DECIMAL32

 

[Stefan Ram]

I do what a human would do when calculating with a pencil:
discard all the trailing »0« from the results of my
BigDecimal calculations.

PS: Just now I learned that there already is a method

http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html#stripTrailingZeros()

, so others should have some need for this, too.

 

[charlesbos73]

Hi,

I wanted to use »java.math.BigDecimal« for some calendar
calculations so as to never have to worry again about any
limitations.

From the "JODA time" FAQ:

Q: What date range is supported?

A: The range supported is -292,269,054 to 292,277,023.
A: In other words, roughly +/- 290 million years to
A: millisecond precision.
A:
A: If you want a date outside this range, ask yourself
A: if you really want millisecond precision. In reality,
A: dates this far in the past or future should only be
A: stored as years - anything else is meaningless.

Which limitation would you hit when working with dates
using JODA-time (which is using long internally to store
dates) that you wouldn't hit using BigDecimal?

Depending on the calculation you're doing, JODA-time may
be handy...

Has anyone else already had this effect and are there other or
better solutions for it?

I found that replacing the ill-conceived, thread-unsafe,
underperforming and overall madening Java date and calendar
classes with JODA-time was usually a "better solution"

It fixes many of the gigantic monstrosities (the JLS-nazi
bot that shall recognize himself shall probably disagree
and join the discussion explaining how perfect Java has
always been) present in the "stock" Java date and
calendar classes

 

[Stefan Ram]

Which limitation would you hit when working with dates
using JODA-time (which is using long internally to store
dates) that you wouldn't hit using BigDecimal?

I started to write my calendar package, when JODA was not
yet there or was not yet well-known.

My date package is based on interfaces for one integral
type and one floating-point type. I have chosen to implement
those interfaces using »java.math.BigInteger« and
»java.math.BigDecimal« for the first applications, but
might as well implement them using »int« or »long« and
»float« or »double«, later.