On Wed, 18 May 2005, Bradley Lucier wrote:

> The first part deals with IEEE 754/854 arithmetic.
> If you don't support this arithmetic, then things are still up in the
> air.

I should not like to see conforming implementations restricted
to exactly this representation and no other; It's nice to be
able to use real numbers of specified precision for some tasks
where the 500th bit of the mantissa actually matters.

>6.1 Equivalence predicates

>The eqv? procedure returns #t if:
>
>*  obj1 and obj2 are both IEEE 754/854 format numbers, and obj1 and
> obj2 have
> the same base, sign, number of exponent digits, exponent bias, biased
> exponent,
> number of significand digits, and significand.
>
>*  obj1 and obj2 are both exact numbers and are numerically equal
> (see =, section 6.2).
>
> The eqv? procedure returns #f if:
>
>*  one of obj1 and obj2 is an exact number but the other is an
>inexact number.
>
>*  obj1 and obj2 are both IEEE 754/854 format numbers, and the base,
>sign,
>number of exponent digits, exponent bias, biased exponent, number of
>significand
>digits, or significand of obj1 and obj2 differ.
>
>*  obj1 and obj2 are exact numbers for which the = procedure returns #f.

I believe that it is also necessary to specify that if one or
more of the arguments is NaN, eqv? returns false.  It is not at
all uncommon for NaN to have a single bit pattern, and thus if
compared under the above definition, a call where two arguments
were both NaN would return #t, which is a mistake in arithmetic.

It is not ideal IMO to declare it an error to pass NaN to eqv?,
since that limits the composition of expressions.

> Note: This section does not state under which conditions eqv? returns
> #t or #f
> for inexact numbers that are not in IEEE 754/854 format.  We
> recommend that
> numbers not in IEEE 754/854 format for which a base, sign, number of
> exponent
> digits, exponent bias, biased exponent, number of significand digits,
> and
> significand can be defined follow the same rules as above.

I would require rather than recommend this property; what I'd
*recommend* is for you, in the future, to practice line
wrapping at an earlier column.  :-)

>6.2.5. Numerical operations
>
>(number? obj )                           procedure
>(complex? obj )                          procedure
>(real? obj )                             procedure
>(rational? obj )                         procedure
>(integer? obj )                          procedure
>
> These numerical type predicates can be applied to any kind
> of argument, including non-numbers. They return #t if the
> object is of the named type, and otherwise they return #f.
> In general, if a type predicate is true of a number then
> all higher type predicates are also true of that number.
> Consequently, if a type predicate is false of a number, then
> all lower type predicates are also false of that number.

><delete this>
>If z is an inexact complex number, then (real? z) is true
>if and only if (zero? (imag-part z)) is true. If x is an
>inexact real number, then (integer? x) is true if and only
>if (= x (round x)).
><add this>
>If an implementation uses IEEE 754/854 format for inexact numbers then:
>*  If z is an inexact complex number, then (real? z) is true if and
>only if both (exact? (imag-part z)) and (zero? (imag-part z)) are true.
>*  If z is an inexact real number, then (rational? z) is true if and
>only
>if z is not positive or negative infinity or a not-a-number.

Note:  IEEE 754/854 gives no way to represent complex numbers.

You will have to use more precise language to say what you mean,
which is, I suspect, uses 754/854 to represent the real and
imaginary parts of the (cartesian) complex number, or uses
IEEE 754/854 to represent the magnitude and angle of the (polar)
complex number.

But once again, I don't think we need to specify this particular
format, nor to relax all restrictions if a different format is
used; In my opinion, the field widths for the mantissa and
biased exponent are irrelevant to the requirement.

In particular, be careful not to assume that all complex numbers
are internally represented in the same way; several implementations,
I believe, use both polar and cartesian representations internally.

Finally, from a mathematical point of view, a number is either
inexact or exact; this includes complex numbers.  A few
implementations allow differing exactness in the real and
imaginary parts of a complex number.  This is a fact, but the
fact lies at some intermediate position between being a mere
artifact of the representation and a mathematical error.
Consult a number theorist to understand more fully the nature
of this error; it is beyond my feeble ability to explicate.

It is not sensible to speak of an inexact complex number whose
imaginary part is exact, and if you require an implementation
that allows it to be, there will be a certain amount of wailing
and gnashing of teeth from mathematicians and number theorists,
who are currently some of scheme's most dedicated and thankful
users.

><add this>
>(real? -2.5+0.0i) =) undetermined
>(real? -2.5+0.0i) =) #f  if IEEE 754/854 arithmetic is used.
><end of addition>

Nope, sorry, this just doesn't work.

> <delete this>
> Note: The behavior of these type predicates on inexact numbers
> is unreliable, since any inaccuracy may affect the result.
> Note: In many implementations the rational? procedure will
> be the same as real?, and the complex? procedure will be the
> same as number?, but unusual implementations may be able
> to represent some irrational numbers exactly or may extend the
> number system to support some kind of non-complex numbers.
> <end of deletion>

I don't believe that this ought to be deleted.

><Add the following>
>
>For implementations that allow (real z) and (imag z) to have different
>exactness, then (exact? z) returns #t if and only if both (exact?
>(real z))
>and (exact? (imag z)) return #t.
>
><end of addition>

Once again, this proceeds from a delusory belief that one number,
as a result of its mere representation, can have two different
exactnesses simultaneously.  This will not fly.

><Change the comparison predicates to the following>

> (= z1 : : : ) procedure
> (< x1 : : : ) procedure
> (> x1 : : : ) procedure
> (<= x1 : : : ) procedure
> (>= x1 : : : ) procedure
<clip>
> Note: If an implementation uses IEEE 754/854 format for its inexact
> numbers, then these procedures shall return #f if called with two or
> more arguments when one of the arguments is a NaN.

"one of" should be changed to "one or more of" -- this does
not change meaning, but adds clarity.  And I think this should
be true of NaN's always, no matter how numbers are represented.

><change the following predicates>

> (zero? z) library procedure
> (positive? x) library procedure
> (negative? x) library procedure
> (odd? n) library procedure
> (even? n) library procedure

> These numerical predicates test a number for a particular
> property, returning #t or #f.

> If an implementation uses IEEE 754/854 format for its inexact
> numbers, then zero?, positive?, and negative? return #f if called with
> a NaN argument.

I would go further and say *all* of these procedures should return
#f if called with a NaN argument, regardless of how numbers or NaNs
are represented.

> <change the following procedures>

> (max x1 x2 : : : ) library procedure
> (min x1 x2 : : : ) library procedure

> These procedures return the maximum or minimum of their
> arguments.

> (max 3 4) =) 4 ; exact
> (max 3.9 4) =) 4.0 ; inexact

> If an implementation uses IEEE 754/854 format for its inexact
> numbers, and any of the arguments to max and min are NaNs, then
> max and min returns one of the NaN arguments as its result.

use "a" rather than "one of the", unless there is some
significance to the eq?-ness of the NaN returned with
one of its arguments.  And say simply "NaNs" if there is
not some significance to representing them in a particular
IEEE format.

> <change floor, ceiling, truncate, and round to take rational arguments,
> not real arguments>

I do not agree with you that these procedures ought not take real
arguments. Instead, they should return inexact numbers when given
inexact numbers and NaN when given NaN.

> <change rationalize to take rational arguments, not real arguments>

This does not make sense.  If you have rational arguments to start
with, what are you using rationalize for?

				Bear