Re: problem with output of the program on different OS

Bart <bc@[EMAIL PROTECTED]
> writes:

> On May 12, 6:27 pm, pereges <Brol...@[EMAIL PROTECTED]
> wrote:
<snip>
>> maybe you are right but isn't it strange that PellesC is the only
>> compiler giving a result like this. If there was a serious bug in the
>> program, then there would have been atleast one compiler which could
>> have given strange result ?

No, you can't reason like that.  It seems to me that there is a clear
and obvious bug in the program (unless you are now working from a
newer fixed version).  Since I seem to shouting from the sidelines
here let me rephrase it: the automatic variable (radar_detector radar)
seems to be only partially initialised buy the function
'initialize_radar'.  This is quite sufficient to explain what you see.
You don't need to blame a compiler.

> I've narrowed the problem down, it can be illustrated by this code:
>
> double x=-10;
> double y=2.0/3.0;
> double z;
> unsigned int a=15;
>
> z=x+a*y;
>
> printf("%g + %u * %g = %g\n", x, a, y, z);
>
> The result (-10+15*(2/3)) should be inexact, and gives something like
> 1e-15 on most compilers. But Pelles, strangely, gives the exact result
> of 0.0!

What is odd about that?  My gcc does exactly the same.  It
seems entirely correct to me.

Either way, it should not be the explanation.  If the physics of the
program are reasonable (and correct) the results will be roughly the
same.  Only the most ill-conditioned problems will diverge due such
problems.  If this is such a case (and I am pretty sure it is not) the
solution lies not in the compiler that gives z = 1e-15 rather than 0
but rather in a new algorithm that is more stable.

-- 
Ben.