views:

210

answers:

5

Is there a publically available library that will produce the exact same results for sin, cos, floor, ceil, exp and log on 32 bit and 64 bit linux, solaris and possibly other platforms?

I am considering the following alternatives:
a) cephes compiled with gcc -mfpmath=sse and the same optimization levels on each platform ... but its not clear that this would work.
b) MPFR but I am worried that this would be too slow.

Regarding precision (edited): For this particular application I don't really need something that produces the value that is numerically closest to the exact value. I just need the answers to be the exact same on all platforms, os and "bitness". That being said the values need to be reasonable (5 digits would probably be enough). I apologize for not having made this clear in my initial question.

I guess MAPM or MPFR with a low enough precision setting might do the trick but I was hoping to find something that did not have the "multiple precision" machinery/flavor to it. In any case, I will try this out.

+1  A: 

You shouldn't need one. floor and ceil will be exact since their computation is straightforward.

What you are concerned with is rounding on the last bit for the transendentals like sin, cos, and exp. But these are native to the CPU microcode and can be done in high quality consistently regardless of library. However, the rounding does vary from chip architecture to architecture.

So, if exact answers for the transindentals is indeed your goal, you do need a portable library, and you also will be giving up huge efficiencies by doing so. You could use a portable library like MAPM which gives you not only consistent ULP results but as a side benefit lets you define arbirary precision.

You can check your math precision with tools like this one and this one.

SPWorley
Regarding floor: the implementation in cephes seems a bit complicated (http://www.netlib.org/cephes).Regarding precision: For the part of the code that is having problems, I don't really care if these functions don't give me the "exact" answer to the last couple of bits. I just need the answers to be consistent and reasonable. I guess MAPM or MPFR with a low enoug precision setting might do the trick.Drepper's tool seems really useful. Thanks! I will also look into cannot use tybor's lib. Thanks again for the info.
Carlos
+1  A: 

You mention using SSE. If you're planning on only running on x86 chips, then what exactly are the inconsistencies you're expecting?

As for MPFR, don't worry - test it! By the way, if it's good enough to be included in GCC, it's probably good enough for you.

I've run into differences in x86 chip math, but that was 10 years ago and perhaps those differences are gone.
Nosredna
By default gcc would use 387 for the 32 bit build but SSE for 64 bit. So if I compiled cephes I might still get two different answers. That is why I would enforce using SSE. Also if the code uses 387 it may be affected by that unit's precision settings.
Carlos
I am not sure how intensely gcc uses mpfr (doens't it use mpfr to compute constants such as sin(0.13) at compile time?). Anyway, I will give it a try.
Carlos
+1  A: 

You want to use MPFR. That library has been around for years and has been ported to every platform under the sun and optimized by tons of people.

If MPFR isn't sufficient for your needs we're talking about full custom ASM implementations in which case it might be more efficient to consider implementing it in dedicated hardware.

+4  A: 

Would something like: http://lipforge.ens-lyon.fr/www/crlibm/index.html be what you are searching for (this is a library whose aim is to be able to replace the standard math library of C99 -- so keep good enough performance in the normal cases -- while ensuring correctly rounded result according to IEEE 754 rounding modes) ?

AProgrammer
+2  A: 

crlibm is the correct tool for this. An earlier poster linked to it. Because it is correctly rounded, it will deliver bit-identical results on all platforms with IEEE-754 compliant hardware if compiled properly. It is much, much faster than MPFR.

Stephen Canon