[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*: 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):