| Date: Mon, 24 Oct 2005 12:23:42 -0700 (PDT)
 | From: bear <xxxxxx@sonic.net>
...
 | I still think that bitwise operations on numbers are incorrect.
 | Bitwise operations should operate on bitvectors, not on numbers.
 | You are not using them as numbers when you do bit operations on
 | them, and their identity as numbers does not give the length of the
 | bitvector you're using them for. This is faint and fuzzy thinking
 | inherited from C and confuses bit representation with semantics.

It is standard practice for root-finders and irrational function
approximators to base their initial estimate on INTEGER-LENGTH.  Think
of it as (inexact->exact (+ 1 (floor (/ (log x) (log 2))))):

;;;; integer-sqrt attributed to Bradley Lucier by Steve VanDevender.
(define (integer-sqrt n)
  (cond ((> n 24) (let* ((length/4 (ash (- (integer-length n) 1) -2))
			 (sqrt-top (integer-sqrt (ash n (* -2 length/4))))
			 (init-value (ash sqrt-top length/4))
			 (q (quotient n init-value))
			 (iterated-value (quotient (+ init-value q) 2)))
		    (if (odd? q) iterated-value
			(let ((m (- iterated-value init-value)))
			  (if (< (remainder n init-value) (* m m))
			      (- iterated-value 1)
			      iterated-value)))))
	((> n 15) 4) ((> n 8) 3) ((> n 3) 2) ((> n 0) 1) ((> n -1) 0)
	(else (slib:error 'integer-sqrt n))))

...
 | According to your definition of real? ...
 |  (real? z) <==> (let ((im (imag-part z))) (and (zero? im)(exact? im)))
 | but simultaneously,
 | (real? +nan.0) ==> #t.
 | This implies that (imag-part +nan.0) is an exact zero, which seems
 | wrong, although consistent with your declaration of NaN as a real
 | number of indeterminate value.  Are complex operations constrained
 | to return some different kind of NaN, or do their results get
 | coerced to the real line in the event of an error?

Good question!