Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri 10 Mar 89 14:43:58-PST
    From: Kim A. Barrett <IIM@ECLA.USC.EDU>

    Many (perhaps almost all) of these could potentially signal STORAGE-CONDITION.
    However, as a general rule I don't think we should document that possibility.

Right. STORAGE-CONDITION is already described as not being an error
exactly because it addresses an implementation failure rather than a
semantic error. I think this distinction is important. I think we should
deal with this by suggesting to Kathy that she mention somewhere that
for this reason, no one should interpret any of the Conditions lists
in the function descriptions as necessarily complete.  The whole point
of the condition system is to provide flexibility in this regard. If we
were being exhaustive, we might as well return integer error codes as
the n+1st value.

    ASH: I can't think of any reason for ASH to signal an ARITHMETIC-ERROR.

[Heh,heh... Yeah, normally neither could I. I remember in Macsyma I ran
into some implementations where ASH wasn't implemented correctly (due to bugs)
and I had to define it in terms of EXPT for some situations.]

Ok, I'll remove this. It can still signal it of course. We just won't
waste users' time with expecting it.

    DECF: might signal SYNTAX-ERROR?  Perhaps this should be PROGRAM-ERROR?

Sorry, you're right.

    GCD: I can't think of any reason for GCD to signal an ARITHMETIC-ERROR.

Ok.

    INCF: might signal SYNTAX-ERROR?  Perhaps this should be PROGRAM-ERROR?

Right.

    LCM: I can't think of any reason for LCM to signal an ARITHMETIC-ERROR.

Ok.

    MOD: the second argument is required, so drop the "is supplied and" from the
    DIVISION-BY-ZERO case.

Ok. Around here, we call that a control-Y error.

    REM: the second argument is required, so drop the "is supplied and" from the
    DIVISION-BY-ZERO case.

Ok.

    SCALE-FLOAT: might signal ARITHMETIC-ERROR (fp over/underflow).

Ok.

    The possibility of ARITHMETIC-ERROR being signaled in the following functions
    may depend on what kind of error should be associated with operations on fp
    NaN's, infinities, and such.

NaN were specifically what I was thinking of. The main objection I was worried
about was whether anyone thought that that wasn't the right error (e.g., that 
TYPE-ERROR was more appropriate).

      MAX, MIN, SQRT, /=, <, <=, =, >, >=, RATIONAL, RATIONALIZE

    Because of CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE, none of MAX, MIN, /=,
    <, <=, =, >, and >= will signal fp over/underflow, and reduce to the question
    of what ARITHMETIC-ERRORs are signaled by RATIONAL.

It's funny I started with numbers because numbers are not really my
strong point.  Can you (or someone) please translate this into a
specific suggestion? Thanks.