mod, div (was Re: [mercury-users] The Mercury random module

[Peter Moulder]

Fergus Henderson <fjh at cs.mu.OZ.AU> writes:

> The semantics of `mod' have been tightened up (it always
> returns a non-negative number), and there are new functions `div' and
> `rem'.  With this change, you can now choose between `//' (round-to-zero)
> and `div' (round-to-minus-infinity).  You call also choose between the
> corresponding remainders: `rem' is remainder with respect to `//', and
> `mod' is remainder with respect to `div'.

I join with the others in warmly welcoming this change.  (See rant below.)

I'd just point out mod should give a negative answer if the second
argument is negative.  (7 divided by -4 is -7/4 which becomes -2 after
rounding towards negative infinity; -2 * -4 is 8, so remainder is -1,
not 3.)


Begin rant (off topic).

I don't know why GNU chose to *guarantee* the wrong behaviour wrt `%'
and `/' in C.  I've often needed `mod' and `div' semantics, but I've
never found a need for `//' and `rem'.

The only reason I can see for GNU choosing `//'/`rem' symantics is so
that integer division has the same symatics as casting a floating
point quotient to an integer.  Can anyone give an example of where
they've needed `//'/`rem' symantics?  If so, would you go so far as to
say that `//'/`rem' is more useful than `div'/`mod'?

The best argument I can see for `//'/`rem' would go ``It is
conceptually; one less thing that the programmer has to worry about.
If these are the symantics that the programmer expects, then we should
provide these, so that fewer user bugs are created because of
ignorance of a minor point in the language spec.''  My counter
argument is that for anyone familiar with how floats and ints are
usually stored (which I'd have thought would be most people who choose
to use C over a higher level language) would expect both the
float->int casting symantics and `div'/`mod' behaviour.  (Certainly I
did before I looked at the specs.)

pjm.