Bradley Lucier <xxxxxx@purdue.edu> writes:

> 1.  I would recommend that (complex-generator) return first
>
> (define special-reals
>   '(0 -0 +1 -1 +0. -0. 1. -1. +inf.0 -inf.0 +nan.0 -nan.0))
>
> (apply append
>        (map (lambda (first)
>               (map (lambda (second)
>                      (make-rectangular first second))
>                    special-reals))
>             special-reals))
>
> as much as possible.  Gambit doesn't have -0, -nan.0; some schemes don't have
> mixed exactness.

Yes the number sequences should be kept at the top with the rest of the
implementation-dependent constants. I will clean that up and update the
sample code with something like this:

;; Omit values that are not distinguished in the implementation.
(cond-expand
  (implementation-with-negative-zero
      (define number-sequence '(0 -0 1 -1 1.1 -1.1 +i -i ...)))
  (...))

(filter real? number-sequence)
(filter integer? number-sequence) ; and so on...

> 2.  I'd recommend that (exact-complex-generator) return first
>
> (define special-exact-reals
> '(+0 -0 +1 -1))
>
> (apply append
>        (map (lambda (first)
>               (map (lambda (second)
>                      (make-rectangular first second))
>                    special-exact-reals))
>             special-exact-reals))
>
> which in Gambit is
>
> (0 0 +i -i 0 0 +i -i 1 1 1+i 1-i -1 -1 -1+i -1-i)

Yes, except that the first 4 values are repeated. I'll try to install
Gambit and make sure the sample code works. The sample code was written
with Gauche in mind because that's the only implementation that supports
all of SRFI 64, 158, and 194.

> 3.  Should
>
> (exact-generator) be renamed to (exact-real-generator), and
> (inexact-generator) be renamed to (inexact-real-generator)?

The intention was to match the generator names to the type predicates,
so exact? became exact-generator and inexact? became inexact-generator.

> 4.  Do you mean (number-generator) to be (real-number-generator)?  I guess I
> don't really see the difference between
>
> (compex-generator) and (number-generator) (unless you support quaternions or
> something like that).

Since number-generator corresponds to the number? predicate, it should
generate both real and complex numbers, which it currently does not do.
That is a bug, will fix. Thank you for the suggestions.