The Math Package

Let's introduce another of the standard classes. This one is called java.lang.Math and it has a couple of dozen useful mathematical functions and constants, including trig routines (watch out—these expect an argument in radians, not degrees), pseudorandom numbers, square root, rounding, and the constants pi and e.

There are two methods in Math to convert between degrees and radians:

public static double toDegrees(double); // new in JDK 1.2
public static double toRadians(double); // new in JDK 1.2

You'll need these when you call the trig functions if your measurements are in degrees.

You can review the source of the Math package at $JAVAHOME/src/java/lang/Math.java and in the browser looking at the Java API.

How to invoke a Math.method

All the routines in the Math package are static, so you can invoke them using the name of the class, like this:

double probability = java.lang.Math.random(); // value 0.0..1.0

All the classes in java.lang are automatically imported, so you can write this as:

double probability = Math.random(); // value 0.0..1.0

Most people will write an import static line near the top of their code (right after the package statement):

import static java.lang.Math.*;

That allows you to shorten the method call to:

double cabbage = random();

Don't forget to compile with the “-source 1.5” option to javac if you use import static.

The Math.log() function returns a natural (base e) logarithm. Convert natural logarithms to base 10 logarithms with code like this:

double nat_log = ...

double base10log = nat_log / Math.log(10.0);

The list of members in the java.lang.Math class is:

public final class Math {
     public static final double E = 2.7182818284590452354;
     public static final double PI = 3.14159265358979323846;
     public static native double IEEEremainder(double, double);
     public static double abs(double);
     public static float abs(float);
     public static int abs(int);
     public static long abs(long);

// trig functions
     public static double toDegrees(double);
     public static double toRadians(double);
     public static native double sin(double);
     public static native double cos(double);
     public static native double tan(double);
     public static native double asin(double);
     public static native double acos(double);
     public static native double atan(double);
     public static native double atan2(double, double);
     public static native double exp(double);
     public static native double pow(double, double);
     public static native double log(double);
     public static native double sqrt(double);

// rounding and comparing
     public static native double ceil(double);
     public static native double floor(double);
     public static double max(double, double);
     public static float max(float, float);
     public static int max(int, int);
     public static long max(long, long);
     public static double min(double, double);
     public static float min(float, float);
     public static int min(int, int);
     public static long min(long, long);
     public static long round(double);
     public static int round(float);

// returns a random number between 0.0 and 1.0
     public static synchronized double random();

// rounds the argument to an integer, stored as a double
     public static native double rint(double);
}

To “strictfp” or not to “strictfp”, is that the question?

The strictfp modifier has a performance cost. CPU's that can do 80-bit double length arithmetic have to take extra steps to get rid of the additional accuracy to mimic processors with standard 64-bit double arithmetic. People doing serious number crunching usually want programs to run as fast as possible, but sometimes consistency of results on all platforms is important too.

The best policy in this situation is to give users a choice. Provide one class that guarantees the fastest best results that a processor is capable of, and provide a second class that will give identical results on all processors.

This is exactly the approach that Java has chosen, support two math libraries with an otherwise identical API: java.lang.Math and java.lang.StrictMath. From the names, you can probably guess that StrictMath uses the strictfp modifier and produces identical results on all platforms. Indeed, that is what javadoc claims for java.lang.StrictMath.

Unhappily, if you look at the source code in the run-time library for these two classes, you'll see that the StrictMath class does not use the strictfp keyword, and java.lang.Math does. When there is a conflict between the documentation and the source code, I generally believe the source code. I filed bug 5050978 against JDK 1.5 beta, but no word back from Sun yet.

You can review and file bugs against Java at http://bugs.sun.com/bugdatabase/index.jsp It's very rare to find a bug in the JDK, and such bugs often result in compiler crashes. If you have a run-time problem in your program, it is almost guaranteed to be a bug you caused.

Originally, all the Math methods were “strictfp”, meaning that the JVM could not use an extended exponent range to represent intermediate results on x86 hardware. That was changed in JDK 1.3, which introduced the package java.lang.StrictMath. StrictMath and Math have the same API. Use StrictMath when absolute portability of numeric results is an issue for you.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.57.172