Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!nrl-cmf!cmcl2!rutgers!rochester!PT.CS.CMU.EDU!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.c
Subject: Re: FP math used for int operations
Message-ID: <3899@aw.sei.cmu.edu>
Date: 23 Jan 88 18:39:19 GMT
References: <2335@haddock.ISC.COM> <3337@hall.cray.com>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 27

In article <3337@hall.cray.com> pmk@hall.cray.com (Peter Klausler) writes:

>Our architectures do not possess integer division instructions, so we're
>forced to do generic integer division (i=j/k) via something like:
>
>	i = (int) ((float) j / (float) k)

No you're not: you can write a subroutine to perform integer division,
the way we did on the old PDP-11/20 and MC68000.  It might be slower,
but at least it would give the right answer for (almost) all of the domain.

>In fact, it's even more complicated, since there's no actual floating
>division instruction either, but rather a "reciprocal approximation"
>instruction, which generates a half-precision reciprocal that must then
>be refined with the Newton-Raphson method iteration instruction.

Which means that the division of two exactly represented quantities does
not always yield the mathematically correct exactly representable
quotient.  Maybe you need to write a subroutine for FLOATING division
also, since to any serious numerical programmer that behaviour is
USELESS.

>Moral:	Try to use floats when programming a scientific machine.
>	Your generated code will use them anyway.

Moral: The world is full of junk hardware.  And the more you buy it, the
more they'll build it.