[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*: a.watson@xxxxxxxxxxxxxxxx, will@xxxxxxxxxxx*Subject*: Re: arithmetic issues*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Fri, 20 Jan 2006 17:15:42 -0500*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

> > type declarations cannot address the > > portability and predictability issues unless implementations > > are required to interpret those declarations in a consistent > > way. > > By "predictability", do the authors of the SRFI mean that inexact > arithmetic gives the same result everywhere, that (/ 1 2) gives > the same result everywhere, or something else? > > Regards, > > Alan We do not mean that inexact arithmetic will give the same result everywhere. We do mean that (/ 1 2) and similar computations will give the same result everywhere. "Predictability" is my word for what I think Mike means by "transparency". Predictability also has to do with making it easy to ensure that a computation involves only exact or only inexact numbers, which is the main motivation for the exact and inexact operations of this SRFI, and is one of the main motivations for the flonum operations. > I would say that R6RS has to provide arithmetic on exact > integers that are large enough to serve as indexes and > lengths. So, either R6RS must require that fixnums are > large enough or it must provide routines to perform > arithmetic on integers that might be larger than fixnums. That is a good point, and I am in complete agreement. Will

- Prev by Date:
**Re: straw-man [was Re: arithmetic issues]** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):