From: Hans-Bernhard Broeker 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: 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 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.