What is the relationship between GPC and IEEE 754 floating point?
THINK and CW (both Mac dialects) allowed e.g.
a := Inf; a := -Inf; a := NaN;
but these are rejected by GPC as undeclared identifiers.
I can get the same effect by e.g.
a := MaxReal * 2.0; {inf} a := 0.0 / 0.0; {nan}
but this seems like a hack.
Also, the old SANE (Apple's most excellent 754 implementation from way back--I think the guru Kaplan was involved, as he was with the also-most-excellent HP-15c pocket calculator) allowed returning specific numeric codes to allow determining what caused a NaN. I remember writing an arctan2 function and in the case of arctan2(0.0, 0.0), I assigned a returm value of something like NaN(85), which was somehow a NaN even though the construct looks like a function. I _think_ I could then query that particular NaN to get a clue about where it arose. I lost this when porting to CW, however.
Anyway, just wondering.
Jerry
lanceboyle@qwest.net wrote:
What is the relationship between GPC and IEEE 754 floating point?
Platform dependent, see http://www.gnu-pascal.de/crystal/gpc/en/thread10316.html.
THINK and CW (both Mac dialects) allowed e.g.
a := Inf; a := -Inf; a := NaN;
but these are rejected by GPC as undeclared identifiers.
You can use the nan from fp.pas in the Mac OS X Pascal Interfaces
{ * nan() * * Availability: * Non-Carbon CFM: in MathLib 1.0 and later * CarbonLib: in CarbonLib 1.0 and later * Mac OS X: in version 10.0 and later }
function nan(tagp: ConstCStringPtr): Double; external name 'nan';
or the BSD one (see "man nan" or http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/nan.3.html which looks to be essentially the same.
NAN(3) BSD Library Functions Manual NAN(3)
NAME nan -- generate a quiet NaN
SYNOPSIS #include <math.h>
double nan(const char *tagp);
long double nanl(const char *tagp);
float nanf(const char *tagp);
The gcc compiler does have Inf and NaN, see e.g. the compiler sources gcc-42/gcc-4.2-20060408/gcc/testsuite/gcc.c-torture/execute/ieee, builtin-nan-1.c, inf-1.c and inf-2.c
double n1 = __builtin_nan("0x1"); double n2 = __builtin_nan("0X1");
float fi = __builtin_inff(); double di = __builtin_inf(); long double li = __builtin_infl();
float fh = __builtin_huge_valf(); double dh = __builtin_huge_val(); long double lh = __builtin_huge_vall();
I believe you can't use gcc builtins directly from gpc, except by linking in a few lines of C.
I can get the same effect by e.g.
a := MaxReal * 2.0; {inf} a := 0.0 / 0.0; {nan}
but this seems like a hack.
Also, the old SANE (Apple's most excellent 754 implementation from way back--I think the guru Kaplan was involved, as he was with the also-most-excellent HP-15c pocket calculator) allowed returning specific numeric codes to allow determining what caused a NaN. I remember writing an arctan2 function and in the case of arctan2(0.0, 0.0), I assigned a returm value of something like NaN(85), which was somehow a NaN even though the construct looks like a function. I _think_ I could then query that particular NaN to get a clue about where it arose. I lost this when porting to CW, however.
Yes, he wrote an amusing foreword for the Apple Numerics Manual, Second Edition (Addison Wesley 1988).
Regards,
Adriaan van Os
Adriaan van Os wrote:
lanceboyle@qwest.net wrote:
What is the relationship between GPC and IEEE 754 floating point?
Platform dependent, see http://www.gnu-pascal.de/crystal/gpc/en/thread10316.html.
THINK and CW (both Mac dialects) allowed e.g.
a := Inf; a := -Inf; a := NaN;
but these are rejected by GPC as undeclared identifiers.
<snip>
The gcc compiler does have Inf and NaN, see e.g. the compiler sources gcc-42/gcc-4.2-20060408/gcc/testsuite/gcc.c-torture/execute/ieee, builtin-nan-1.c, inf-1.c and inf-2.c
double n1 = __builtin_nan("0x1"); double n2 = __builtin_nan("0X1");
float fi = __builtin_inff(); double di = __builtin_inf(); long double li = __builtin_infl();
float fh = __builtin_huge_valf(); double dh = __builtin_huge_val(); long double lh = __builtin_huge_vall();
I believe you can't use gcc builtins directly from gpc, except by linking in a few lines of C.
AFAICS those builtins appeared in gcc-3.3.x (I could not find __builtin_nan in earlier backends). I do not know what they will do on non-IEEE hardware (fortunately such hardware is getting rare). With some effort we can add them to GPC as predefined routines (Inf probably as a constant).