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

*To*: schlie@xxxxxxxxxxx, will@xxxxxxxxxxx*Subject*: Re: arithmetic issues*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Fri, 20 Jan 2006 17:38:25 -0500*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

Paul Schlie wrote: > - seemingly a good reason for indefinitely precise exacts to be optional, > and/or for them to bounded similarly to floats (and have the same > dynamic range; thereby each float may map to a corresponding bounded > exact, and each exact may map to a float within its precision.) Bounded exact numbers are not closed under arithmetic operations. > - just meant to state the opinion that it seems more elegant > to preserve type-less operators, which may be extended with > a cast syntax which extends beyond the operator to cast it's > operands, i.e. in lieu of a typed +fl etc. > > ((<float> +) x y ...) :: (+ (<float> x) (<float> y) ...) That may seem more elegant, but consider these examples, where I write flo+ and flo- to mean versions of the + and - procedures that coerce their arguments to flonums before adding or subtracting them. ((<float> list) 1.1 2.2) = (list (<float> 1.1) (<float> 2.2)) = (list 1.1 2.2) ((<float> list) + -) = (list (<float> +) (<float> -)) = (list flo+ flo-) ((<float> +) 1.1 2) = (+ (<float> 1.1) (<float> 2)) = (+ 1.1 2.0) ((<float> +) 1.1 -) = (+ (<float> 1.1) (<float> -)) = (+ 1.1 flo-) ((<float> +) 1.1 'a) = (+ (<float> 1.1) (<float> '#(2.2))) = (+ 1.1 ?????) In terms of elegance, it seems sorta random to me for <float> to be the identity on flonums, to coerce other numeric types to flonums, to coerce procedures to procedures that map <float> across their arguments, and to be an error on things that are neither numbers nor procedures. Will

**Follow-Ups**:**Re: arithmetic issues***From:*Paul Schlie

**Re: arithmetic issues***From:*Paul Schlie

- Prev by Date:
**Re: arithmetic issues** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):