This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
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 <lucier@xxxxxxxxxxxxxxx> | 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 <lucier@xxxxxxxxxxxxxxx> | > | 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) procedureThese 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 differentexactness, 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