1
0
Fork 0
cl-sites/HyperSpec-7-0/HyperSpec/Issues/iss290_w.htm
2024-04-01 10:24:07 +02:00

206 lines
15 KiB
HTML

<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
<HTML>
<HEAD>
<TITLE>CLHS: Issue REAL-NUMBER-TYPE Writeup</TITLE>
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
<LINK REL=TOP HREF="../Front/index.htm">
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
<LINK REL=PREV HREF="../Issues/iss289_w.htm">
<LINK REL=UP HREF="../Issues/iss290.htm">
<LINK REL=NEXT HREF="../Issues/iss291_w.htm">
</HEAD>
<BODY>
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss289_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss290.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss291_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
<HR>
<H2>Issue REAL-NUMBER-TYPE Writeup</H2>
<PRE><B>Issue:</B> <A HREF="iss290.htm">REAL-NUMBER-TYPE</A><P>
<B>Forum:</B> CLEANUP<P>
<B>References:</B> Table 4-1.<P>
<B>Category:</B> ADDITION<P>
<B>Edit history:</B> 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,<P>
and John Aspinall<P>
08-JAN-89, Version 2 by Bob Cassels -- incorporate<P>
Masinter's suggestion and make <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> a CLOS <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A><P>
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's<P>
suggestions clarifying the relationship between CL<P>
numeric type names and mathematical names<P>
05-APR-89, Version 4 by Pitman (changes per X3J13)<P>
<B>Status:</B> Accepted v3 Mar-89 by X3J13 (on a 12-3 vote) with <P>
amendments. The proposal as amended is v4.<P>
<P>
<B>Problem Description:<P>
</B><P>
There is no <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> type specifier symbol for the CL type<P>
'(<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A> <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A>). <P>
<P>
<B>Proposal (REAL-NUMBER-TYPE:X3J13-MAR-89):<P>
</B><P>
Make <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> be a CL data type:<P>
<P>
p.13 &quot;Numbers&quot;<P>
<P>
Add: The <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A> data type encompasses all of these kinds of<P>
numbers. For convenience, there are names for some<P>
subclasses of numbers. @i[Integers] and @i[ratios] are of<P>
type <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A>. @i[Rational numbers] and @[floating-point<P>
numbers] are of type <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A>. @i[Real numbers] and @i[complex<P>
numbers] are of type <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>.<P>
<P>
Although the names of these types were chosen with the<P>
terminology of mathematics in mind, the correspondences<P>
are not always exact. Integers and ratios model the<P>
corresponding mathematical concepts directly. Numbers<P>
of the <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> type may be used to approximate real<P>
numbers, both rational and irrational. The <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> type<P>
includes all Common Lisp numbers which represent<P>
mathematical real numbers, though there are<P>
mathematical real numbers (irrational numbers)<P>
which do not have an exact Common Lisp representation.<P>
Only <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> numbers may be ordered using the &lt;, &gt;, <A REL=DEFINITION HREF="../Body/f_eq_sle.htm#LTEQ"><B>&lt;=</B></A>,<P>
and <A REL=DEFINITION HREF="../Body/f_eq_sle.htm#GTEQ"><B>&gt;=</B></A> functions.<P>
<P>
Compatibility note: The Fortran <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> defines the term<P>
&quot;real datum&quot; to mean &quot;a processor approximation to the value<P>
of a real number.&quot; In practice the Fortran &quot;basic real&quot; type<P>
is the floating-point data type Common Lisp calls<P>
<A REL=DEFINITION HREF="../Body/t_short_.htm#single-float"><B>SINGLE-FLOAT</B></A>. The Fortran &quot;double precision&quot; type is<P>
Common Lisp's <A REL=DEFINITION HREF="../Body/t_short_.htm#double-float"><B>DOUBLE-FLOAT</B></A>. The Pascal &quot;real&quot; data type is<P>
an &quot;implementation-defined subset of the real numbers.&quot; In<P>
practice this is usually a floating-point type, often what<P>
Common Lisp calls <A REL=DEFINITION HREF="../Body/t_short_.htm#double-float"><B>DOUBLE-FLOAT</B></A>.<P>
<P>
A translation of an algorithm written in Fortran or Pascal<P>
which uses &quot;real&quot; data usually will use some appropriate<P>
precision of Common Lisp's <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> type. Some algorithms may<P>
gain accuracy and/or flexibility by using Common Lisp's<P>
<A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A> or <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> types instead.<P>
<P>
p.33 &quot;Overlap, Inclusion, and Disjointness of Types&quot;:<P>
<P>
Remove: The types <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A>, <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A>, and <A REL=DEFINITION HREF="../Body/a_comple.htm#complex"><B>COMPLEX</B></A> are pairwise<P>
disjoint subtypes of <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>.<P>
<P>
Rationale: It might be thought that <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A> and <A REL=DEFINITION HREF="../Body/t_ratio.htm#ratio"><B>RATIO</B></A> ...<P>
<P>
Rationale: It might be thought that <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>FIXNUM</B></A> and <A REL=DEFINITION HREF="../Body/t_bignum.htm#bignum"><B>BIGNUM</B></A> ...<P>
<P>
Add: The types <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A> and <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> are pairwise disjoint subtypes<P>
of <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A>.<P>
<P>
The types <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> and <A REL=DEFINITION HREF="../Body/a_comple.htm#complex"><B>COMPLEX</B></A> are pairwise disjoint subtypes<P>
of <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>.<P>
<P>
Rationale: It might be thought that <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>FIXNUM</B></A> and <A REL=DEFINITION HREF="../Body/t_bignum.htm#bignum"><B>BIGNUM</B></A> should <P>
form an exhaustive partition of the type <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A>, that <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A><P>
and <A REL=DEFINITION HREF="../Body/t_ratio.htm#ratio"><B>RATIO</B></A> should form an exhaustive partition of <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A>,<P>
that <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A> and <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> should form an exhaustive partition of <P>
<A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A>, and that <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> and <A REL=DEFINITION HREF="../Body/a_comple.htm#complex"><B>COMPLEX</B></A> should form an exhaustive<P>
partition of <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>. These are all purposely avoided in order <P>
to permit compatible experimentation with extensions to the<P>
Common Lisp number system, such as the idea of adding explicit <P>
representations of infinity or of positive and negative infinity.<P>
<P>
p.43 Table 4-1 &quot;Standard Type Specifier Symbols&quot;<P>
<P>
Add: <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A><P>
<P>
p.49 &quot;Type Specifiers that Abbreviate&quot;<P>
<P>
Add: (<A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> low high)<P>
Denotes the set of real numbers between low and high. ...<P>
[As with <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A> and <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A>.]<P>
<P>
<P>
Make <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> a built-in CLOS <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A>.<P>
<P>
Add a specific data type predicate <A REL=DEFINITION HREF="../Body/f_realp.htm#realp"><B>REALP</B></A> which tests for membership in<P>
this type. [By analogy with <A REL=DEFINITION HREF="../Body/f_nump.htm#numberp"><B>NUMBERP</B></A>.]<P>
<P>
<B>Test Case:<P>
</B><P>
If a programmer wishes to test for &quot;a number between 1 and 10&quot;, the<P>
only current CL types would be '(or (rational 1 10) (float 1 10)) or<P>
something like '(and <A REL=DEFINITION HREF="../Body/f_nump.htm#numberp"><B>numberp</B></A> (not <A REL=DEFINITION HREF="../Body/f_comp_3.htm#complexp"><B>complexp</B></A>) (satisfies range-1-10))<P>
with (<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> range-1-10 (real) (<A REL=DEFINITION HREF="../Body/f_eq_sle.htm#LTEQ"><B>&lt;=</B></A> 1 real 10)). Both of these are<P>
likely less efficient, and certainly less expressive than '(real 1 10).<P>
<P>
<B>Rationale:<P>
</B><P>
Mathematics has a name for (<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A> <A REL=DEFINITION HREF="../Body/a_ration.htm#rational"><B>RATIONAL</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A>) -- it is &quot;real&quot;.<P>
This <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> is important because it is all the numbers which can be<P>
ordered.<P>
<P>
Throughout the &quot;Numbers&quot; chapter, the phrase &quot;non-complex number&quot; is<P>
used.<P>
<A REL=DEFINITION HREF="../Body/f_max_m.htm#max"><B>MAX</B></A>, <A REL=DEFINITION HREF="../Body/f_max_m.htm#min"><B>MIN</B></A>, p. 198 &quot;The arguments may be any non-complex numbers.&quot;<P>
<A REL=DEFINITION HREF="../Body/f_cis.htm#cis"><B>CIS</B></A> p. 207 &quot;The argument ... may be any non-complex number.&quot;<P>
<P>
<B>Current Practice:<P>
</B><P>
Probably nobody does this.<P>
<P>
<B>Cost to Implementors:<P>
</B><P>
Some work is necessary to add this name. But since the underlying<P>
type already exists the amount of work should be minimal.<P>
<P>
<B>Cost to Users:<P>
</B><P>
Since this is an upward-compatible extension, it may be ignored by<P>
users.<P>
<P>
<B>Cost of Non-Adoption:<P>
</B><P>
Occasional inconvenience and/or inefficiency.<P>
<P>
<B>Benefits:<P>
</B><P>
Mathematical clarity.<P>
<P>
Ability to do CLOS <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> dispatch on the type.<P>
<P>
<B>Aesthetics:<P>
</B><P>
As mentioned under &quot;rationale,&quot; this would be a more concise way to<P>
express a common programming idiom.<P>
<P>
<B>Discussion:<P>
</B><P>
The name &quot;non-complex number&quot; is incorrect because future<P>
implementations may wish to include numerical types which are neither<P>
complex nor real. [e.g. pure imaginary numbers or quaternions]<P>
<P>
The name &quot;scalar&quot; is incorrect because the mathematical concept of<P>
scalar may indeed include complex numbers.<P>
<P>
Fortran and Pascal use the name &quot;real&quot; to mean what CL calls<P>
<A REL=DEFINITION HREF="../Body/t_short_.htm#single-float"><B>SINGLE-FLOAT</B></A>. That should cause no significant problem, since a Lisp<P>
program written using the type <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> will do mathematically what the<P>
equivalent Fortran program would do. This is because Fortran's &quot;real&quot;<P>
data-type is a subtype of the CL <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> type. The only differences<P>
might be that the Lisp program could be less efficient and/or more<P>
accurate.<P>
<P>
A survey of several Fortran and Pascal books shows that the distinction<P>
between <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A> and <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> is that <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> numbers may have fractional<P>
parts, while INTEGERs do not. Later discussions explain that REALs<P>
cover a greater range. Much later discussions cover precision<P>
considerations, over/underflow, etc. So the average Fortran or Pascal<P>
programmer should be completely comfortable with the proposed Lisp<P>
concept of <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A>.<P>
</PRE>
<HR>
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
</BODY>
</HTML>