Fix parsing of exact numbers with negative exponents

* libguile/numbers.c (mem2decimal_from_point): Use scm_divide instead of
  scm_divide2real when applying a negative exponent, to preserve
  exactness in case the "#e" forced exactness specifier is present.
  This fixes a bug where numeric literals such as "#e1e-5" yielded
  incorrect fractions.

diff --git a/libguile/numbers.c b/libguile/numbers.c
index 427e772..b4f2242 100644 (file)
--- a/libguile/numbers.c
+++ b/libguile/numbers.c
@@ -5668,7 +5668,7 @@ mem2decimal_from_point (SCM result, SCM mem,
          if (sign == 1)
            result = scm_product (result, e);
          else
-           result = scm_divide2real (result, e);
+           result = scm_divide (result, e);
 
          /* We've seen an exponent, thus the value is implicitly inexact. */
          x = INEXACT;

diff --git a/test-suite/tests/numbers.test b/test-suite/tests/numbers.test
index 9584294..d94b6a1 100644 (file)
--- a/test-suite/tests/numbers.test
+++ b/test-suite/tests/numbers.test
@@ -1456,6 +1456,11 @@
     (pass-if (string=? (number->string 35 36) "z"))
     (pass-if (= (num->str->num 35 36) 35))
 
+    ;; Before Guile 2.0.1, even in the presence of a #e forced exactness
+    ;; specifier, negative exponents were applied inexactly and then
+    ;; later coerced to exact, yielding an incorrect fraction.
+    (pass-if (eqv? (string->number "#e1e-10") 1/10000000000))
+
     ;; Numeric conversion from decimal is not precise, in its current
     ;; implementation, so 11.333... and 1.324... can't be expected to
     ;; reliably come out to precise values.  These tests did actually work