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

*To*: Paul Schlie <schlie@xxxxxxxxxxx>*Subject*: Re: Error objects in general*From*: "John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>*Date*: Sun, 30 Oct 2005 11:30:30 -0500*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF8A2EDD.BF4C%schlie@xxxxxxxxxxx>*References*: <BF8A2918.BF49%schlie@xxxxxxxxxxx> <BF8A2EDD.BF4C%schlie@xxxxxxxxxxx>*User-agent*: Mutt/1.4.2.1i

Paul Schlie scripsit: > Overall the question is: if NaN's (aka <indeterminate>/<void> values) are > to be embraced, should their observable effect be more generally defined > throughout the entire language specification? (As otherwise the ambiguities > they represent may either be obscured by subsequent evaluations, or result > in potentially undesirable non-easily foreseen halting errors?) > > [or alternatively should all arithmetic operations always return well > specified deterministic numeric values, thereby eliminating the otherwise > necessity for a <indeterminate>/<void>/<nan> value object?] This is the fallacy of false dichotomy. All flonum arithmetic operations do always return well-specified deterministic values; however, some of them are not numbers. What's more, this is what all Scheme implementations on non-ancient hardware provide in practice. A NaN is not an indeterminate value; it is a determinate non-numeric value, disjoint from all other Scheme values. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.reutershealth.com pleasures in life.... http://www.ccil.org/~cowan --Jeni Tennison <jcowan@xxxxxxxxxxxxxxxxx>

**References**:**Re: Error objects in general***From:*Paul Schlie

**Re: Error objects in general***From:*Paul Schlie

- Prev by Date:
**Re: Error objects in general** - Next by Date:
**Re: Error objects in general** - Previous by thread:
**Re: Error objects in general** - Next by thread:
**Re: Error objects in general** - Index(es):