diff --git a/libguile/numbers.c b/libguile/numbers.c
index 427e77263..b4f224240 100644
--- 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 95842941d..d94b6a14e 100644
--- 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