Mail Archives: djgpp/2004/02/19/15:15:46
On Mon, 16 Feb 2004 23:11:42 -0500 in comp.os.msdos.djgpp, Ethan
Rosenberg <ethros AT earthlink DOT net> wrote:
>Dear Listmembers -
>
>
>MUCH THANKS IN ADVANCE FOR ANY AVICE WHICH WILL BE GIVEN.
>
>>Does that mean that the modified program produces _exactly_ the same
>>results as before, on each platform? Or do you see any changes in the
>>results with the _CRT0_FLAG_FILL_DEADBEEF bit set?
>
>No change wantsoever!!!
>
>
>The following are code FRAGMENTS from the program. My feelings are that
>the error is in the integration routine. etot is defined as FLOAT.
>
>I have extracted these fragments for a program of approx. 3000 lines of
>code. I hope I am not burdening you with too much.
In general, most programmers should not use 32 bit float for
arithmetic, unless they do careful analysis and coding of algorithms
to avoid the *SEVERE* loss of precision that can occur in just a
single operation with unfortunate values.
A simple example of this would be when you do accumulation in float:
you need to sort and add up the numbers from smallest to largest
absolute value to avoid losing the effect of small values totally.
If you can enable precision loss reporting in your program, with a
compiler switch or library function call, you may find that's
occurring all over the place on the problem platform.
Some compilers (many if you set the right options) may effectively
ignore the float definition, may carry out all the calculations in
double or long double, and particularly at high optimization levels,
may keep the values in floating point registers, and never truncate
the value to float precision, except possibly during output
conversion.
OTOH particularly if you compile with debugging enabled (-g), all
results may be stored and reloaded from memory locations on every
operation, resulting in bit loss on every operation, especially on
register poor platforms like i86 systems.
You can also often force this if you can set FP precision control to
force 32 bit float results on every operation, using a compiler switch
or library function call.
Some libraries and OSes have suffered from not properly saving and/or
restoring the complete FP register status: around calls that are known
to trash the registers; from being unable to detect that a program is
using FP; or just buggy code.
--
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
- Raw text -