Re: problem with output of the program on different OS

On May 13, 1:39=A0am, Ben Bacarisse <ben.use...@[EMAIL PROTECTED]
> wrote:
> Bart <b...@[EMAIL PROTECTED]
> writes:
> > On May 12, 6:27=A0pm, 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. =A0It seems to me that there is a clear
> and obvious bug in the program (unless you are now working from a
> newer fixed version). =A0Since 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'. =A0This is quite sufficient to explain what you see.
> You don't need to blame a compiler.

One specific initialisation problem was mentioned upthread; there
seemed to be others, but not directly affecting the Pelles C result I
was tracing.

>
> > I've narrowed the problem down, it can be illustrated by this code:
>
> > double x=3D-10;
> > double y=3D2.0/3.0;
> > double z;
> > unsigned int a=3D15;
>
> > z=3Dx+a*y;
>
> > printf("%g + %u * %g =3D %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? =A0My gcc does exactly the same. =A0It
> seems entirely correct to me.

I would expect the answer to be wrong by one bit or so. My gcc/3.4.5
gives -5e-16.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour (it was also more interesting
than what I was supposed to be doing..)

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

Yes the program is unstable if it can give different results depending
on whether one value is just one side of zero or the other. As it is I
wouldn't now trust any of the results to be correct even if many
concur.

This is up to the OP now to fix the problems.

--
Bartc