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

*To*: common-lisp@SU-AI.ARPA*Subject*: (typep 3 'complex) => t*From*: Rob MacLachlan <RAM@C.CS.CMU.EDU>*Date*: Sun, 23 Nov 1986 19:36:00 -0000

There is a bit of type sysem lossage that I noticed lately which is unrelated to the TYPE-OF discussion. My realization is that RATIONAL is a subtype of (COMPLEX NUMBER), since according to p47, "...this type encompasses those complex numbers that can result from giving numbers of the specified type to the function COMPLEX." Of course, (COMPLEX 3 0) => 3. This interpretation depends on the meaning of the phrase "complex numbers" in the above passage. This interperetation does not hold if "complex number" in the above passage means a number where (NOT (EQL (IMAGPART number) 0)). Due to the rule for complex canonicalization, it makes no sense to require the non-0 imagpart, since it makes the declaration useless for complex numbers with rational components. It seems that there is an analogy between COMPLEX and RATIONAL due to the similarity of the complex and rational canonicalization rules. 3 is a rational, since a rational can be canonicalized to an integer. Similarly, 3 is a complex since a complex can be canonicalized to an integer. The real problem is that there is no type which is to COMPLEX as RATIO is to RATIONAL, i.e. a type that represents complex numbers that have not been canonicalized. If my intepretation is correct, then the COMPLEX type with no component type specified is effectively equivalent to (AND NUMBER (NOT FLOAT)). This makes the COMPLEXP function fairly useless if it continues to be equivalent to (TYPEP ... 'COMPLEX). There is some mumbling about "may be different for declaration and discrimination" in the definition of the COMPLEX type specifier, but close reading suggests that this is irrelevant to the issue at hand, since it is really attempting to say that COMPLEX types are similar to ARRAY types in that the implementation has freedom in choosing component type specializations. Comparison with the similar hemming and hawing in the ARRAY definition supports this conclusion. Rob

- Prev by Date:
**GET-SETF-METHOD** - Next by Date:
**Re: (typep 3 'complex) => t** - Previous by thread:
**Macrolet and setf** - Next by thread:
**Re: (typep 3 'complex) => t** - Index(es):