• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

strictfp doesn't seem to be doing it's job

 
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Given the following code:

The output on lines 26 and 29 is the same (see the code comments on lines 6, 7, 15, and 16 to see the effects that the hightest e+number has on that output).
Since the output is the same, I don't see what strictfp double method does differently than the regular double method. What am I missing?
 
Marshal
Posts: 8049
569
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sam Peterson wrote:Since the output is the same, I don't see what strictfp double method does differently than the regular double method.


And what kind of difference you were expecting in outputs?

However, answer to your question could be found in Wikipedia article. Some more technical information could be found in Java Language Specification (JLS).
 
Sheriff
Posts: 7111
184
Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

That Article wrote:Using strictfp guarantees that results of floating-point calculations are identical on all platforms.


So you wouldn't see any difference, even between platforms, and that's it's purpose.
 
Master Rancher
Posts: 4002
52
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the OP's question is, why is there not a difference when we don't use strictfp?  He's comparing code with strictfp, to code without strictfp, and finds that they give the same result.  And the main reason for that is: the only guarantee made for strictfp is what happens when you do have strictfp.  There isn't any guarantee for what happens when you don't have it.  Some systems may behave exactly the same as for strictfp, and some may behave differently.  There's nothing wrong with that, and it's not really something worth worrying about.
 
Liutauras Vilda
Marshal
Posts: 8049
569
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:I think the OP's question is, why is there not a difference when we don't use strictfp?


So perhaps that could be answered to OP in a more primite way, that's because OP's system implementation is so to speak a typical. As in JLS and Wikipedia articles mention, some systems may produce difference as a result of differently achieved floating point arithmethics.

So having strictfp modifier, it ensures, that floating point arithmetics are done following strictly defined standard IEEE Standard for Floating-Point Arithmetic (IEEE 754). So once again, OP's system follows that as a default, hence no difference either way.  
 
Marshal
Posts: 73760
332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But the only differences you are likely to notice even if there is a difference between strictfp and ordinary floating‑point aritthmetic are those differences causing overflow or underflow. Only when here is an intermediate calculation result with an absolute value > Double#MAX_VALUE or < Double#MIN_VALUE. None of the calculations shown produces results outwith the defined range of a double, so there will be no differences observable.

I have only ever used strictfp to see whether it works, and I haev never perceived a difference anyway.
But strictfp isn't a “beginning” subject: moving discussion.
 
Liutauras Vilda
Marshal
Posts: 8049
569
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@OP, thanks for bringing this topic to here. I don't think I ever saw it discussed before.

Did anyone of you considered (had a need) using it in some real cases?
 
Bartender
Posts: 1059
33
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So I saw that strictfp is becoming the default for Java SE 17, and got all hot and bothered for a minute before being reminded that this will generally make no difference on any modern hardware:
http://openjdk.java.net/jeps/306

The only place in practice that you really saw different behaviors was on Intel processors using classical x87 type instructions, which apparently basically never happens anymore.

So you would never see a difference on any places you were going to run Java 17 anyway, if I am not confused.

Logically, we might think this means "get rid of strictfp" but Java doesn't do that.

Instead, tons of documentation gets simpler (JLS and JVM) by just calling everything strictfp by default.

I think this is unlikely to make any difference anywhere except the Java cert exams have one less keyword to ask questions about?
I am just kidding, it has probably been years since they had strictfp questions.  I do own some VERY old Java books, including 1.4 Cert Prep (hand-me-downs, I never took the exams).

There really aren't that many keywords, so removing one from the pool of what we would ever have a reason to use seems like a minor big deal.
 
reply
    Bookmark Topic Watch Topic
  • New Topic