views:

394

answers:

5

HI,

I am trying to use the robust predicates for computational geometry from Jonathan Richard Shewchuk.

I am not a programmer, so I am not even sure of what I am saying, I may be doing some basic mistake.

The point is the predicates should allow for precise aritmthetic with adaptive floating point precision. On my computer: Asus pro31/S (Core Due Centrino Processor) they do not work. The problem may stay in the fact the my computer may use some improvements in the floating point precision taht conflicts with the one used by Shewchuk. The author says:

/* On some machines, the exact arithmetic routines might be defeated by the  */
/*   use of internal extended precision floating-point registers.  Sometimes */
/*   this problem can be fixed by defining certain values to be volatile,    */
/*   thus forcing them to be stored to memory and rounded off.  This isn't   */
/*   a great solution, though, as it slows the arithmetic down.              */

Now what I would like to know is that there is a way, maybe some compiler option, to turn off the internal extended precision floating-point registers.

I really appriaciate your help

A: 

If you're using GCC, the SO answer here might help:

If you're using another compiler, you might be able to find some clues in that example (or maybe post a comment to that answer to see if Mike Dinsdale might know.

Michael Burr
A: 

The complier option you want for Visual Studio is /fp:strict which is exposed in the IDE as Project->Properties->C/C++->Code Generation->Floating Point Model

Joe Gauterin
+1  A: 

Yes, you'll have to change the FPU control word to avoid this. It is explained well for most popular compilers in this web page. Beware that this is dramatically incompatible with what most libraries expect the FPU to do, don't mix and match. Always restore the FPU control word after you're done.

Hans Passant
A: 

_control87(_PC_53, _MCW_PC) or _control87(_PC_24, _MCW_PC) will do the trick. Those set the precision to double and single respectively with MSVC. You might want to use _controlfp_s(...), as that allows you to retrieve the current control word explicitly after setting it.

MSN
A: 

As others have noted, you can deal with this by setting the x87 control word to limit floating point precision. However, a better way would be to get MSVC to generate SSE/SSE2 code for the floating-point operations; I'm surprised that it doesn't do that by default in this day and age, given the performance advantages (and the fact that it prevents one from running into annoying bugs like what you're seeing), but there's no accounting for MSVC's idiosyncrasies.

Ranting about MSVC aside, I believe that the /arch:SSE2 flag will cause MSVC to use SSE and SSE2 instructions for single- and double-precision arithmetic, which should resolve the issue.

Stephen Canon
The whole point of x87's extended precision arithmetic is to avoid having to resort to these ridiculous libraries for matrix operations in the first place. Who would want lower precision to be the *default*?
Gabe
@gabe: The `x87` doesn't deliver nearly enough accuracy to do exact arithmetic, which is what these geometric primitives provide. In cases like this, all it does is break algorithms that behave properly on *every other architecture*. It also introduces all sorts of hard-to-predict bugs wherein numerical results are affected by semantically unrelated computations. There are definite benefits to `x87` extended arithmetic, but not so many that it should be used without any critical consideration of the alternatives.
Stephen Canon
Wow. Are you also against fused multiply-add operations? Remember, x87 was the first implementation of IEEE 754, and almost certainly the most popular. Considering that Intel's Itanium and i960, and Motorola's 68881 and 88110 all have extended precision arithmetic, it's hardly the only one.
Gabe
@gabe: Of course not. I'm not opposed to extended precision, either. What I am against is it being blindly employed by compilers as the default evaluation mode, even when the user hasn't asked for it. This is a constant source of bugs and puzzles for inexperienced programmers. The cases where a naive algorithm is saved by the compiler inserting extended precision computations behind the programmers back, by contrast, are few and far between. Having extended precision available is great boon to numerical computing; having it be the default is much harder to justify.
Stephen Canon