Hi Mark,
Mark H Weaver <[email protected]> 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?
The doc for ‘integer-expt’ makes the same mistake:
"Return @var{n} raised to the power @var{k}. @var{k} must be an\n"
"exact integer, @var{n} can be any number.\n"
However, an integer is necessarily an exact number, whereas the converse
isn’t true:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user) [25]> (exact? 2/3)
$4 = #t
scheme@(guile-user) [25]> (integer? 2/3)
$5 = #f
--8<---------------cut here---------------end--------------->8---
In actuality, ‘integer-expt’ expects K to be an integer (fixnum or
bignum).
So I suspect that your patch doesn’t work because ‘inexact->exact’
returns something that’s obviously not necessarily an integer:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user) [25]> (inexact->exact 2.3)
$6 = 2589569785738035/1125899906842624
--8<---------------cut here---------------end--------------->8---
Does that make sense?
Thanks,
Ludo’.
