Aubrey:

Your reply hasn't reached me yet (we're having e-mail problems), so
I'm going with the copy from the archive.

> | From: Bradley Lucier <xxxxxx@math.purdue.edu>
>  | Date: Fri, 20 May 2005 15:23:28 -0500
>  |
>  | Hi, Aubrey:
>  |
>  | We already discussed many of these issues on various threads in
>  | comp.lang.scheme.
>
> I can't find any subjects with "exact", "IEEE", or "inifinity" in the
> 3100 postings in my current usenet feed.  How about a URL?

The first hit on groups.google.com for "Scheme arithmetic jaffer
lucier" gives your thread "Infinities in Scheme" from August 2003,
where I posted my recommendations to the Baltimore Scheme meeting in
1998 and we discussed those recommendations (among other things).
Explicitly, I came up with

<http://groups-beta.google.com/group/comp.lang.scheme/browse_frm/
thread/fd5f9f0238a9fb26/691ee5724d6de75a?q=scheme+arithmetic+jaffer
+lucier&rnum=1#691ee5724d6de75a>

> | On May 20, 2005, at 2:13 PM, Aubrey Jaffer wrote:
>  |
>  | >  | From: Bradley Lucier <xxxxxx@math.purdue.edu>
>  | >  | Date: Wed, 18 May 2005 22:38:43 +0200
>  | >  |
>  | >  | .., I sent document about proposed changes to numerics to
>  | >  | Marc Feeley last March to forward to the committee.  Since
> then my
>  | >  | thinking has evolved a bit, but I thought I would just
> include my
>  | >  | comments verbatim here. ...
>  | >
>  | > Why are you restricting the specification of inexacts to
> IEEE-754/854
>  | > arthmetic?
>  |
>  | I'm not doing as you suggest; perhaps you misinterpret my
>  | recommendation.
>
> You have me at a disadvantage.  Where I have written extensively about
> intent and motivations in SRFI-70, you have given no hint, even in
> response to my direct question.

OK, let's try this again.

I 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.
> ...
> 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.
> ...
> If an implementation uses IEEE 754/854 format for inexact numbers
> then:

etc.  I mean to imply that other types of inexact arithmetic are
possible, and these parts of the specification don't necessary apply
to them.  I don't pretend to be able to imagine all possible inexact
arithmetic systems.

You wrote:

> Why are you restricting the specification of inexacts to
> IEEE-754/854 arthmetic?

which I take to imply that you think my entire specification allows
only IEEE-754/854 arithmetic.

Is this right?  If so, I don't understand why you think this.

Again, I wrote:

> (exact? z)                      procedure
> (inexact? z)                    procedure
>
> These numerical predicates provide tests for the exactness of a
> quantity.
> For any Scheme number, precisely one of these predicates is true.
>
> <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>

This says explicitly that "For any Scheme number, precisely one of
these predicates is true."

Now, I understand that

"z is exact"    if and only if "(exact? z) => #t"
"z is inexact"  if and only if "(inexact? z) => #t"

Under my recommendation, precisely one of these is true, so each
scheme number is either exact or inexact, not both, and not neither.

You wrote:

> A number is either exact or inexact; and a complex number (like a
> rational number) is one number, not two.  Exactness thus applies to
> the whole complex number, not to its components.

So what are you thinking?  What are you trying to say?  Do you think
that this is in some way incompatible with my definition of exact?
and inexact??  Or are you trying to make a separate point?

You wrote:

> I will not anger you further with my guesses as to your intentions.

Angry?  No, not angry, not at all.  Bemused, perhaps, but not angry.

Brad