From: Bruno H. <br...@cl...> - 2004-04-20 19:08:09
|
The type specifier (COMPLEX type) should, according to ANSI CL's description (HyperSpec/Body/syscla_complex.html), only depend on (upgraded-complex-element-type type). * (upgraded-complex-part-type '(eql 0)) RATIONAL * (upgraded-complex-part-type 'rational) RATIONAL Therefore the types (COMPLEX (EQL 0)) and (COMPLEX RATIONAL) should be the same. But TYPEP doesn't work this way: * (typep #c(0 1) '(complex rational)) T * (typep #c(0 1) '(complex (eql 0))) NIL And SUBTYPEP doesn't work this way either: * (subtypep '(complex rational) '(complex (eql 0))) NIL T [Taken from clisp's type.tst] Platform: Linux/x86. SBCL version: 0.8.9 compiled by CMUCL 18e. |
From: Christophe R. <cs...@ca...> - 2004-05-04 11:18:56
|
Bruno Haible <br...@cl...> writes: > The type specifier (COMPLEX type) should, according to ANSI CL's description > (HyperSpec/Body/syscla_complex.html), only depend on > (upgraded-complex-element-type type). > [...] > [Taken from clisp's type.tst] > Platform: Linux/x86. SBCL version: 0.8.9 compiled by CMUCL 18e. Thank you for the report. I believe I've fixed this (properly, this time; those interested in SBCL history may wish to know that the broken behaviour was almost entirely my fault in the first place, and dates back to the halcyon days of pre7) in sbcl-0.8.10.9, but I'm still uncertain about details; if there are still observable oddities, we want to know about them. :-) In particular, I think UPGRADED-COMPLEX-PART-TYPE is fairly bogus, in that there is no sensible answer to (upgraded-complex-part-type '(eql 0)) or to (upgraded-complex-part-type '(or single-float double-float)); the first because the type lattice upgrading requirement is inconsistent with the meaning of the type (COMPLEX (EQL 0)), and the second because in fact the complex specialized representations don't form a lattice at all, because there is no complex representation that can hold all objects of type REAL. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Bruno H. <br...@cl...> - 2004-05-05 10:48:59
|
Christophe Rhodes wrote: > > The type specifier (COMPLEX type) should, according to ANSI CL's > > description (HyperSpec/Body/syscla_complex.html), only depend on > > (upgraded-complex-element-type type). > Thank you for the report. I believe I've fixed this Thanks! > In particular, I think UPGRADED-COMPLEX-PART-TYPE is fairly bogus UPGRADED-COMPLEX-PART-TYPE is reasonably specified as - a function from { subtypes of REAL } to { subtypes of REAL }, for which - for any type T, T <= (U T), - for any types T1 and T2, T1 <= T2 implies (U T1) <= (U T2). The following implementations of it are all valid: (defun upgraded-complex-part-type (type &optional environment) ; #1 (cond ((subtypep type 'NIL) 'NIL) (t 'REAL))) (defun upgraded-complex-part-type (type &optional environment) ; #2 (cond ((subtypep type 'NIL) 'NIL) (subtypep type 'RATIONAL) 'RATIONAL) (subtypep type 'SHORT-FLOAT) 'SHORT-FLOAT) (subtypep type 'SINGLE-FLOAT) 'SINGLE-FLOAT) (subtypep type 'DOUBLE-FLOAT) 'DOUBLE-FLOAT) (subtypep type 'FLOAT) 'FLOAT) (t 'REAL))) (defun upgraded-complex-part-type (type &optional environment) ; #3 type) The only two "problems" with it are: - What should be the result when the input type is not a recognizable subtype of REAL? Say, (UPGRADED-COMPLEX-PART-TYPE 'SYMBOL) (UPGRADED-COMPLEX-PART-TYPE '(SATISFIES SYMBOLP)) (UPGRADED-COMPLEX-PART-TYPE '(SATISFIES REALP)) I think one may give an error here. - The upgrading can be defined arbitrarily, independently how the implementation actually works. This is because there is no MAKE-COMPLEX function taking a type specifier as argument, and no way to SETF REALPART or SETF IMAGPART of an existing complex number. For CLISP, definition #1 reflects the implementation realities but I'll use definition #3 because it allows a maximum of type inference. > there is no sensible answer to > (upgraded-complex-part-type '(eql 0)) > because the type lattice upgrading requirement is > inconsistent with the meaning of the type (COMPLEX (EQL 0)) Err, the type (COMPLEX (EQL 0)) is _defined_ as a function of (upgraded-complex-part-type '(EQL 0)). See http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/syscla_complex.html If you define (upgraded-complex-part-type '(EQL 0)) => RATIONAL, the type (COMPLEX (EQL 0)) is equivalent to (COMPLEX RATIONAL). > there is no sensible answer to > (upgraded-complex-part-type '(or single-float double-float)); > because in fact the complex specialized representations don't > form a lattice at all, because there is no complex representation that > can hold all objects of type REAL. Possible results of (upgraded-complex-part-type '(or single-float double-float)) can be (OR SINGLE-FLOAT DOUBLE-FLOAT), FLOAT, or REAL. Since FLOAT is the disjoint union of SINGLE-FLOAT, DOUBLE-FLOAT, etc., and because of the contagion rules http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/fun_complex.html http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/sec_12-1-4-4.html (COMPLEX FLOAT) is the disjoint union of (COMPLEX SINGLE-FLOAT), (COMPLEX DOUBLE-FLOAT) etc. (COMPLEX REAL) and (COMPLEX FLOAT) can well be abstract types, in the sense that they have no direct instances other than those of (COMPLEX SINGLE-FLOAT), (COMPLEX DOUBLE-FLOAT) etc. Why not? Bruno |
From: Christophe R. <cs...@ca...> - 2004-05-05 11:05:20
|
Bruno Haible <br...@cl...> writes: >> there is no sensible answer to >> (upgraded-complex-part-type '(eql 0)) >> because the type lattice upgrading requirement is >> inconsistent with the meaning of the type (COMPLEX (EQL 0)) > > Err, the type (COMPLEX (EQL 0)) is _defined_ as a function of > (upgraded-complex-part-type '(EQL 0)). See > http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/syscla_complex.html It is also defined as, in the very next paragraph: (complex type-specifier) refers to all complexes that can result from giving numbers of type type-specifier to the function complex, plus all other complexes of the same specialized representation. and there are no complexes that can result from giving numbers of type (EQL 0) to the function COMPLEX. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Paul F. D. <di...@dl...> - 2004-05-05 11:08:58
|
Christophe Rhodes wrote: > It is also defined as, in the very next paragraph: > (complex type-specifier) refers to all complexes that can result > from giving numbers of type type-specifier to the function complex, > plus all other complexes of the same specialized representation. > and there are no complexes that can result from giving numbers of type > (EQL 0) to the function COMPLEX. Doesn't the 'plus all other complexes of the same specialized representation' save you there? Paul |