[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*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Unifying the two generic arithmetic alternatives*From*: Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx>*Date*: Tue, 15 Nov 2005 05:29:09 -0800 (PST)*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

I wrote: > > Note that a floating point number (aside from INF and NaN) represents > > one and precisely one rational number. Thus to perform an accurate > > calculation with a flonum, we simply use its actual value. John Cowan writes: > the result of flonum addition interpreted as a rational number is *not* > accurate. You are correct. However, my wording must be unclear. I am not suggesting that accurate calculations can be performed with flonum operations. Can anyone help me out here? I read what I wrote, and it seems to me to say what I meant. I do not know how to reword it so that other people will not find it confusing. John Cowan writes: > Indeed, even without control flow as such the idea is bizarre. If x > and y are inexact numbers, is the value of (if (< x y) "foo" "bar") > an inexact string? Yes. Each rational number represents one and only one number, each string represents one and only one string. Your result is flagged as having been calculated using approximate operations. I wrote: > > FAST+ always performs a fast (if perhaps inaccurate) operation -- > > returning a flonum, or a complex number made up of flonums. John Cowan writes: > Why a flonum? Addition of two fixnums with no overflow should be > able to return a fixnum, no? I agree. Bear writes: > I think most implementors are going to dislike it because it > means they have to treat exactness as a bit independent from > the representation format. No doubt. A lot of implementors don't like CALL-WITH-CURRENT-CONTINUATION either. So? Bear writes: > But honestly, I think that we're not really going to have an > adequate solution for this problem until the precision to > which each number is known is part of the semantics of the > language. Not just a bit to say whether that precision is > "infinite" or not. What is the problem that you'd like to solve? Bear writes: > There seem to be no pressing engineering problem that [inexact > strings and symbols] solve in a way that people find satisfactory. I'm not going to advocate that contagious inexactness be a part of R6RS. However I will point out: * Some people want contagious inexactness. * Some people want it badly enough that they support R5RS style generic arithmetic, despite its well known problems. I do argue that if contagious inexactness is going to be in R6RS, it should: * be done correctly * avoid pedagogic confusion in the classrom * not lead to pernicious bugs in production software Bear writes: > This has disturbing implications that I think most people aren't > ready to embrace; namely, inexact strings and symbols. This is a terminology issue. There's nothing distrurbing about being given the result of a calculation and also being told that it is not guaranteed to be accurate or reproducible, having been derived from approximate operations. The problem is that people are used to thinking of *numbers* as being inexact, and then in that mindset saying that's it's nonsensical for strings and symbols to be inexact. However, with flonums it's not the *number* that's inexact, it's the flonum *operations* that are inexact. Would using a different terminology would help people understand the concepts more easily? I'm not tied to "EXACT?" and "ACCURATE+" as wording. From the responses so far, (exact? "a string") appears to be immediately confusing to most people. Thanks, Andrew

**Follow-Ups**:**Re: Unifying the two generic arithmetic alternatives***From:*Dave Mason

- Prev by Date:
**Re: Unifying the two generic arithmetic alternatives** - Next by Date:
**Re: Unifying the two generic arithmetic alternatives** - Previous by thread:
**Re: Unifying the two generic arithmetic alternatives** - Next by thread:
**Re: Unifying the two generic arithmetic alternatives** - Index(es):