X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Trace-PostClient-IP: 68.147.131.211
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT Invalid>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Cross Platform Incompatabilites? - code fragments
Organization: Systematic Software
Message-ID: <fh3d40hecscols693jgahi3dnic7a6l56l@4ax.com>
References: <3 DOT 0 DOT 1 DOT 16 DOT 20040216231142 DOT 38e7a7cc AT earthlink DOT net> <3 DOT 0 DOT 1 DOT 16 DOT 20040302202549 DOT 3957c428 AT earthlink DOT net> <c24cn4$lk$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 75
Date: Thu, 04 Mar 2004 02:13:25 GMT
NNTP-Posting-Host: 24.71.223.147
X-Complaints-To: abuse AT shaw DOT ca
X-Trace: pd7tw1no 1078366405 24.71.223.147 (Wed, 03 Mar 2004 19:13:25 MST)
NNTP-Posting-Date: Wed, 03 Mar 2004 19:13:25 MST
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On 3 Mar 2004 10:40:36 GMT in comp.os.msdos.djgpp, Hans-Bernhard
Broeker <broeker AT physik DOT rwth-aachen DOT de> wrote:

>Ethan Rosenberg <ethros AT earthlink DOT net> wrote:
>
>[...]
>>     HBR/long double
>>               min           delta          etot
>>               0.45     135.183805  650175.488059
>>               3.15      -3.106527    1270.050546
>
>>     SARAH/long double
>>                 min             delta          etot
>>               0.45     135.183805  650175.488059
>>               3.15      -3.106527    1270.050546
>
>Note that 'long double' is the only type in which both machines return
>the same result?  I'm not completely convinced yet, but this seems
>like it supports my assumptions: FPU register precision is part of
>your problem.  Long double has the same precision as the FPU
>registers, so changes to the FPU default precision shouldn't affect
>them as they do the other floating-point types.
>
>> The problem with the long double calculations, I think, is that the sqrt
>> function assumes double for input.
>
>That shouldn't too bad a problem.  Doesn't DJGPP's full-scale libm
>come with a sqrtl() for long double arguments?  Or was that only the
>case for the full CEPHES lib?
>
>> The FFT routine which I have not modified at all is:
>
>> Recognizing the the problem may be from overflow of the float, certain
>> changes were made in the program:
>
>Overflow would have manifested itself in different ways.  After you
>turned on SIGFPE generation, you would have got right-out crashes of
>the program.  Otherwise, you would be seeing Inf and NaN among your
>outputs.
>
>This really looks more like catastrophic loss of precision.  
>
>Did you try -mfloat-store yet?
>
>
>>     qsort(temp3, jj, sizeof(FLOAT), mycomp);
>>     for(i = 0; i < jj; i++)
>>         sum += 2*temp3[i];
>
>That's not quite how the "sum smallest items first" trick I outlined is
>supposed to be used.
>
>You're supposed to have a loop like this:
>
>     while(number of terms > 1)
>       find two smallest elements (by magnitude) of the list, i and k:
>       remove i and k from the list
>       put their sum, i+k into it instead
>
>The idea is to avoid summing any two items of vastly different
>magnitudes, if that's at all possible.  

Treating the array as a heap would allow this to be done efficiently. 
See Knuth, Sedgewick, or any algorithms book, for details on heaps. 
Heap creation replaces the qsort. Keeping the smallest items at the
end of the array/heap simplifies reheaping and reduces the work
required after removing the two smallest items and inserting their
sum. Ensure the comparison operations are the right way round to keep
the array/heap in largest first order. 

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian DOT Inglis AT CSi DOT com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply