[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*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Subject*: Re: Revision of SRFI 70 available*From*: bear <bear@xxxxxxxxx>*Date*: Mon, 18 Jul 2005 08:50:50 -0700 (PDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9lvf38ba3a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*References*: <y9lvf38ba3a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>

This draft effectively eliminates certain properties of inexactness vs. exactness, and in doing so it creates a type distinction where none was before. In the dialect spec'd by R5RS, there was never any situation where an inexact number was required and an exact one would not do; thus it was entirely correct for implementations to return exact numbers whenever the opportunity presented itself. An implementation with exact roots in its numeric system, for example, could return an exact square root of two, or multiply two such numbers to get an exact two, or multiply an inexact whatever by an exact zero to get an exact zero, or subtract a boxed inexact number from itself to get an exact zero, or whatever. Exactness, where available, was an unequivocal good. Compliance with this SRFI requires that implementations do *NOT* extend exact numerics in any way; rather than pretending to revise the standard itself, it should simply point out that the standard permits such extension but also allows compliance with the present SRFI, which forbids it. This is an example of what I meant when I had misgivings about SRFI-75 (a SRFI about R6RS) being discussed in this forum (which is NOT about RnRS); it confuses the two processes to an intolerable degree, and leads the authors of SRFI's to believe, erroneously, that they have the authority to revise the standard. But, process quibbles aside, this reveals a deeper issue. This draft intends to constrain implementations from opportunistically providing exact results or seeking to provide exact results where other implementations or representations cannot. This amounts to treating inexactness in some circumstances as a *desirable* property of numbers. I strongly suspect that if inexactness has become a desirable property, then it is most likely because of one or more design mistakes. This is like deriving a known-false result in mathematics; it indicates that at least one of the steps along the way was wrong, and subsequent steps, including the present SRFI in dealing with inexactness, therefore invalid (in proceeding, perhaps correctly, from erroneous premises). I believe that it indicates that one or more of the uniform-numeric-vector SRFI's is in conflict with Scheme's basic design principles (the preference for exact calculation where possible) and in need of redesign. Bear

**Follow-Ups**:**inexactness vs. exactness***From:*Aubrey Jaffer

**References**:**Revision of SRFI 70 available***From:*Michael Sperber

- Prev by Date:
**Revision of SRFI 70 available** - Next by Date:
**Re: Nitpick with FLOOR etc.** - Previous by thread:
**Revision of SRFI 70 available** - Next by thread:
**inexactness vs. exactness** - Index(es):