On 8 Dec 2006, at 20:31, Mike Blaguszewski wrote:
In an attempt to get identical floating point results across platforms, I'm compiling my project with the -fno-fast-math switch, and using Sun's open source implementation of the standard C math functions. I'll later do the equivalent with VC++ on Windows.
Currently I'm compiling these files directly into my project, and #including the system <math.h> header. This seems to work, but gives me a bunch of linker warnings about multiple definitions for sin, cos, etc.. Is this a reliable thing to be doing? Is there some better way to override functions in libSystem? Worst case, I can rename the custom functions and their calls, but I was hoping to avoid that.
Thanks for any assistance, and if you think my end goal is hopeless, feel free to advise on that too :-)
IMO your end goal is hopeless. There are just too many variables involved for you to reliably get the same results across different platforms (I'm assuming from the lengths that you're going to that you expect the exact same results). For instance, on x86, some of the floating point registers hold more precision than an IEEE 64-bit double (80 bits). On still other platforms, the FP registers hold 96 bits (this was true on 68K and subsequently on some SPARC systems [probably for compatibility reasons… Sun started with 68K]).
And then there's the handling of subnormal numbers, exceptional conditions, rounding and probably other things I can't even think of right now.
Floating point is hopelessly processor specific, and even if you're using the same processor, some operating systems configure processor floating point units differently to others, which can result in different results as well. Plus some chips (the x86 architecture being the primary example, but probably not the only one) have more than one type of floating point unit, and different compilers may default to using different FP implementations on-chip (current practice on x86 chips seems to be to use the SSE instructions rather than the x87 instructions, even for straightforward floating point work).
What you need to do, if you're using floating point, is to use algorithms that aren't sensitive to the differences between implementations. There are plenty of books on numerical methods that cover these kinds of issues.
Kind regards,
Alastair.