Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > BigDecimal: Sun? IBM?

Reply
Thread Tools

BigDecimal: Sun? IBM?

 
 
wald
Guest
Posts: n/a
 
      12-03-2004
Hey group,

I'm considering using the java.math.BigDecimal class for a
simulation program I'm working on. Reading up on the subject, I've
come across a bunch of (seemingly outdated?) pages describing
alternative IBM implementations and specifications improving on
the functionality [1].

Now, several questions pop up because basically I'm confused by
these different sources:

* what's the status of the Sun implementation of IBM's
specifications? There's definitely something going on [2], but it
isn't really clear to me if it's already implemented in J2SE 1.5.0
or not.

* if J2SE 1.5.0 doesn't implement it yet, I guess I could use the
IBM prototype class that's available. But: (i) does it work
decently with J2SE 1.5.0? (ii) the IBM AlphaWorks licensing [3]
does not make me feel very comfortable using it in research
programming, and also mentions a 90 day usage limit... are there
open source alternatives that can be used without concern? I'm
talking academic use here.

Anyway, I hope someone here can provide some answers,

Wald

[1] http://www2.hursley.ibm.com/decimal/
[2]
http://jcp.org/aboutJava/communitypr...013/index.html
[3] http://www2.hursley.ibm.com/decimalj/aworksla.html
 
Reply With Quote
 
 
 
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-03-2004
wald wrote:
> I'm considering using the java.math.BigDecimal class for a
> simulation program I'm working on.


Why? For numerical arithmetic, the issues with exact rounding and decimal
representation that BigDecimal solves are usually not an issue, and using
plain float or double is much, MUCH faster.
 
Reply With Quote
 
 
 
 
wald
Guest
Posts: n/a
 
      12-03-2004
Michael Borgwardt <> wrote:

> wald wrote:
>> I'm considering using the java.math.BigDecimal class for a
>> simulation program I'm working on.

>
> Why? For numerical arithmetic, the issues with exact rounding
> and decimal representation that BigDecimal solves are usually
> not an issue, and using plain float or double is much, MUCH
> faster.


I'm simulating growth models where some quantities evolve from quite
large to very small values, approaching zero in the limit. So,
calculations with these quantities end up in divisions of numbers of
quite different magnitudes. I'm afraid that the limitations of
floating point arithmetic will have more influence than I can
tolerate, especially since the accuracy of simulation results is
quite important in those low-quantity situations...

Wald
 
Reply With Quote
 
Tom McGlynn
Guest
Posts: n/a
 
      12-03-2004
wald wrote:

....
>
> I'm simulating growth models where some quantities evolve from quite
> large to very small values, approaching zero in the limit. So,
> calculations with these quantities end up in divisions of numbers of
> quite different magnitudes. I'm afraid that the limitations of
> floating point arithmetic will have more influence than I can
> tolerate, especially since the accuracy of simulation results is
> quite important in those low-quantity situations...
>
> Wald



Understanding the effects of numerical precision on computations
is a very complex subject in general, but from what you have described
there is no reason not to use normal floating point arithmetic.

E.g., consider

double x = 1.23456789D100;
double y = 9.87654321D-100;

We have here two numbers that differ by 10^200, rather a large factor.

Let

double xy = x/y;
double yx = y/x;

We can ask what is the relative error of the values of xy or yx.
Even though the two values differ by 10^400, the relative error of these
two numbers will both be about the a little better than 1 part in 10^15.
Floating point has no problem dealing with calculations over a vast
range of scale.


Where you might need further precision is if you were doing calculations that
involve something like:

x1 = 1.0000000000000001d0; x2 = 1.0000000000000002d0;
y = 1.;

z = y/(x1-x2);

I've make the values close to one just to demonstrate that it's not the magnitude
of the number that's the problem, it's dealing with differences between almost
equal values, regardless of magnitude.

If you really need to worry about calculations like this you
are in for far more pain than just dealing with BigDecimal!

Regards,
Tom McGlynn



 
Reply With Quote
 
jddarcy
Guest
Posts: n/a
 
      12-10-2004
wald <arnout.standaert@n*o_s-p%a|m.cit.kuleuven.ac.be> writes:

>Hey group,


>I'm considering using the java.math.BigDecimal class for a
>simulation program I'm working on. Reading up on the subject, I've
>come across a bunch of (seemingly outdated?) pages describing
>alternative IBM implementations and specifications improving on
>the functionality [1].


>Now, several questions pop up because basically I'm confused by
>these different sources:


>* what's the status of the Sun implementation of IBM's
>specifications? There's definitely something going on [2], but it
>isn't really clear to me if it's already implemented in J2SE 1.5.0
>or not.


Sun, IBM, and a few others worked on JSR13 and JSR13 is part of jdk 5.
The BigDecimal class now supports floating-point style operations;
i.e. results can be rounded to a given precision. See

http://java.sun.com/j2se/1.5.0/docs/...igDecimal.html

The new BigDecimal features are also described in the article "Fixed,
Floating, and Exact Computation with Java's BigDecimal" from the July
2004 issue of DDJ.

-jddarcy
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57