Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site ism780c.UUCP
Path: utzoo!watmath!clyde!cbosgd!ukma!psuvm.bitnet!psuvax1!burdvax!sdcrdcf!ism780c!tim
From: tim@ism780c.UUCP (Tim Smith)
Newsgroups: net.arch
Subject: Re: Right shift vs. divide
Message-ID: <239@ism780c.UUCP>
Date: Tue, 14-Jan-86 17:27:42 EST
Article-I.D.: ism780c.239
Posted: Tue Jan 14 17:27:42 1986
Date-Received: Fri, 17-Jan-86 01:36:35 EST
References: <124000005@ima.UUCP> <4772@alice.UUCP> <996@mmintl.UUCP>
Reply-To: tim@ism780c.UUCP (Tim Smith)
Organization: Interactive Systems Corp., Santa Monica, CA
Lines: 23

>It does seem, however, that an arithmetic right shift which *is* equivalent
>to a division would be more useful, however.  There are relatively few cases
>where one wish to round towards minus infinity, and those cases are not
>especially likely to be divisions by powers of two.

There are two things that seem reasonable to compute for a/b.
(1) int(a/b), and (2) sign(a/b)*int(abs(a)/abs(b)).  When b = 2,
arithmetic right shift computes (1).  Division computes (2).
[This is assuming a "normal" computer, whatever that means!]
Because division is (2), some properties one would normally
expect division to have do not hold.  For example, if a,b, and n
are integers, b != 0, I would expect (a + bn) / b to be the same
as a/b + n.  This would hold if division was (1), but not when it
is (2).

The only reason I have heard for using (2) is that -(a/b) = (-a)/b.
This is a nice property, but I think that having (a+bn)/b = a/b + n,
and having the mod function have a range of b instead of 2b-1 are
more important.  Hence, it is division that should be changed to
agree with shift.

--
Tim Smith       sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim