🚀 go-pugleaf

Brooke Paul Anderson (brooke@cco.caltech.edu) wrote:
: The problem is that, if your program has generated a NaN or an Inf,
: something is definitely wrong, and the calculation needs to be halted.
: To me, having to sprinkle tests all over to check for these conditions
: is just as inconvenient and annoying as trying to catch bad pointers
: in an OS that doesn't have protected memory (like in DOS, where pointers
: can stomp all over the OS until the whole machine locks up).

what you need is a full implementation of IEEE-754 where the production
of a NaN or Inf (under most circumstances) can cause a trap to be taken
which could either halt you program or go to a special bit of
fix up code.

IEEE-754 uses NaNs and Infs to allow for calculation to procede as far
as possible while tracking the propogation of "dodgy" values. However,
the standard is design around the idea that you should be able to trap
out of your program in these circumstances.

However, sticking in all the support for traps etc can be a bit
excessive if you believe that the vast majority of users won't
need it, hence many people only implement the arithmetic core
or IEEE-754.

having traps, though, allows all sorts of interesting concepts to
arise like "quiet" and "noisy" NaNs!


--
--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 625
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
                1992: celebrate the quincentenary of columbus getting lost