6

We all pretty much know how strictfp works.

Something like this:

package com.hk.basicjava.tests.strictfp;

import java.util.*;

public class StrictFP {
    public static void main(String[] argv) {
        double d = Double.MIN_VALUE; 
        System.out.println("non strictfp : " + notStrictFP(d)); // may be 4.9E-324
        System.out.println("strictfp : " + strictFP(d)); // should be 0
    }

    static double notStrictFP(double a) {
        return (a / 2 ) * 2;
    }
    static strictfp double strictFP(double a) {
        return (a / 2 ) * 2 ;
    }
}

But, does any one know particular hardware/OS (and maybe JRE) combination where there is a difference in results returned by methods with and without strictfp specifiers?

I tried several combinations, but there was no difference.

Alex Kreutznaer
  • 1,170
  • 8
  • 18
  • Is a *practical problem* for you then, if you can't find one that makes a difference? :-) – Greg Kopff Jan 24 '13 at 22:34
  • 2
    @GregKopff It may become a practical problem. You'd better know in advance when it may become a practical problem. – Alex Kreutznaer Jan 24 '13 at 22:41
  • @GregKopff If someone's writing a set of in-house coding practices it could be helpful to know if this is still relevant. – Jeff Jan 24 '13 at 22:44
  • 2
    I don't know which formulas would best test such round-off, but I'm pretty sure the values should not be optimizable by the runtime. For example, I'd do `a / x` where x is defined as `static final double x = Double.parseDouble(System.getProperty("nonexistentProperty", "2"));`. – VGR Jan 25 '13 at 13:29
  • Related: http://stackoverflow.com/questions/22562510/does-java-strictfp-modifier-have-any-effect-on-modern-cpus – icza May 26 '15 at 07:32

1 Answers1

0

You're getting a number that the double can represent accurately: Double.MIN_VALUE; so it doesn't surprise me that there's no difference. If you use arithmetic that produces a number that cannot retain its precision, the same arithmetic can produce two different results. strictfp would work in this case, where JVM approximates the answer the same way both times.

user3376587
  • 134
  • 2
  • 12