views:

236

answers:

1

I have algorithm/computation in Java and unit test for it. The unit test expects result with some precision/delta. Now I ported the algo into .NET and would like to use same unit test. I work with double data type.

The problem is that Java uses strictfp (64bits) for some operations in Math class. Where as .NET uses FPU/CPU always (80 bits). .NET is more precise and faster. Java is more predictable.

Because my algo is cyclic and reuses the results from previous round, the error/difference/more-precision accumulates too big. I don't rely on speed (for unit test). And I'm happy to use .NET precision in production, but I would like to validate the implementation.

Consider this from JDK


public final class Math {
    public static double atan2(double y, double x) {
    return StrictMath.atan2(y, x); // default impl. delegates to StrictMath
    }
}

I'm looking for library or technique to use strict FP in .NET.

Preemptive comment: I do understand IEEE 754 format and the fact that floating point number is not exact decimal number or fraction. No Decimal, no BigInt or BigNumber. Please don't answer this way, thanks.

+1  A: 

Unfortunately there is no way to enforce FP strictness in C#, the .Net CLR just lacks the ability to do calculations with less precision that the maximum that is can.

I think there's a performance gain for this - it doesn't check that you might want less precision. There's also no need - .Net doesn't run in a virtual machine and so doesn't worry about different floating point processors.

However isn't strictfp optional? Could you execute your Java code without the strictfp modifier? Then it should pick up the same floating point mechanism as .Net

So instead of forcing .Net to use strictfp and checking it comes out with the same values as your Java code you could force Java to not use strictfp and check that it then comes out the same as the .Net code.

Keith
That's good idea. I would probably need to reimplement java Math class to not use strictfp and hope that it's not implemented as strinc in native code of the runtime. But it doesn't solve the problem completely (now I'm just nitpicking). Because I have some constant expected results hardcoded in code, so if I run the unit test on differen hardware later, it will fail.... Well, there is no better answer anyway, you won the race :-)
Pavel Savara