l...@gnu.org (Ludovic Courtès) writes: >> I just realized that there is a better way to fix these bugs. We don't >> need a new top-level case in expt after all. Instead, we generalize the >> scm_integer_expt case to support inexact integer exponents. > > You mean “inexact number”, right?
No, I meant "inexact integer", for example 3.0. > However, an integer is necessarily an exact number, No, (integer? 3.0) returns #t, as it should, according to R5RS. R5RS's description of "integer?" gives this precise example, and guile's implementation agrees. > So I suspect that your patch doesn’t work because ‘inexact->exact’ > returns something that’s obviously not necessarily an integer: I'm only talking about inexact integers such as 3.0, so that (expt 2 3.0) ==> (integer-expt 2.0 3) ==> 8.0 However, I have since realized that it is not enough to convert the base to inexact; I must also convert integer-expt's result to inexact, because there is one case where making the base inexact is not enough: (expt 3 0.0) ==> (integer-expt 3.0 0) ==> 1 Though (expt 3 0.0) should reduce to 1.0. So the code needs to coerce the result of integer-expt to inexact. I am working on a patch to fix these and some other problems. Mark