[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reading NaNs
| 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)
((> 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?