Helping ordinary people create extraordinary websites!
HOME TUTORIALS SCRIPTS WEB HOSTING BLOG FORUM
Get Our Newsletter
Email:

Mondo Math Libs

By Eric Olson
2003-08-22


Java's BigInteger and BigDecimal

 

Java coders are probably familiar with the java.math package and two of its more interesting classes, BigInteger and BigDecimal. These are both arbitrary precision numeric classes, the first being binary, and the second being decimal, as you might have guessed from the names.

The good news is that these classes have been part of the standard Java implementation since JDK 1.1, so they're "free" to programmers and require no extra work to distribute/install them on a user's system (assuming Java itself is installed).

The primary drawback of these classes is that they're pretty minimalist in comparison with some of the MPM libraries. They support the main four arithmetic operations and some other minor manipulations, but that's it. There are no trigonometric, log, exponentiation, or other features available. As such, they make a good foundation for Java programmers, but they're not enough to support many scientific or advanced applications.

One other interesting note is that IBM has made its own drop-in replacement for Sun's BigDecimal class available. You can download it and documentation from IBM's site (see Resources). IBM's and Sun's BigDecimal classes differ in two areas. IBM improves in a couple of areas on the Sun version, such as making some conversions to less precise data types throw exceptions instead of simply returning bad data. IBM has also added a greater level of control over rounding, but without sacrificing backwards compatibility with existing code.

Java's BigInteger and BigDecimal

Hints and tips
You could write several sizable chapters or even an entire book on the benefits and pitfalls of MPM libraries, but here are a few things to watch out for as you experiment.

  • Always remember that MPM libraries are quirky animals: Every one has its own personality, and you should never assume you can pick one up, slap it into an existing project, and start coding away. At a minimum you should count on experimenting with the library at two levels: a very simple, naive one, in which you just exercise features to gain familiarity with the package, and also a more intense and application-specific one that should reveal the library's oddities and give you a feel for its performance as you'll use it. (And performance can be a particularly thorny issue, because in many cases the authors of some of these libraries have lavished attention on some parts and left others with minimal and slower implementations.)
  • Consider initialization issues: Virtually all MPM libraries will let you initialize variables in their extended precision formats using as constants either the native environment's numbers or string values. This makes sense; it would be silly if you couldn't initialize a multiple-precision variable to anything larger than what a native number will hold. But you can run into trouble with decimal format multiple-precision floating point variables. For example, if you initialize such a variable with the literal constant 0.1, you'll get a nasty surprise. Your compiler will normally convert 0.1 into a binary format, resulting in a repeating decimal value, which will be used to initialize your variable, so your variable won't start off containing exactly 0.1. You can avoid this problem by using a string constant of "0.1" instead of a numeric constant. This will get the desired data into your variable and bypass your compiler's translation efforts.
  • Be careful about semantics: Some libraries, like hfloat, do some unusual things with what seems like "normal" statements. The hfloat manual explains that the line hfloat a = 1234; does not initialize the hfloat a to 1234, but instead sets a's precision to 1234 digits and initializes it to 0. This is probably not what you would expect, and could lead to some spectacular bugs.
  • Know the package's resource requirements: Some libraries require a bit more tender loving care in order to work properly. In some cases you can simply use the library as provided or recompile it, and then drop it into your project as you would any other dynamically linked library. But some libraries require environment variables to be set or other libraries to be present. These details aren't a concern for your own work, but if you plan to distribute a program that uses one of these libraries, it can quickly turn into more trouble than your users are willing to accept.
  • Another aspect of resource requirements is memory usage. Many of the MPM libraries will use all available memory in extreme circumstances, such as dealing with truly huge numbers, but they give you a way to limit the precision of the numbers and the memory used, or to decide when to stage values to disk instead of keeping them in memory. Depending on how widely distributable your application must be, these controls could mean the difference between a successful product rollout and a flop (no pun intended).
  • Handling exceptions, overflows, and underflows: This is another area where MPM libraries vary greatly. Some ignore such issues completely, and others spend considerable effort to give you complete control over and information about how math operations are performed, and the results. Some packages use arbitrary precision representations, as opposed to a fixed precision, eliminating overflow/underflow problems.


Tutorial Pages:
» A look at some of the math libraries for Linux
» Ground rules
» Binary vs. decimal
» Some contenders
» Java's BigInteger and BigDecimal
» Hints and tips
» Resources


First published by

Related Tutorials:
» How to Install PHP 5 on Linux
» How to Install Apache 2 on Linux
» How to Install MySQL 5.0 on Linux
» SMB Caching
» Mound --Bind
» Tar Wild Card Interpretation

Ask A Question
characters left.