Re: problem with output of the program on different OS

Bart <bc@[EMAIL PROTECTED]
> writes:

> On May 13, 1:39 am, Ben Bacarisse <ben.use...@[EMAIL PROTECTED]
> wrote:
>> Bart <b...@[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.
>
> One specific initialisation problem was mentioned upthread; there
> seemed to be others, but not directly affecting the Pelles C result I
> was tracing.

I can't see how leaving parts of a complex number (that is used)
uninitialised could not be affecting what you were tracing.  Maybe I
am missing what you are tracing, but the program seems use
uninitialised data, specifically the real part of the E_scattered
member and the imaginary part of E_incident member of the radar
structure (as posted /three days ago/[1]).

Now, the OP may have corrected that, and you may be using that
corrected source, but there was no "OK, fixed" message from him so I
suspect not.  It is also possible that my reasoning is wrong, but then
I'd expect a message saying "it's OK, I set it here" or "I never use
the real part of E_scattered").

>> > 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.
>
> I would expect the answer to be wrong by one bit or so. My gcc/3.4.5
> gives -5e-16.

Mine is 4.2.3.  The point is I think 0 is a correct and permitted
answer.  It is not at all strange (to me).

This has got so surreal that I have just downloaded Pelles C.  If I
leave the bug in I get this output:

Es: inf Ei: 1.112194e-04 RCS: inf

If I correct it by setting the missing parts of the complex numbers to
0 I get this:

Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

which is exactly what gcc 4.2.3 and lcc-win32 give me.  It seems to be
a bug of the most ordinary nature.

> I was intrigued in why 1 compiler out of 4 gave a different result,
> and tracked it down to this behaviour

I am far from sure that you have.  Does the version you traced have
uninitialised data and does the problem remain when you add the two
extra zero initialisations?  If, so I will agree it looks odd, but so
far it seems to be a common all-garden bug in the code.

[1] Message-ID: <87wsm3eeqh.fsf@[EMAIL PROTECTED]
>

-- 
Ben.