[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

*To*: cesura@xxxxxxxxxxx*Subject*: Re: external representations*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sat, 18 Jun 2005 21:55:42 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9lu0jwyu8q.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (message from William D Clinger on Sat, 18 Jun 2005 09:55:17 +0200)*References*: <y9lu0jwyu8q.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

| From: William D Clinger <cesura@xxxxxxxxxxx> | Date: Sat, 18 Jun 2005 09:55:17 +0200 | | I have four things to say. | | 1. Defining a distinct external syntax for every NaN, or providing | some other means for programs to create specific NaNs, would | interfere with a representation that is likely to be of great | importance on 64-bit machines. | | With regard to the first point, one of the most attractive 64-bit | representations is to represent all non-NaN inexact reals in IEEE | double precision format, and to represent all other Scheme values | as NaNs. This works because there are about 2^53 NaNs, which is | about 2^53 more NaNs than are needed to represent the results of | floating point computation. | | Using these excess NaNs to encode all of Scheme's non-flonum values | is practical, and results in very efficient floating point | calculation. I would oppose any proposed external syntax for NaNs | that might interfere with the representation of Scheme values as | NaNs. SRFI-70 mandates no connection between IEEE-754 NaN and 0/0. In fact, (= 0/0 0/0) ==> #t, while NaN != NaN in IEEE-754 arithmetic (in C). Furthermore, SRFI-70 0/0 is a single number (which is not complex). And 0/0 is optional in SRFI-70. So SRFI-70 is no threat to using 2^53 NaNs for any purpose. | 2. The proposed 1/0 and -1/0 syntax for infinities has two related | problems: it looks like these things are exact, and allowing this | syntax will require a more complicated rule for deciding whether a | numeric literal is exact or inexact. One of the notations being floated is #i1/0 and #i-1/0 (and #i0/0). This notation looks inexact; and requires no rule complications. Does that assuage your concerns? | 3. The +inf.0 and -inf.0 syntax is already used by several | implementations, which agreed to standardize upon it several years | ago, before the SRFI process began. Th +inf.0 and -inf.0 syntaxes | (and +nan.0) also appear within The Revised R6RS Status Report of | October 2004, which is online at www.schemers.org. | With regard to 2 and 3, I think SRFIs and other standardization | processes should attempt to build on past standardization; | otherwise we'll just be going around in circles. The proposed 1/0 | and -1/0 syntax is contrary to the R5RS rule for determining | whether an external representation names an exact or inexact | number. It is also contrary to the informal standard that several | major implementations have already agreed upon and have used for | several years. Finally, it is contrary to the syntax being | considered by the R6RS editors. Their progress report of October | 2004 listed +inf.0 and -inf.0 among the things that are "probably | not terribly controversial". On June 28, 2003 I posted to rrrs-authors@xxxxxxxxxxxxxxxxx a survey <http://swiss.csail.mit.edu/~jaffer/III/RAWI> of infinity behaviors and notations in Kawa-1.7, SCM-5d8, Guile-1.3.4, Bigloo-2.5c, glibc-2.2, Elk-3.0, Gambit-3.0, Mz-Scheme-202, MIT-Scheme-7.8, and Scheme-48-0.57. At that time, there was no notation common to more than one Scheme implementation. That it is "not terribly controversial" could only be arrived at by ignoring most Scheme implementations. Being an author of SCM, and having posted an article on this topic to rrrs-authors@xxxxxxxxxxxxxxxxx, I am mystified by a standardization process which not only doesn't include interested implementors, it doesn't even notify them "several years" after the fact! Am I wasting my time tendering SRFIs in hopes of participating in the development of R6RS? As for the relative merits of notations, 1/0 is very evocative for infinity. While "finit" is a Latin root, "infinit" is a Middle English derivation. Thus "inf" will be not be nearly as evocative for most people. Numerical data written by Scheme programs will be seen by people who have never read a Scheme Report. Seeing 1/0 or -1/0, many will intuit that the calculation reached an exceptional value. "Nan" as a numerical notation is obscure, even to English speakers. It is an acronym for not-a-number, which isn't the case for SRFI-70 #i0/0; (number? #i0/0) ==> #t. There is still time for R6RS to improve upon the casually adopted "standard" of +inf.0. | 4. So far as I can tell, the R5RS does not require | every number to have an external representation. You are correct. The type restriction implied by the `z' argument is that only complex numbers need have external representations. 6.2.6 Numerical input and output: -- procedure: number->string z -- procedure: number->string z radix ... The procedure `number->string' takes a number and a radix and returns as a string an external representation of the given number in the given radix such that (let ((number NUMBER) (radix RADIX)) (eqv? number (string->number (number->string number radix) radix))) is true. It is an error if no possible result makes this expression true. 1.3.3 Entry format: It is an error for an operation to be presented with an argument that it is not specified to handle. Thus (number->string 0/0) is an error. The equivalence of number notations between string->number, number->string, literal constants, and read, and write was shown in <http://srfi.schemers.org/srfi-70/mail-archive/msg00061.html>

**References**:**external representations***From:*William D Clinger

- Prev by Date:
**external representations** - Next by Date:
**Re: infinities reformulated** - Previous by thread:
**external representations** - Next by thread:
**Re: external representations** - Index(es):