Silent Mage wrote:If a class has the strictfp modifier, does it ensure that methods ran within contained classes also adhere to ieee754 standard? ...
I am assuming the answer is no.
You know what? I don't know.
But I'd say that your assumption is definitely the safest one.
Bonus: can you at compile time (possibly with reflection) make a class strictfp. (I don't want to mess with the source of a sharealike)
Again: dunno, but I don't see any immediate evidence of it via a quick Google. However, if you can do it, it's much more likely to be a flag supplied to the javac command than it is to have anything to do with reflection.
General tip: Reflection in Java is a last resort; so don't go looking for places to use it - especially if you don't have to.
Isn't it funny how there's always time and money enough to do it WRONG?
Welcome to the Ranch
I would suggest reflection won’t help you with something which primarily involves primitives. The answer will be in the Java Language Specification. All floating‑point operations adhere to IEEE754, but may use the extended exponents.
You also see the strictfp keyword can be applied to classes, methods, and interfaces. If you look up the classes link, it says that all methods, constructors, etc are strictfp, also implicitly those in included types. So yes, an inner class would also be strictfp. The same applies if you apply strictfp to an interface.
What FP‑strict means, is described here. There might be more about it in the virtual machine specification.
It appears there are two versions of what IEEE754 mandates, strict and non‑strict, so Java follows IEEE754 at all times.
In the example you wrote, the method is not included inside a strictfp class or method, so it would appear that the Foo method remains in non‑strict mode.
This is too difficult for “beginning”, so I shall move it.
Even before to think about how to make a non-strictfp method as strictfp, please first consider if you really need the method as strictfp in first place.
I'm not a veteran programmer, but to this date, I haven't seen a real-life production-ready piece of code using strictfp. This strictfp thing is used when you are extremely concerned about getting precisely same results for floating point calculations on all platforms.
Please note that this 'same result on all platform' might not be precisely accurate result (because by using strictfp, you strictly adhere to IEEE 754 standard, and you disable the processor's capacity to use extended exponent range to store intermediate results of floating point operations).
The answer is here: 188.8.131.52. strictfp Classes . You'll notice that it consistently talks about "declarations" and not about what happens at run-time.
Joined: Apr 07, 2013
Thank you, I had a feeling that it would no. But not finding a definitive yes or no was driving me crazy. I also had no way to quickly reproduce the divergence so just testing it was next to impossible. (start simulation: Divergence, start simulation:10 hours later GAH!... I am aware that it could be my own code but while doing a total rewrite I stumbled upon how float arithmetic could diverge hardware to hardware)
Reason: fixedstep repeatable simulation, in this case a cross-platform muliplayer game.
"Forgot" to mention to avoid a fixedstep vs client-server discussion.
Winston: Only ever had to use reflection once, and I didn't like it. It appears that reflection can't do this.
You probably shouldn't store the simulation's state using floating point values then. Instead, use discrete time steps, store the state using int/long/BigInteger/BigDecimal, and restrict the precision of your calculations so that the difference in intermediate results between platforms won't have effect on the outcome. If at each time step you "cut off" the part where a platform introduces differences, then you'll always be able to reproduce the same result after a time step, regardless of the platform.
Joined: Apr 07, 2013
Stephan van Hulst, thank you although I already considered this.
discrete time steps: already using a fixed time step, would be next to impossible if not.
int/long: my use of sin/cos makes the lack of decimals difficult, than the realization that I would have to make my own function for them or use strict math to get the same answer than cast it to the required float used by my third party rendering system made me decide not to. (than I attempted to make my own fixed point...)
BigDecimal: Too much math and comparison going on, I imagine that the performance difference + the cast at the end would make it unusable, but I don't truly know and if I try to metric everything I may end up never finishing the project.
Restrict/Cutoff: couldn't the divergence still happen?
A/B = 2.999...7
A/B = 3.000...9
and doesn't strictfp do this on the fpu/cpu already?
Since it is resolved Ill hit the button, I'm not against continued discussion a lone programmer can miss allot of ideas.