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

*To*: IIM%ECLA.USC.EDU@AI.AI.MIT.EDU*Subject*: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1*From*: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>*Date*: Fri, 10 Mar 89 18:26 EST*Cc*: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU*In-reply-to*: <12476991984.30.IIM@ECLA.USC.EDU>

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.

**References**:**Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1***From:*Kim A. Barrett <IIM@ECLA.USC.EDU>

- Prev by Date:
**CL-Cleanup-mailer** - Next by Date:
**(reply to message)** - Previous by thread:
**Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1** - Next by thread:
**(new) Issue DESCRIBE-UNDERSPECIFIED** - Index(es):