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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*To*: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>*Subject*: Generic Exact Arithmetic*From*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Date*: Thu, 17 Nov 2005 16:27:12 +0100*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <A1C23F2C-9999-489E-94E2-6F4F3190E4AB@xxxxxxxxxxxxxxx> (Bradley Lucier's message of "Tue, 18 Oct 2005 15:01:24 -0500")*References*: <A1C23F2C-9999-489E-94E2-6F4F3190E4AB@xxxxxxxxxxxxxxx>*User-agent*: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5-b21 (darwin)

Bradley Lucier <lucier@xxxxxxxxxxxxxxx> writes: >> Should the R5RS procedures for generic arithmetic (e.g. +) > remain in R6RS? Here are five possible answers, phrased in terms of > the + procedure: >> >> 1. + is not defined in R6RS. >> 2. + is defined to be a synonym for the ex+, so its domain > is restricted to exact arguments, and always returns an exact result. >> 3. + is defined as the union of the ex+ and in+ procedures, > so all of its arguments are required to have the same exactness, and > the exactness of its result is the same as the exactness of its > arguments. >> 4. + is defined as in R5RS, but with the increased > portability provided by requiring the full numeric tower. This > alternative is described in the section R5RS-style Generic Arithmetic. >> 5. + is defined to return an exact result in all cases, even > if one or more of its arguments is inexact. This alternative is > described in the section Generic Exact Arithmetic. >> >> Will Clinger prefers the 4th possibility, Mike Sperber the 5th. > > I have real difficulties with 5, which I hope to expand on at a later > time. Part of the problem is that 5 assumes that inexact->exact > gives reasonable results on inexact arguments, and I can't see how > this can be true if, for example, inexacts are implemented as the > computable reals. This is not correct, but I see how the way SRFI 77 is written would make you think so. The problem in presenting the material was that going with Generic Exact Arithmetic induces more far-reaching changes in R5RS's arithmetic model than is completely specified in the SRFI, mostly in the construction of the tower and the numerical predicates. This was the best I could do given the time I had for now, and I apologize for the shortcomings of the presentation. I ask people interested to refer to the paper for more rationale. Specifically, this arithmetic model assumes that its procedures accept only inexact reals that have a single, reasonable exact counterpart. We were mostly thinking in the IEEE universe, where each inexact real that isn't an infinity or NaN corresponds to a single rational number, which we know how to represent. It is probably possible to imagine an arithmetic model with a more fancy representation of reals (both inexact and exact) which makes the relationship between the exact numbers and inexact numbers more complicated, but that would probably not be very practical. It's also not very common among existing Scheme systems. > [...] > The paper > > [Egner et al. 2004] Sebastian Egner, Richard Kelsey, Michael > Sperber. Cleaning up the tower: Numbers in Scheme. In Proceedings of > the Fifth ACM SIGPLAN Workshop on Scheme and Functional Programming, > pages 109--120, September 22, 2004, Snowbird, Utah. Technical report > TR600, Computer Science Department, Indiana University > > is cited as justification for several parts of this proposal. > Unfortunately, I believe this paper to be seriously flawed. > > I'm bringing this up for the following reason: I don't believe that > this paper can be used, by itself, as justification for any aspect of > this proposal. It may be used as an *argument* for certain aspects > of the proposal, but as there has been no general discussion of the > merits of the paper, either in this forum or in others, I don't > believe that it can be used as "settled decisions". Thus, if the > authors of this SRFI wish to use arguments from that paper as > justification for certain aspects of *this* proposal, they should > repeat those arguments here for them to be discussed and debated as > usual. It wasn't our intention to present the paper as "settled decisions." (You can see that from the simple fact that Will Clinger doesn't agree.) Instead, our intention was exactly as you suggest, to provide an argument of why Generic Exaçt Arithmetic is in the proposal. It's not clear to me how repeating the arguments set forth in the paper would achieve anything---the paper is archived for the foreseeable future, as are other pieces of related work somebody might disagree with. So it would help greatly if you elaborated on what you think the flawas of the paper are. (I can see that the paper is flawed in aspects of its presentation, as the misunderstanding described above shows, but haven't seen much argument that its substance is equally flawed.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

**References**:**Some preliminary comments***From:*Bradley Lucier

- Prev by Date:
**Re: Contagious Inexactness, revision 2** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Some preliminary comments** - Next by thread:
**FIXNUM (aka Re: Arithmetic issues)** - Index(es):