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

Gaussian rationals



    Date: Friday, 3 June 1983, 17:27-EDT
    From: David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
    Having Gaussian rationals behave as an extension of the real rationals
    seems superficially plausible, but I don't consider myself competent to
    evaluate the implications.  Let me ask the $64 question: will the
    result of any function, other than type-checking functions and
    transcendental functions, be affected by this change (i.e. are there
    other functions that treat complex numbers on the real line different
    from real numbers)?

I just carefully checked the Laser manual.  I'm fairly certain that the
answer to your $64 question is:  No.

However, I am not 100% convinced we are all talking the same language here.
Let me present a small dialog with a Common Lisp interpreter to demonstrate
the behavior I think we are proposing here:

(= (/ 4 2) 2)
T			;whatever (/ 4 2) returns, it must be
			;indistinguishable from 2.  [Except perhaps by
			;using EQ?  I guess that doesn't matter.]
(integerp (/ 4 2))
T			;Indistinguishable.
(eql (/ 4 2) 2)
T			;eql is defined to be = for numbers.
(= (complex 2 0) 4/2)	;Typing "4/2" should be just like typing "2".
T			;Again indistinguishable.
(+ #C(2/3 0) 1/3)	;Typing "#C(2/3 0)" is just like typing "2/3".
1
(integerp *)
T			;Whatever it is, it acts like an integer.
(nth (+ #C(0/69 7/7) (* 3 (complex (/ 4 6) -1/3))
     '(zero one two three))
TWO

Now there is one issue that can go either way.  Currently (according to
page 24 of Laser) the complex type and the rational type are DISJOINT.  I
presume the idea is that the complex type is to consist of only those
numbers with non-zero imaginary part.  Unfortunately this is a mis-use of
the mathematical term "complex", which is normally applied to a set of
numbers that INCLUDES the real numbers.  The predicate COMPLEXP should
correctly be true of ALL Common Lisp number types, and should thus be
useless. 

Better I think, would be to have a type named REAL, then where previously
you would have written (COMPLEXP ...), now you would write
(NOT (REALP ...)).  I understand that there is a tendency in computer
languages to mis-use the word "real" to mean "floating point", but it's a
shame to introduce a new mis-use to cover for an old one.

[ BTW, I just chased all over the Laser manual trying to find where the
  printed representation of complex numbers is set forth.  I found it on
  page 15, but I looked first in the Numbers chapter, and second in the
  section of the I/O chapter titled "Printed representation...".  All
  plausible places to find such information...]