Xref: utzoo comp.theory:371 comp.misc:8285 comp.lang.misc:4218
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.theory,comp.misc,comp.lang.misc
Subject: Re: Modulus (Re: hashing function for strings)
Message-ID: <12115@goofy.megatest.UUCP>
Date: 22 Feb 90 23:47:47 GMT
References: <981@m1.cs.man.ac.uk>
Organization: Megatest Corporation, San Jose, Ca
Lines: 37

From article <981@m1.cs.man.ac.uk>, by chl@cs.man.ac.uk (Charles Lindsey):
...
> 
> I tried to get the PASCAL standardizers to get it right, but although they
> admitted the merit of my case, they got cold feet because, in the meantime,
> all hardware was now being built the way languages were now defining it.
> 

I too haggled with the Pascal standardizers, but I was under the impression
that we WON. I just now went back to an old draft copy, and to
_Standard_Pascal_ by Doug Cooper, and I discover that dammit, they
only did MOD right, not DIV.

@#$%^&!!!

MOD is stipulated to be correct, but -- get this! -- DIV is stipulated
to be wrong! You can't even do it right if you want to. Not unless you
want to (shudder) violate the standard. Oooooo. They say,

    abs(i) - abs(j) < abs((i div j)*j) <= abs(i)

There's them damnable abses again. What the **** has abs got to do with
anything? Abses in definitions translate into tests for > 0 at runtime.
Who needs the agravation?

And then they confess, 'NOTE: Only for i >=0 and j > 0 does the relation
(i div j) * h + i mod j = i hold.'


    ***

Just now I did a little experimenting. On Sun-3, release 4.3.  In both C
and Pascal, division is correct, but mod is wrong.

In other words, they have it exactly backwards from the ANSI Pascal
Standard. Not right mathematically. Not right according  to the standard.
You got to wonder, how come?