[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My suggestions to the R6RS committee about numerics
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) 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