From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Win2000 DJGPP Problem Report Calculations = NaN
Date:	22 Nov 2001 17:18:46 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	45
Message-ID:	<9tjc1m$72h$1@nets3.rz.RWTH-Aachen.DE>
References:	<Gn7LD6 DOT A0D AT leeds DOT ac DOT uk>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 1006449526 7249 137.226.32.75 (22 Nov 2001 17:18:46 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	22 Nov 2001 17:18:46 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Graham Rangel-Sharp <een7gdr AT leeds DOT ac DOT uk> wrote:
> at university. I know DJGPP is not fully functioning in win2000 but im not
> allowed to install anything else.

For the particular problem at hand, I guess the Cygwin port of GNU
utilities would be better. At least until a version of DJGPP suitable
for Win2K becomes widely available.

> The problem is that im having to compile software written about 5 years ago
> on a sun machine. I can get it to compile and run on win2000 but after some
> time into the program, some of the calcutlations come out with answers of
> NaN. 

Getting a NaN out of a program is not an indication of a strong bug, in and
of itself.  It merely means that the program's iteration reached areas where
undefined results occur. I.e. it may have run into sqrt(negative) or something
like that.

Different computing platforms differ (and always have) in the way they
they react to such situations.  Often, even compiler options or
runtime library calls influence the behaviour further.  On a DEC Alpha
in default mode, e.g., the whole program would have been killed by the
operating system the first time a NaN-generating floating point
operation occured.

In DJGPP and Linux systems, the default mode is to run in non-stop
mode, which runs the risk of getting NaN results instead.

> The software runs a simulation of a transister and incorporates many
> iterations, they seem to start of okay, giving sensible answers but about
> 20-30 mins into the running the strange results appear. I dont think its a
> problem with the code since it works fine on a friends linux machine.

It may not seem like a problem with the code, but that's by no way a
guarantee.  Subtle differences in the accuracy of hardware FPU
operations and/or math library functions can cause such differences,
too.

Just to settle one possible origin of the problem: is that a rather
new machine (a 1.7 GHz P4 would be -- but *how* new)?  If so, this
might be a sign of hardware flakiness.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -