Re: fix for expt bug

[Mark H Weaver]

address@hidden (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