From 4ad20a7f5f65b8aca4fe1411eae3683db0bcd1ba Mon Sep 17 00:00:00 2001
From: toy <toy>
Date: Tue, 22 Apr 2003 16:04:48 +0000
Subject: [PATCH] Note that (complex single-float) and (complex double-float)
 are good numeric types, and adjust text accordingly.

Also note that structure slots can hold these complex types without
boxing.
---
 docs/cmu-user/compiler-hint.tex | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/docs/cmu-user/compiler-hint.tex b/docs/cmu-user/compiler-hint.tex
index 71387d8eb..be5294144 100644
--- a/docs/cmu-user/compiler-hint.tex
+++ b/docs/cmu-user/compiler-hint.tex
@@ -2934,8 +2934,9 @@ arithmetic, several constraints must be met:
 \end{itemize}
 
 The ``good types'' are \w{\code{(signed-byte 32)}},
-\w{\code{(unsigned-byte 32)}}, \code{single-float} and
-\code{double-float}.  See sections \ref{fixnums}, \ref{word-integers}
+\w{\code{(unsigned-byte 32)}}, \code{single-float},
+\code{double-float}, \code{(complex single-float)}, and \code{(complex
+  double-float)}.  See sections \ref{fixnums}, \ref{word-integers}
 and \ref{float-efficiency} for more discussion of good numeric types.
 
 \code{float} is not a good type, since it might mean either
@@ -2950,16 +2951,19 @@ would be at a loss if there was no declaration at all
 useful in this regard, since they can often be strengthened to a good
 integer type.
 
-Arithmetic with \code{complex} numbers is inefficient in comparison to
-float and integer arithmetic.  Complex numbers are always represented
-with a pointer descriptor (causing consing overhead), and complex
-arithmetic is always closed coded using the general generic arithmetic
-functions.  But arithmetic with complex types such as:
+% Arithmetic with \code{complex} numbers is inefficient in comparison to
+% float and integer arithmetic.  Complex numbers are always represented
+% with a pointer descriptor (causing consing overhead), and complex
+% arithmetic is always closed coded using the general generic arithmetic
+As noted above, \cmucl{} has support for \code{(complex single-float)}
+and \code{(complex double-float)}.  These can be unboxed and, thus,
+are quite efficient.  However, arithmetic with complex types such as:
 \begin{lisp}
 (complex float)
 (complex fixnum)
 \end{lisp}
-is still faster than \code{bignum} or \code{ratio} arithmetic, since the
+will be significantly slower than the good complex types but is still
+faster than \code{bignum} or \code{ratio} arithmetic, since the
 implementation is much simpler.
 
 Note: don't use \code{/} to divide integers unless you want the
@@ -3189,7 +3193,7 @@ The derived result of the function is \code{(OR SINGLE-FLOAT
 actually a complex number.  Because of this, the generic complex log
 routine is used.
 
-If the declaration for \code{x} were \code{(single-float (0f0))} so 0
+If the declaration for \code{x} were \code{(single-float (0f0))} so $+0.0$
 is not included or \code{(or (single-float (0f0)) (member 0f0))} so
   $+0.0$ is include but not $-0.0$, the derived type would be
   \code{single-float} for both cases.  By declaring \code{x} this way,
@@ -3280,6 +3284,8 @@ representations.  These types (and subtypes of these types) are supported:
 (unsigned-byte 32)
 single-float
 double-float
+(complex single-float)
+(complex double-float)
 \end{lisp}
 
 The primary advantage of specialized slot representations is a large
-- 
GitLab