DIV and MOD ( was: Something IBM did right )

[Richard A. O'Keefe]

In article <328 at sdti.UUCP> turner at sdti.UUCP (0006-Prescott K. Turner, Jr.) writes:
>In article <643 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>>there are at least three sensible definitions of integer division/remainder,
>>all of which agree which divisor and dividend are positive.
>To call all three definitions "sensible" is inviting a war.

Not at all:  to agree that what someone else wants to do is sensible
is usually a rather irenic thing to do.

>To me the arguments Dave Jones presented make sense and the
>counterarguments do not.

I claim that each of the "floor", "trunc", and "ceil" definitions is
sensible and useful.  I have realistic (got to conceal those proprietary
details) examples showing that each of them has uses.  Please don't
think that I ever suggested that any of the definitions other than your
favourite should be used _instead_.  I repeat that I have uses for all
three.  (And if there are other sensible definitions around, I can
probably find uses for them too.)

Dave Jones' arguments, and arguments I have received by E-mail from
someone else, boil down to
	"_I_ haven't had the wit to see a use for it, so it's _baaaad_."

>Actually, I do accept as a counterargument that most programming languages
>require the definition in which the quotient is truncated towards 0. re
>But it's a shame that they went down that path.

Well, programming language designers mostly copy other languages.  And way
back there we find Fortran.  And Fortran's designers either ruled the way
they did because they were convinced that it was the most useful definition
for Fortran's then envisaged applications, or because it suited the
hardware well, and in the latter case the designers of the 704 or whatever
presumably had what _they_ thought were good reasons for their choice.

"Most programming languages require definition X" is some sort of
argument for making definition X available, but it is _not_ a good argument
for having X be the _only_ definition available.

I don't give a Continental which particular definition a language designer
choses to dignify with infix notation of its own, as long as when I have a
use for one of the others it is available at least as efficiently as any-
thing I could have coded myself.

It is worth noting that on a lot of present-day UNIX boxes (68010s,
68020s, VAXen, many but not all RISCs) that integer division is so slow
anyway that providing the hardware version (whatever that is) as "/"
and "%" and supporting the other three definitions with a few conditional
branches and other in-line code would be a perfectly reasonable thing to do.