- **Java**
(*http://www.velocityreviews.com/forums/f30-java.html*)

- - **BigDecimal: Sun? IBM?**
(*http://www.velocityreviews.com/forums/t138925-bigdecimal-sun-ibm.html*)

BigDecimal: Sun? IBM?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 |

Re: BigDecimal: Sun? IBM?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. |

Re: BigDecimal: Sun? IBM?Michael Borgwardt <brazil@brazils-animeland.de> 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 |

Re: BigDecimal: Sun? IBM?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 |

Re: BigDecimal: Sun? IBM?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 |

All times are GMT. The time now is 07:50 AM. |

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.

SEO by vBSEO ©2010, Crawlability, Inc.