🚀 go-pugleaf

In article <730@castor.linkoping.telesoft.se> ath@linkoping.telesoft.se (Anders Thulin) writes:
>In article <8904@sail.LABS.TEK.COM> toma@sail.LABS.TEK.COM (Tom Almy) writes:
>
>>Case 1: { double x=1e200; printf("%g",x*x); }
>>(With some compilers, the 80x87 has to have the overflow trap masked off).
>>Microsoft C (V6.00A): prints +inf	(correct!)
>>Microway NDP C-386 (V1.4e): prints -*inf** (wrong sign!?!)
>>Metaware High C DOS 386 (V1.62): prints infinity (correct!)
>>Turbo C (C++ V1.0): hangs, requiring "three fingered salute".
>>Zortech C (V2.18): prints 1.797693e+308

>Why is 'infinity' the correct answer? I don't think ANSI C says
>anything about that, so the Zortech answer may be 'as correct' as the
>Microsoft or Metware.

In every case IEEE floating point is used. The floating point co-processor
generates the result "+inf". The Zortech runtime doesn't recognize the
special value, but instead prints the largest float. "+inf" is more correct
because that is the internally represented value, and is also indicative
that overflow has occured. It is interesting to note that only the ZOrtech
compiler does not mask overflow by default -- with the other compilers
(which print "inf") you have to mask overflow to get the infinity result
since they would otherwise abort with a fp overflow trap.

>>Case 2: { double x=1e50; x = sin(x); printf("%g", x);}
>>( matherr() function defined where available )
>>Microsoft: sine function causes error "Total loss of significance" (correct!)
>>Microway: crashes, producing register dump, executing sine function.
>>Metaware: with inline 80387 code, 1e50; with fp library, NaN (ok.)
>>Turbo C: sine function causes error "Domain" (wrong error)
>>Zortech C: prints garbage answer.

>A suggestion:

>In an ANSI C environment, you must clear errno before the invocation
>of sin, and test it afterwards to detect any errors. As I don't see
>it in your code, I suspect you didn't use it.

Microsoft, Turbo, and Zortech provide matherr() functions which are supposed
to trap the errors (in fact all but Zortech did). Neither Metaware nor
Zortech set errno. I was able to get Zortech to indicate an error by
telling the run time that no floating point was available -- it gives the
error when the emulator is used! But that doesn't help performance.

An investigation of this problem showed that the library implementers
did not RTFM! The sine function (and some others) leave the argument 
untouched when out of range, but set a flag indicating failed reduction.
These compilers just fail to check the flag.

>Naturally, 'correctness' must be relative some standard. I assume ANSI C,
>but you may have chosen something different.

IMHO C is not my language of choice for numeric programs because it is
so slopily defined (although I must admit ANSI C is improving). Expecting
floating point errors to be handled might be asking too much, but as I
said "Microsoft C actually does something better."

Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply


-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply