[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*: srfi-70@xxxxxxxxxxxxxxxxx*Subject*: Re: infinities reformulated*From*: bear <bear@xxxxxxxxx>*Date*: Sat, 4 Jun 2005 09:42:21 -0700 (PDT)*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050602161228.B3E3D1B77B4@xxxxxxxxxxxxxxxx>*References*: <20050531071658.EC10C1167@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050531234805.0EC7F1B77B4@xxxxxxxxxxxxxxxx> <874qcgg4uf.fsf@xxxxxxxxxxxxxxxxx> <20050602161228.B3E3D1B77B4@xxxxxxxxxxxxxxxx>

On Thu, 2 Jun 2005, Aubrey Jaffer wrote: > | From: Thomas Bushnell BSG <tb@xxxxxxxxxx> > | There is no function "precision-of", so there is no need for an > | answer. Arbitrarily big precision arithmetic (generally) works pretty > | well; you carry around symbolic representations and operate on them. > >To first order: > > (define (precision-of x) (string-length (number->string x))) > >R5RS requires all numbers to have external representations; and it >specifies the allowed formats. I think the relevant section here is where it says that (paraphrase) when exact numbers are operated on in such a way as to produce inexact results, the results should have at least as much precision as the most precise hardware floating-point representation available. I read this as forbidding (or at least recommending against) immediate floating-point representations that fit in 32 bits and truncate the mantissa for a typetag. So, when A) you take (sqrt 2) and B) 2 is an exact number, and C) your implementation cannot represent the result exactly, the standard requires (or at least recommends) that your implementation return a result with at least the "greatest hardware precision available", which in most cases will be, I believe, what the C compiler refers to as a "long" or "double" precision float. But this is, of course, subject to some interpretation by different implementors; Nothing in R5RS says that the hardware representation must be used; only that at whatever is used must provide at least as much precision. A squared, cubed, or n'th-powered representation may be available to represent square roots, cube roots, or nth roots exactly, for example. A logarithmic representation where the number stored is an integer power of 1+epsilon may be used. Etc. For heavy math work, I want to be able to specify the precision used, in one of several ways; For example, by saying (with-inexact-precision 128 ... (sqrt 2) ...) or (sqrt 2 :precision 128) or (without keywords) (sqrt 2 128) or something. I think someone else has suggested that there ought to be a different sqrt function for each desired precision, but I don't like that method as much. Bear

**Follow-Ups**:**Re: infinities reformulated***From:*Aubrey Jaffer

**References**:**Re: infinities reformulated***From:*Chongkai Zhu

**Re: infinities reformulated***From:*Aubrey Jaffer

**Re: infinities reformulated***From:*Thomas Bushnell BSG

**Re: infinities reformulated***From:*Aubrey Jaffer

- Prev by Date:
**Re: My suggestions to the R6RS committee about numerics** - Next by Date:
**Re: [srfi-70] Limit** - Previous by thread:
**Re: string->number** - Next by thread:
**Re: infinities reformulated** - Index(es):