Xref: news2.mv.net comp.os.msdos.djgpp:1302 From: pausch AT electra DOT saaf DOT se (Paul Schlyter) Newsgroups: comp.os.msdos.djgpp Subject: Re: acos(2.0) and other errors Date: 21 Feb 1996 11:16:32 +0100 Organization: Svensk Amat|rAstronomisk F|rening Lines: 32 Message-ID: <4gere0$ngn@electra.saaf.se> References: <271654446E1 AT fs2 DOT mt DOT umist DOT ac DOT uk> NNTP-Posting-Host: electra.saaf.se To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp In article <271654446E1 AT fs2 DOT mt DOT umist DOT ac DOT uk>, A.Appleyard wrote: > I am sick of program runs being hostage to one stray floating point overflow. > What I want is one or both of (1) Being able to tell the PC to carry on > regardless if overflow happens, (2) Being able to tell the PC to go to such > and such an address if overflow happens. And what do you intend to do in (2) if you get there (except to terminate the program)? If you're using a coprocessor (80x87, or a 486DX or Pentium), the coprocessor can be programmed for this. You can tell the coprocessor to not generate interrupts when f.p. overflows etc happens, and instead return some approproate value. Division by zero will return "infinite", dividing zero by zero, or multiplying infinite by zero, will return "indefinite", and attempting things like the sqrt or log of a negative number, or asin/acos of numbers above +1.0 or below -1.0, will return "not-a-number". The coprocessor can continue doing operations on these special representations -- for instance dividing by "infinite" will produce zero, most operations on "indefinite" will produce another "indefinite", and any operation on "not-a-number" will produce another "not-a-number". For details, check Intel's, or someone else's, documentation for the 80x87 coprocessor. -- ---------------------------------------------------------------- Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) Grev Turegatan 40, S-114 38 Stockholm, SWEDEN e-mail: pausch AT saaf DOT se psr AT home DOT ausys DOT se