neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) (04/23/91)
I've discovered a compiler bug in ORCA/C v1.2. The compiler does not
compile extended precision constants in source code properly. It
generates double precision numbers, then converts them to extended for
insertion into the code. Worse, extended precision arrays seem to fill
with nonsense if defined by constants in the source code, ie:
extended arr[2] = {1.234567890123456789,9.876543210987654321};
The 'L' flag doesn't help, and the manual mentions that ORCA/C
ignores that flag anyway.
Other things which don't work:
#define M_PI 3.1415926535897932385
used in something like myval = M_PI; gives wrong results.
The solution: the stdlib function "strtod" does work properly, so
here's an inelegant solution:
#define M_PI strtod("3.141592653589792385",NULL);
myval = M_PI;
Similar things can be done for initializing arrays. You initialize a
string array, and then your program has to take time to convert those
strings into extended values.
--
Christopher Neufeld....Just a graduate student | Flash: morning star seen
neufeld@aurora.physics.utoronto.ca Ad astra! | in evening! Baffled
cneufeld@{pnet91,pro-cco}.cts.com | astronomers: "could mean
"Don't edit reality for the sake of simplicity" | second coming of Elvis!"