What makes you think the C++ and Java results are actually different? In particular how did you print the result? If you were to print the Java result to only 6 decimal places it would very likely produce the same result as you printed from C++.

Java's default conversion from float (and double) to string has the unusual property of containing sufficient digits to allow the original float value to be reconstructed exactly. In other words

For any value of x, Java requires the result to be true. The default conversion of most other languages results in a standard number of decimal places or, for larger values, a fixed number of significant figures.

To compare your results in C++ and Java more easily, I suggest you subtract 1 from the value and print the resulting 'error' term. Then the interesting information from the point of view of comparing accuracy will be in the first few digits.

A second factor which may apply is that Java requires arithmetic on float values to be carried out with exactly float precision; netiher more nor less is permitted. Other languages may treat float just as a storage size and perform the computation to any convenient accuracy. Java's approach has the advantage that a developer won't be fooled into thinking his code works merely because his machine happens to compute (a badly conditioned expression) with unusual accuracy. So with Java we don't get code which works when run on an Intel machine where compiler chooses to use the 80 bit temporary real for internal values, and then fails to work on a PowerPC where ordinary double precision is used. It used to be common (at least for mathematicians) to have to tune numeric code very carefully for particular compiler and processor combinations. With Java we just target the Java specification and all conforming JVM should then produce exactly the same result (with some minor caveats for exponent overflow/underflow).

Thanks.I initially used "print" to output the result.Strangely enough it's now giving me the right result.

I went into Eclipse's debugger to re-check everything and it is now giving me 1.0f exactly.Very strange issue I had.It's cleared up now.

The reason I'm worried about error is because when I do interpolation between quaternions and vectors and other stuff I need absolute precision.I'm actually thinking about writing a shader to do my calcs and then return the final result in order to keep maximum precision, then again video cards usually have less precision than general prupose CPUs.

But as I mentioned in onther thread, the communication between the vRAM and RAM is so slow it's just not worth it. It only works out if you can reduce the vRAM<>RAM I/O to an absolute minimum. Say: hundreds or operations on each texel.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Argh, because of course Float.NaN != Float.NaNThe round trip through String does recover the identical value even for NaN, it is just the test which is tricky.The test should readFloat.toIntBits(z) == Float.toIntBits(x)

Why do you guys get on each other's nerves?"Argh" isn't exactly a friendly manner in which one would respond with.

PS: This is not an attempt by me to get flamed.

'Argh' is not directed at anyone else, usually, when you read it on the forums. It's the equivalent of slapping your forehead in real life when you realize you've made a mistake. Or, as Homer would say, "Doh!".

Why do you guys get on each other's nerves?"Argh" isn't exactly a friendly manner in which one would respond with.

PS: This is not an attempt by me to get flamed.

'Argh' is not directed at anyone else, usually, when you read it on the forums. It's the equivalent of slapping your forehead in real life when you realize you've made a mistake. Or, as Homer would say, "Doh!".

'Argh' is not directed at anyone else, usually, when you read it on the forums. It's the equivalent of slapping your forehead in real life when you realize you've made a mistake. Or, as Homer would say, "Doh!".

Exactly right. The peculiar characteristic that NaN isn't equal to itself was something I ought to have remembered. At the time I was concentrating on the fact that the String conversion should round trip the values exactly (including the NaN case) and forgot that the equality test is tricky.

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

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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?

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... )

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

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.

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org