Floating point accuracy in Java not as accurate as C/C++?

Miscellaneous Topics
#21

This may be helpful information.

C has no defined accuracy of floating point calculations. It is totally platform dependant.

Java has a very tightly defined floating point standard, which happens to be about the most accurate choices of options from the IEEE spec.

This is oen of the issues we run into in trying to bring Java down to consumer devices, which often cheat on their floating point hardware. The PS2 is a great example,. to do Java correctly by the current spec would require software emulation of floating poitn on the PS2 :frowning:

#22

Can someone explain how “strictfp” affects this? I had thought that it was added so that floating point hardware could be more widely used when this option was left out… but apparently it isn’t enough?

#23

strictfp opens up one, very limited exception, in order to allow the use of one very useful x86 mode (“fused multiply and add” as I recall) that was illegal by the original spec do to a loss of accuracy in the overflow. This was hurting code-generation on the x86.

It does not go as far as to allow any paltform’s implementation of float. (some of us believe it should, or that there should be another ‘platformfp’ keyword added… )

#24

strictfp does not change the accuracy requirements at all, instead not using it allows the use of an extended exponent range. So that instead of overflowing at about 1e308, much larger values can be represented. This is only permitted for the intermediate values of an expression. On Intel hardware it allows intermediate values to be kept on the FP stack which uses an 80 bit representation. With strictfp each intermediate value has to be saved to memory and then reloaded to force overflow to occur at the expected point. Note that although the FP stack has 80 bits for each entry calculations do not necessarily use the full 64 bit mantissa — there is a mode setting which controls the accuracy required (float, double, extended).

Fused multiply and add is a separate issue usually relating to Power cpus, and this is still not permitted because it uses additional accuracy for the intermediate result.

#25

ok so to summarize: Using strictfp roughly means that intermediate results must be rounded to the precision defined by the Java spec, without it intermediate results can use more precision than the spec allows for, right?

I’m with Jeff, there should probably be a ‘fastfp’ mode that just uses the precision inherent in the native instruction set. If it’s good enough for C/C++ developers, why not? So long as you can get the precision that the spec originally asks for when you need to get the same answers across multiple platforms.

I’m betting there is already an RFE for this, anyone know the number?

#26

Not quite the precision is always as specified. Without strictfp the range of the exponent can be extended for intermediate values only.

As for “fastfp” I think a complete anything goes would be bad idea — there should still be some minimum requirements.

#27

Im on Cas’s side here.

You can get to the platform’s fp, whever it is, in C or even in Pascal. Thre shoudl be a way to do it from Java. If you are purosefully giving up some portability for speed IMHO thats fine as long as its clear that you knwo that that is what youa re doing.

#28

There was a JSR:
http://jcp.org/en/jsr/detail?id=84

[quote]Withdrawn 2002.03.01. Due to the general absence of interest in the community, the Specification lead withdrew the JSR.
[/quote]

#29

A good place to start would be a spec that resembles rather closely the spec of x86 FPU behaviour, don’t you think :wink:

Cas :slight_smile:

#30

Sure, it always makes sense to base things on broken technology :slight_smile:

#31

So long as it infests the face of the Earth I’m happy to go with the flow!

Cas :slight_smile:

#32

[/quote]
Hm. Im surprised by “lack of interest”. I WOULD expect it to be highly controbversial, which might be what that is polite-language for,