[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integer residue-classes

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.



Mike Sperber wrote:
> I have two purely informational questions at this point:
> 
> - Is there any particular reason for the naming---i.e. why DIV and QUO
>   are named DIV and QUO and not QUO and DIV?  Do these go back to some
>   convention?

Not so far as I know.  Egner et al used DIV and MOD, and
SRFI 77 just copied that paper.  I chose QUO and REM just
to have different names that parallel DIV and MOD.

> - Are you suggesting replacing QUOTIENT/REMAINDER/MODULO by
>   DIV/MOD/QUO/REM or merely adding them?

I favor replacing QUOTIENT/REMAINDER/MODULO, or at least
banishing them to some library of deprecated R5RS procedures.

Some history:  We got these definitions wrong early on.
As Brad pointed out, I misunderstood the R*RS specification
of MODULO, implemented it incorrectly in MacScheme, and
didn't recognize REMAINDER's problems until 1996.  At that
time, Alan Bawden lamented the inconsistency of QUOTIENT
with MODULO, and expressed his desire for an analogue of
QUOTIENT consistent with MODULO.

Egner et al raised these issues in their 2004 paper, and
proposed DIV and MOD, which went into the current draft of
SRFI 77.

Apart from rationale, the only objections that have so far
been raised to DIV and MOD are
1.  DIV and MOD are defined when zero is the second argument,
2.  the arbitrary dependence upon the sign of the second
    argument, and
3.  they don't meet programmer's expectations as expressed
    by Bear.

Defining the second pair of procedures gets rid of issues
2 and 3.

Will