This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
| Date: Mon, 24 Oct 2005 12:23:42 -0700 (PDT) | From: bear <bear@xxxxxxxxx> ... | 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!