why use int over double?

[Ali Gilani]

i am using the book book beginning java 2. and there is a example showing how the math class works

the program calculates the radius of a circle in feet and inches given that the area is 100 square feet:

 
 
public class  MathCalc
{
    public static void main(String[]args)
    {
         double radius = 0.0;
         double circlearea= 0.0;
         int feet = 0;
         int inches = 0;
         radius = Math.sqrt(circleArea/Math.PI;
         feet = (int)Math.floor(radius); 
         inches = (int)Math.round (12.0 * (radius-feet));
System.out.println( Feet + "feet" + inches + "inches");
     }
 
}
 

 

the output will be 5 feet 8 inches.

my question is why bother with using 'int', why not simply use 'double' for all your variables?

in feet and inches 'int' has been used as the result would have been a floating value. so casting as been used. But doesnt that complicate things?cant one just use long for all variables and forgot about worrying whether the value will fit or not.

[Jeanne Boyarsky]

Ali,
Doubles are not as precise as ints. Does 4 inches equal .3, .33, .333, etc?

[Timmy Marks]

Of course, since the values are all calculated in doubles, you won't get any more precision by converting to ints. I think usually it is a performance issue, since mathematical operations are typically an order of magnitude faster for ints than for doubles. In this particular case, it won't make a difference, since all you are doing is displaying the ints. If you were to use the values of feet and inches for a large number of calculations, you would notice a significant difference.

[Ali Gilani]

If you were to use the values of feet and inches for a large number of calculations, you would notice a significant difference

could you elaborate? how significant would the difference be?


Ali

[Timmy Marks]

Well, the size of the performance difference will depend heavily on the architecture of your system. The best way to find out is just to experiment!

Try something like this:

 
public static void main(String[] args={
  volatile int intFeet = 0;
  volatile double doubFeet = 0.0;
 
  long startTime, endTime;
  startTime = System.currentTimeMillis();
  for (int i = 0; i < 1000; i++={
    doubFeet = 4.0;
    doubFeet *= 5.0;
  }
  endTime = System.currentTimeMillis();
  
  System.out.println("Time for 1000 multiplications (double): " 
                     + endTime - startTime);
 
  startTime = System.currentTimeMillis();
  for (int i = 0; i < 1000; i++={
    intFeet = 4;
    intFeet *= 5;
  }
  endTime = System.currentTimeMillis();
  
  System.out.println("Time for 1000 multiplications (int): " 
                     + endTime - startTime);
}
 

This is just a simplistic example to show the difference between double and integer multiplication. I tried to make sure the only difference is in the multiplication operation itself, so I declared both time vars before the first test, removing any overhead for alotting them. Make sure you declare the variables volatile so the compiler won't optimize them out of the code.

[Ali Gilani]

Timmy,

i am just a beginner learning java, i have not even reached the part when i learn about volatile variables.

Are u saying i should just compile the code? what will happen and how will it tell the difference between int and double???


Ali

[Timmy Marks]

I can't guarantee that the code will compile. I don't have a JVM here at work, so I won't be able to debug it. If it doesn't work, the bugs should be fairly easy to find though.

What it does is, saves the time when it is about to go into the first loop, does a thousand double multiplications and then gets the time again. Then it subtracts the start time from the end time, which gives the total time spent in the loop (plus a small overhead for getting the time. Then it prints out the result before doing the same steps for integer multiplication.

You don't really need to know about volatile variables just yet, they basically tell the compiler "watch out, the value can change somewhere outside the code".

[Dan Maples]

How does a volatile vairable change OUTSIDE of the code? Could you elaborate more please?

Thanks

[Timmy Marks]

Memory can be shared with other threads or other processes. A good example (most often found in C) is when you have peripherals with registers. The peripheral can change the value of the register, so you have to be careful when you write something to the register and then execute, for example, an if based on the value of the register. If you don't declare the identifier as volatile, your compiler could very well say "well, you just set that to x, so the if will always evaluate to false" and then get rid of the if block altogether!

[Ali Gilani]

timmy,

i got the code to work, after a number of errors, but the answer comes to '0' in both cases??/


could you check the code and give me the one that is error free, thanks.

Ali

[Timmy Marks]

I will take a look this evening (Central Europe), but as I said, I have no JVM here at work!

[Timmy Marks]

Ali, just wanted to update you on what I found.

1. Windows XP (on my system, anyway) has a granularity of 10 ms, so anything that completes within the same 10 ms slot in which it starts will get the same end time as the start time, resulting in a measured time of 0.

2. I upped the number of multiplications into the 10 millions, and saw that (again, on my system) the double operations did not take longer than the int operations. So I guess I told you a lie at the beginning regarding floating point being noticably slower than int math.

[Ali Gilani]

timmy, thanks for the reply

could you post the corrected code?

what machine are u using? and could you check it on another PC?

post the code and i'll check the time on my PC too , thanks

Ali
[ June 17, 2005: Message edited by: Ali Gilani ]

[fred rosenberger]

i'm late to the party, but let me chime in with my 2 cents...

first, your original code will always output 0. You set the area to 0, and then compute the radius from that. any circle with an area of 0 will have a radius of 0.

Now, the reason i'd use an int for feet is that it doesn't make sense to use a float here. 25.83299820 inches is EXACTLY 2 feet, 1.83299820 inches. Why would i want to deal with getting 2.0000000001 feet, and then using the formatter to make that display as 2.

The same logic can be applied to inches. Perhaps, for this application, our degree of tolerance is +- 0.5 inches... in other words, as long as we are within 1/2 an inch, we're close enough. therefore, i don't NEED all that decimal noise.
[ June 17, 2005: Message edited by: fred rosenberger ]

[Edwin Keeton]

My tests indicate that double computations are approximately an order of magnitude ( approx. 8 to 15 times) slower than int, using 10,000,000 cycles for each.

[Timmy Marks]

Well, there you have it. Edwin says 8 to 15 times slower for double. I still get about the same result for each. The code I used:

public class Test {
  static volatile int intFeet = 0;
  static volatile double doubFeet = 0.0;
 
  public static void testSpeed(){
    long startTime, endTime;
    startTime = System.currentTimeMillis();
    for (int i = 0; i < 10000000; i++) {
      doubFeet = 4.0;
      doubFeet *= 5.0;
    }
    endTime = System.currentTimeMillis();
    System.out.println("Time for 10,000,000 multiplications (double): " +
                       (endTime - startTime));
  
    startTime = System.currentTimeMillis();
    for (int i = 0; i < 10000000; i++) {
      intFeet = 4;
      intFeet *= 5;
    }
    endTime = System.currentTimeMillis();
    System.out.println("Time for 10,000,000 multiplications (int): " +
                       (endTime - startTime));
  }
 
  
  public static void testGranularity(){
    long startTime, endTime = 0;
    startTime = System.currentTimeMillis();
    while (endTime <= startTime){
      endTime = System.currentTimeMillis();
    }
    System.out.println("Shortest time interval: " + (endTime - startTime));
  }
  
  public static void main(String[] args){
    testGranularity();
    testSpeed();
  }
}

sample output:

Shortest time interval: 10
Time for 10,000,000 multiplications (double): 40
Time for 10,000,000 multiplications (int): 40

I am running Windows XP Pro on an Athlon 2600+ with 512MB Ram

Edwin, how similar is the code you use?

[Edwin Keeton]

I copied your original code listing Timmy. When I copy your last listing the results are (curiously) very close, 1281 for double and 1235 for int (typical results).

This calls for more investigation.

[John Smith]

Time for 10,000,000 multiplications (double): 40
Time for 10,000,000 multiplications (int): 40

The total running time of 40ms is way too short to be meaningful. Additionally, for the double multiplication test, you made it too easy: mutiplying by 5.0 is pretty much the same as multiplying by an integer, isn't it? Try to add a fraction to the number and you will see the difference. I adjusted your code (see new version below), ran the test, and here is the output:

100000000 multiplications (double): 23290
100000000 multiplications (int): 2360

That is, mutiplying doubles is about 10 times slower than multiplying ints.

public class MultiplicationTest {
    private static volatile int intFeet = 5;
    private static volatile double doubFeet = 5.0;
    private static final long ITERATIONS = 100000000;
 
    public static void main(String args[]) {
        testSpeed();
    }
 
    public static void testSpeed() {
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < ITERATIONS; i++) {
            doubFeet *= 5.12345;
        }
        long elapsed = System.currentTimeMillis() - startTime;
        System.out.println(ITERATIONS + " multiplications (double): " + elapsed);
 
        startTime = System.currentTimeMillis();
        for (int i = 0; i < ITERATIONS; i++) {
            intFeet *= 5;
        }
        elapsed = System.currentTimeMillis() - startTime;
        System.out.println(ITERATIONS + " multiplications (int): " + elapsed);
    }
}

[ June 17, 2005: Message edited by: John Smith ]

[Edwin Keeton]

Sorry, when I copied your original code I deleted volatile (and static) while cleaning up a little for the compiler.

[Edwin Keeton]

The difference between the times in John's test and Timmy's is initializing the variables when the class loads versus assigning to it inside the method.

This makes the double run about 3 times slower and the int about twice as fast. I'm sure this has to do with the fields being volatile. I'm not sure whether volatile is isolating the multiplication operation or obscuring it.

And while I also thought this would make a difference, adding values to the right of the decimal place didn't make any difference in my testing. 4.0 gave the same result as 4.12345, etc.

public class Test {
//  static volatile int intFeet = 0;
//  static volatile double doubFeet = 0.0;
  static volatile  int intFeet = 3;
  static volatile double doubFeet = 4.0;
  static final long ITERATIONS = 100000000;
 
  public static void testSpeed(){
    long startTime, endTime;
    startTime = System.currentTimeMillis();
    for (int i = 0; i < ITERATIONS; i++) {
//      doubFeet = 4.12345    ;
      doubFeet *= 5.0;
    }
    endTime = System.currentTimeMillis();
    System.out.println("Time for 100,000,000 multiplications (double): " +
                       (endTime - startTime));
  
    startTime = System.currentTimeMillis();
    for (int i = 0; i < ITERATIONS; i++) {
//      intFeet = 4;
      intFeet *= 5;
    }
    endTime = System.currentTimeMillis();
    System.out.println("Time for 100,000,000 multiplications (int): " +
                       (endTime - startTime));
  }
 
  
  public static void testGranularity(){
    long startTime, endTime = 0;
    startTime = System.currentTimeMillis();
    while (endTime <= startTime){
      endTime = System.currentTimeMillis();
    }
    System.out.println("Shortest time interval: " + (endTime - startTime));
  }
  
  public static void main(String[] args){
    testGranularity();
    testSpeed();
  }  

[John Smith]

doubFeet *= 5.0;

Although it looks like you varied the initial value, you are still multiplying by 5.0, which is not very representitive of a typical double. Try multiplying by 5.12345 instead.

[Edwin Keeton]

The code I posted is a little misleading John. I was switching back and forth from

doubFeet *= 5.0  

and

doubFeet *= 5.123456  

In both cases 38485 was a typical result on my machine, Java 1.5.0.03, Windows XP, Pentium 4 3.0 GHz, 480Mb RAM