Tomm Carr <[EMAIL PROTECTED]> wrote:
> Joseph Ottinger wrote:
>
> > I used to work in financials as well (for the State of Florida) where
> > we, too, had to balance out to the penny. We did so with COBOL, and
> > managed portions ourselves. It *can* be done. :)
>
> Right. Any spec is going to have an error tolerance in it. There is no
> such thing as absolute accuracy. I don't think there is even a
> definition of absolute accuracy. Even the feds can't demand something
> that doesn't exist. However, demanding accuracy to the nearest penny is
> certainly within the capabilities of a 64-bit double floating point data
> type. If not, how would they even know your calculation was off by a
> penny? Do they test it with 128-bit floats?
You are confusing accuracy with precision. You cannot get penny-level accuracy
if your number scheme only supports 14 decimal digits of precision (like IEEE
double) and the number to be represented is one hundred trillion(US:
10-to-the-14th) dollars(US). However, when dealing with normal (significantly
smaller) amounts you should be able to get the desired accuracy, unless the
number of calculations begins to cause rounding error to creep into the pennies
digit...
> So why does Java have BigInteger and BigDecimal? For the padded cell
> crowd that want to calculate pi or e or Plank's Constant to the
> millionth decimal place. But their real-world usefulness is limited.
Err... no. The padded cell crowd, if they are serious about these rediculous
precisions, have many alternatives to Java that are more appropriate for this
kind of work.
> Limited does not mean non-existant. I have a calculation that uses
> Fibonacci values which can get quite large quickly. So, during that
> part of the calculation, I use BigInteger. Even in this one place I use
> it I could probably get away with using doubles to hold large integer
> values, but this is such a small part of the overall calculation which
> is such a small part of the total application that the performance hit
> is negligible so why not?
A long will hold the first 92 terms of the classic Fibonacci sequence. Am I to
understand that you needed more terms than that?
Besides that, if you use doubles you will lose precision sooner than you will
with longs. A double can represent a larger absolute value than a long, but
doubles have *less* precision than longs:
double: 14 decimal digits of precision.
long: 18 decimal digits of precision.
> Another application which could use BigInteger during intermediate
> processing is statistics. There are many statistical equations which
> use factorials. The final answers are quite reasonable in scope, but
> the intermediate calculations use very large values.
That is why most statistical calculations which require division of factorials
are based on the algebraic reduction of the ratio to least (algebraic) terms.
So in the following calculation:
(n!)/((n-r)!)
The computation would be reduced to something like this:
long n = whatever;
long r = somethinglessthanwhatever;
long result = 1;
for( long i = 0; i < r; i++ )
{
result *= n - i;
}
In this case, if we are sure the result will be "reasonable", then we can be
sure that each of the intermediate terms is "reasonable" as well.
However, none of this is really related to BigDecimal.
> All this means is that the usefulness if BigInteger and BigDecimal are
> restrictive and, if used, should be limited only to where they are
> essential. To adopt the use of BigDecimal for all floating point
> calculations, as the original poster implied he might do, just to obtain
> an arbitrary level of precision is unnecessary.
To say the least!!
> Btw, if BigDecimal can be an arbitrary length, what is returned when you
> divide 1 by 3 using BigDecimal? There has to be some point in
> generating the sequence of 9's where even BigDecimal has to call it quits.
If you had take the time to read the Javadoc before asking this question, you
would see that all the overload methods of divide() have a rounding policy
argument, which says what to do when you have run out of significant digits,
and one overload has a scale argument which sets the number of significant
digits to meet your specs. If you use the "don't round" rounding policy and
you run out of significant digits, BigDecimal throws an exception.
-- Roger
=====
-- Roger Glover
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
To change your JDJList options, please visit: http://www.sys-con.com/java/list.cfm
