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

Re: arithmetic issues



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