different results on different compiler

A

Alessio

Hi,

There's a way ( or some advice ) to get same results with different
compilers ?
Let me explain better.
I've developped an application ( from a pv-wave source ) that use some
math function (fabs, sqrt,....), I noticed that using different
compiler, results are different.
I think that trouble is the way compilers represent floats in memory.
How can I manage this ?

Thank you.
 
B

Boon

Alessio said:
Is there a way ( or some advice ) to get same results with different
compilers ?
Let me explain better.
I've developed an application ( from a pv-wave source ) that use some
math function (fabs, sqrt, ...), I noticed that using different
compiler, results are different.
I think that trouble is the way compilers represent floats in memory.
How can I manage this ?

What Every Computer Scientist Should Know About Floating-Point Arithmetic
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
J

James Kuyper

Alessio said:
Hi,

There's a way ( or some advice ) to get same results with different
compilers ?
Let me explain better.
I've developped an application ( from a pv-wave source ) that use some
math function (fabs, sqrt,....), I noticed that using different
compiler, results are different.
I think that trouble is the way compilers represent floats in memory.
How can I manage this ?

The only way to absolutely guarantee getting the same results is to
emulate floating point behavior within your own code: create a struct
whose members are integers (and which would presumably be bit-fields)
representing the sign, signifcand, and exponent, and write your own
routines for addition, subtraction, multiplication, etc. Then build
your own variant of the standard library's math functions that work with
this emulated floating point type. This would be a lot easier to do in a
language with operator overloads than it would be in C, but it's still a
lot of hard work. Because all of the actual operations involve integers,
you can ensure that exactly identical results are produced (if you're
careful).

If that seems like far too much trouble, you're right - it is. What you
should be doing is writing your code so that it does not require exactly
identical results. However, while you can't, at any reasonable cost,
eliminate such variations, you can minimize them by using double or even
long double to minimize round-off errors.

If you can afford to restrict the portability of your code, C99 added a
number of new features that allow you to determine things about your
floating point environment that would affect the results:
* __STDC_IEC_559__ should be pre-#defined by the implementation only if
it conforms to IEC/IEEE 60559, a standard that imposes much stricter
requirements on floating point operations than the C standard itself does.
* If the value of FLT_ROUNDS is either 0, 1, 2, or 3, then it tells you
useful information on how rounding is performed. If you don't like the
value of FLT_ROUNDS, you can attempt to change the rounding by calling
fsetround(), but pay attention to the return value: if it's non-zero,
your attempt failed.
* If the value of FLT_EVAL_METHOD is not -1, it tells you something
useful about how intermediate results are handled.

Even implementations that pre#define __STDC_IEC_559__, can be put in the
same rounding mode, and have the same value for FLT_EVAL_METHOD can
still produce different results from the same code, but the variations
should be much smaller than if there are differences in those regards.
 
B

Ben Bacarisse

Alessio said:
There's a way ( or some advice ) to get same results with different
compilers ?
Let me explain better.
I've developped an application ( from a pv-wave source ) that use some
math function (fabs, sqrt,....), I noticed that using different
compiler, results are different.

How different? If your algorithm is a good one and you have written
portable C, the results should vary between machine by an amount that
does not matter to your application.

When the differences are large it is often because there is plain big
in the code or some non-portable assumption being made. More rarely
the algorithm is so ill-conditioned that small errors get magnified to
a size where they swamp the real answer.
I think that trouble is the way compilers represent floats in memory.
How can I manage this ?

People do it all time. Some of the post widely ported code is/was
numerical routines that produce the same answer (but with slightly
different error bounds and so on) on all sorts of floating point
implementations.

To get more help you need to post some code. If the project is small
you can post it all. If it is large, can you find a sub-part that can
be cut down that exhibits the same problem and post that. A complete
single file program is the ideal and will get the largest number of
people to look at it.
 
T

Tim Prince

Alessio said:
Hi,

There's a way ( or some advice ) to get same results with different
compilers ?
Let me explain better.
I've developped an application ( from a pv-wave source ) that use some
math function (fabs, sqrt,....), I noticed that using different
compiler, results are different.
I think that trouble is the way compilers represent floats in memory.
How can I manage this ?

Along with issues mentioned in other replies, you must refer to the
documentation of the various compilers, and choose equivalent compile
flags (perhaps flags to improve language standard conformance). For example,
gcc -O3 -msse2 -funroll-loops --param max-unroll-times=4 yoursource.c
and
icc -ansi-alias -fp-model source yoursource.c
might be comparable, with current versions of those compilers.
As you hinted, making different choices between 80-bit extra precision and
non-extended precision, as well as level of compiler optimization, could
be involved. You could follow up on this on support forum for the
compilers of your choice.
 
A

Alessio

Thank you all.
I realize that some compiler aren't C99 complain and uses double
precision function for single precision type, i.e. fabs instead of
fabsf, sqrt instead of sqrtf.

Alessio ha scritto:
 
J

jameskuyper

Alessio said:
Thank you all.
I realize that some compiler aren't C99 complain...

C Compilers that are not fully conformant with C99 are pretty common.
Most C compilers have a mode where they are fully conformant with C90,
and don't even attempt to support any of the new features in C99.
However, you'll still have discrepancies you'll have to deal with even
if you're comparing two different implementation that fully conform to
C99.
... and uses double
precision function for single precision type, i.e. fabs instead of
fabsf, sqrt instead of sqrtf.

Compilers that would replace a call to fabsf() with a call to fabs(),
or replace sqrtf() with sqrt() are pretty rare; offhand, I doubt that
there are any. There are a great many other issues you need to worry
about that are far more important than that one:

* Rounding mode
* The handling of intermediate results.
* Poor implementations of IEEE 754 == IEC/IEEE 60559.
* Floating point implementations that don't even attempt to conform to
IEEE 754.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top