X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Sun, 08 Feb 2004 20:47:16 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Ethan Rosenberg <ethros AT earthlink DOT net>
Message-Id: <2719-Sun08Feb2004204715+0200-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <3.0.1.16.20040208120922.428f5b8a@earthlink.net> (message from
	Ethan Rosenberg on Sun, 08 Feb 2004 12:09:22 -0500)
Subject: Re: Cross Platform Incompatabilites?
References: <3 DOT 0 DOT 1 DOT 16 DOT 20040204105918 DOT 33f75924 AT earthlink DOT net>  <3 DOT 0 DOT 1 DOT 16 DOT 20040204105918 DOT 33f75924 AT earthlink DOT net> <3 DOT 0 DOT 1 DOT 16 DOT 20040208120922 DOT 428f5b8a AT earthlink DOT net>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sun, 08 Feb 2004 12:09:22 -0500
> From: Ethan Rosenberg <ethros AT earthlink DOT net>
> 
> The program is calculating a Fast Fourier Transform (FFT).  I have checked
> it on test data, and know it works.  I have also compile with the -Wall
> flag, to see if there was something subtle there.  No warnings of
> incompatiblities were found.
> 
> The differences are *possibly* generated in a routine which calculates the
> integral under the curve of FFT*FFT*2, using the trapezoidal rule.  The
> error appears in only one integration of a calculation of probably a
> hundred integrations.  The integration routine does not seem to have errors.  

So you are saying that the results of the FFT from the same input data
are different on the two platforms, right?  If so, what kind of
differences, in quantitative terms, are we talking about?  Are the
differences minor, like a small fraction of the results, or major,
like if they differ by a large factor?

What kind of hardware do you have on both machines?  What is the CPU
on each one of them, for example?  Any chance one of them uses an FP
emulator?

> This is the first time I have encountered any inconsistencies, in hundreds
> of calculations.  The files I am using are VERY big.  The FFT vector
> contains 16k complex variables, composed of two float type variables.  I
> *might* be having addressing problems.

Bad addresses might be one possible cause, yes.  You may wish to try
to run the program on the pure DOS configuration under YAMD (which can
be downloaded from the DJGPP FTP site), and see if it catches any such
bugs.

Another possibility could be some FP exception that is generated by
the program on one of the platforms.  The DJGPP library docs describe
a function _control87 that can be used to set the x87 FPU so that it
triggers SIGFPE whenever a bad float result is produced.  One idea to
debug this is to enable FP exceptions like that and see if any SIGFPEs
happen on one of the platforms.  If you do get SIGFPEs, it almost
surely means some kind of data-dependent bug.

> INSTALL=C:\DOS\SHARE.EXE /l:500 /f:5100

I'd delete this line (not that I think it has anything to do with
your problem): SHARE is wicked.

> DEVICEHIGH /L:2,41104 =C:\BPCDROM\BPCDDRV.SYS /D:BPCDDRV$  /D:BPCDDRV$

What does this driver do?

> DEVICEHIGH /L:2,12048 =C:\DOS\SETVER.EXE

SETVER is wicked, don't use it.  Again, I don't think it can explain
your problem.