complex number reader bug?

complex number reader bug?

[Bill Schottstaedt]

guile> (number? '1.0+.1i)
#f
guile> .1
0.1
guile> 1+.1i
1.0+0.1i
guile> 1.0+.1i
ERROR: Unbound variable: 1.0+.1i
ABORT: (unbound-variable)


Other similar cases:

.1+.0i
1.+.0i
.1+.1i
1e1+.1i

Re: complex number reader bug?

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:

> guile> (number? '1.0+.1i)
> #f
> guile> .1
> 0.1
> guile> 1+.1i
> 1.0+0.1i
> guile> 1.0+.1i
> ERROR: Unbound variable: 1.0+.1i
> ABORT: (unbound-variable)
>
>
> Other similar cases:
>
> .1+.0i
> 1.+.0i
> .1+.1i
> 1e1+.1i

Below is a patch for review.  It was an interesting problem, as I
haven't gone very far into Guile's number handling code before.

    Neil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Read-complex-numbers-where-both-parts-are-inexact-de.patch --]
[-- Type: text/x-diff, Size: 3713 bytes --]

From 04f9bc774a49b0ab54a37eb401b76aa824876c75 Mon Sep 17 00:00:00 2001
From: Neil Jerram <neil@ossau.uklinux.net>
Date: Wed, 1 Jul 2009 01:39:24 +0100
Subject: [PATCH] Read complex numbers where both parts are inexact decimals

Thanks to Bill Schottstaedt for reporting this problem!

* libguile/numbers.c (mem2ureal): Don't be misled by *p_exactness
  being INEXACT on entry (as is possible when reading a complex
  number): use local exactness variable x which starts as EXACT.
  Call mem2decimal_from_point () with &x instead of p_exactness.

* test-suite/tests/numbers.test ("string->number"): Add complex number
  tests suggested by Bill.
---
 NEWS                          |    1 +
 libguile/numbers.c            |   19 +++++++++++++------
 test-suite/tests/numbers.test |    9 ++++++++-
 3 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/NEWS b/NEWS
index 235dcd5..0c21225 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,7 @@ Changes in 1.8.7 (since 1.8.6)
 ** With GCC, always compile with `-mieee' on `alpha*' and `sh*'
 ** Better diagnose broken `(strftime "%z" ...)' in `time.test' (bug #24130)
 ** Fix parsing of SRFI-88/postfix keywords longer than 128 characters
+** Fix reading of complex numbers where both parts are inexact decimals
 
 ** Allow @ macro to work with (ice-9 syncase)
 
diff --git a/libguile/numbers.c b/libguile/numbers.c
index 25b0c1a..2e1635f 100644
--- a/libguile/numbers.c
+++ b/libguile/numbers.c
@@ -2739,6 +2739,10 @@ mem2ureal (const char* mem, size_t len, unsigned int *p_idx,
   unsigned int idx = *p_idx;
   SCM result;
 
+  /* Start off believing that the number will be exact.  This changes
+     to INEXACT if we see a decimal point or a hash. */
+  enum t_exactness x = EXACT;
+
   if (idx == len)
     return SCM_BOOL_F;
 
@@ -2750,8 +2754,6 @@ mem2ureal (const char* mem, size_t len, unsigned int *p_idx,
 
   if (idx+4 < len && !strncmp (mem+idx, "nan.", 4))
     {
-      enum t_exactness x = EXACT;
-
       /* Cobble up the fractional part.  We might want to set the
 	 NaN's mantissa from it. */
       idx += 4;
@@ -2770,11 +2772,10 @@ mem2ureal (const char* mem, size_t len, unsigned int *p_idx,
 	return SCM_BOOL_F;
       else
 	result = mem2decimal_from_point (SCM_I_MAKINUM (0), mem, len,
-					 p_idx, p_exactness);
+					 p_idx, &x);
     }
   else
     {
-      enum t_exactness x = EXACT;
       SCM uinteger;
 
       uinteger = mem2uinteger (mem, len, &idx, radix, &x);
@@ -2806,10 +2807,16 @@ mem2ureal (const char* mem, size_t len, unsigned int *p_idx,
 	result = uinteger;
 
       *p_idx = idx;
-      if (x == INEXACT)
-	*p_exactness = x;
     }
 
+  /* Update *p_exactness if the number just read was inexact.  This is
+     important for complex numbers, so that a complex number is
+     treated as inexact overall if either its real or imaginary part
+     is inexact.
+  */
+  if (x == INEXACT)
+    *p_exactness = x;
+
   /* When returning an inexact zero, make sure it is represented as a
      floating point value so that we can change its sign. 
   */
diff --git a/test-suite/tests/numbers.test b/test-suite/tests/numbers.test
index 2dbc917..bafd9cd 100644
--- a/test-suite/tests/numbers.test
+++ b/test-suite/tests/numbers.test
@@ -1365,7 +1365,14 @@
                 ("1@0" 1.0) ("1@+0" 1.0) ("1@-0" 1.0)
                 ("2+3i" ,(+ 2 (* 3 +i))) ("4-5i" ,(- 4 (* 5 +i)))
                 ("1+i" 1+1i) ("1-i" 1-1i) ("+1i" 0+1i) ("-1i" 0-1i)
-                ("+i" +1i) ("-i" -1i)))
+                ("+i" +1i) ("-i" -1i)
+		("1.0+.1i" 1.0+0.1i)
+		("1.0-.1i" 1.0-0.1i)
+		(".1+.0i" 0.1)
+		("1.+.0i" 1.0)
+		(".1+.1i" 0.1+0.1i)
+		("1e1+.1i" 10+0.1i)
+		))
     #t)
 
   (pass-if-exception "exponent too big"
-- 
1.5.6.5

Re: complex number reader bug?

[Ludovic Courtès]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Below is a patch for review.  It was an interesting problem, as I
> haven't gone very far into Guile's number handling code before.

Nice, thanks!  Looks good to me.

Ludo'.