Ramakrishnan and others,
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.
Within that case, if the exponent is an inexact integer, then we make it
exact and make the base inexact, and then call scm_integer_expt.
I think this strategy is better for these reasons:
* Fewer top-level cases to check, thus making expt faster.
* More precise answers in the case of inexact integer exponents.
* More cases handled without spurious imaginary parts turning up, for
example (expt +234234234.5i 4.0)
* Simpler code
Something like the code below. (WARNING: UNTESTED!)
What do you all think? Can you see any problems with this strategy?
Best,
Mark
index fbc6cc8..f38772e 100644
--- a/libguile/numbers.c
+++ b/libguile/numbers.c
@@ -5445,8 +5445,14 @@ SCM_DEFINE (scm_expt, "expt", 2, 0, 0,
"Return @var{x} raised to the power of @var{y}.")
#define FUNC_NAME s_scm_expt
{
- if (scm_is_true (scm_exact_p (x)) && scm_is_integer (y))
- return scm_integer_expt (x, y);
+ if (scm_is_integer (y))
+ {
+ if (scm_is_true (scm_exact_p (y)))
+ return scm_integer_expt (x, y);
+ else
+ return scm_integer_expt (scm_exact_to_inexact(x),
+ scm_inexact_to_exact(y));
+ }
else if (scm_is_real (x) && scm_is_real (y) && scm_to_double (x) >= 0.0)
{
return scm_from_double (pow (scm_to_double (x), scm_to_double (y)));
