On Tue, 2009-09-22 at 20:34 -0400, John Cowan wrote:
> Yes, it's amazing how much faster a numerical Scheme program can often be
> made by the
> insertion of a few judicious dots, which force flonum arithmetic!
Am I *not* the only one, then, who prefers the "overflow to an inexact"
semantics to the "consume all memory and crash" semantics?
Honestly, I think most of the practical problems with bignums would be
solved if there were no automatic coercion between 'big' and
'fixed-size' numeric representations. You shouldn't get bignum
results (and the attendant risk of "consume all memory and crash"
semantics) unless you specifically use bignum arguments (and
therefore say, "yes I know I'm taking that risk").
This, however, would make 'big-ness' another type division, similar to
the exact/inexact distinction in scheme, where an exact integer 6 could
be either a fixnum or bignum.
> > And exact-rational support is halfbaked: (expt 27 1/3) should return
> > exact 3, but doesn't in the implementations I have tried.
> That is why I am proposing a rational-expt function which accepts a
> rational base and integer exponent and returns a rational value,
> for users who want exact results or systems without flonums.
;; note: expt must be a nonnegative exact integer.
;; returns exact if base is exact, inexact otherwise.
(define rational-expt
(lambda (base expt)
(if (= expt 0) 1
(if (even? expt)
(let ((intermed (rational-expt base (/ expt 2))))
(* intermed intermed))
(let ((intermed (rational-expt base (/ (- expt 1) 2))))
(* (* intermed intermed) base))))))
But this doesn't solve the problem. Note that he wanted to use a
rational rather than an integer expt. That's harder to come up with
a nice easy closed form for, and requires things like branch cuts to
be defined.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
