Re: arithmetic issues William D Clinger (20 Jan 2006 22:38 UTC)
Re: arithmetic issues Paul Schlie (21 Jan 2006 01:45 UTC)
Re: arithmetic issues Paul Schlie (21 Jan 2006 02:54 UTC)

Re: arithmetic issues Paul Schlie 21 Jan 2006 01:45 UTC

> From: William D Clinger <xxxxxx@ccs.neu.edu>
>> Paul Schlie wrote:
>> ...
>Bounded exact numbers are not closed under arithmetic operations.

- agreed, they're not arithmetically clean.

>> - 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.

- I was presuming the semantics of (<type> <function-or-operand>)
  would be evaluation context sensitive, thereby <functions> remain
  predominantly type-less:

  - if appearing within the <function> position of an <expression>:

  ((<type> <function>) <operand> ...) :: (<function> (<type> <operand>) ...)

  - if appearing within an <operand> position, it returns that data <type>:

  (<function> (<type> <operand>) ...) :: (<function> <operand-type> ...)

- however as you implicitly suggest, if applied in the function position it
  may alternatively select a <function-type> if defined. Thereby:

  - if appearing within the <function> position of an <expression> and
  <function-type> exists:

  ((<type> <function>) <operand> ...) :: (<function-type> <operand> ...)

  otherwise:

  ((<type> <function>) <operand> ...) :: (<function> (<type> <operand>) ...)

  - if appearing within an <operand> position, it returns that data <type>:

  (<function> (<type> <operand>) ...) :: (<function> <operand-type> ...)

>     ((<float> list) 1.1 2.2)
>  =  (list (<float> 1.1) (<float> 2.2))
>  =  (list 1.1 2.2)

- yes, or (<list-float> 1.1 2.2) if defined.

>     ((<float> list) + -)
>  =  (list (<float> +) (<float> -))
>  =  (list flo+ flo-)

- yes, presuming <+-float> and <--float> were defined?

>     ((<float> +) 1.1 2)
>  =  (+ (<float> 1.1) (<float> 2))
>  =  (+ 1.1 2.0)

- yes, or (<+-float> 1.1 2) if defined?

>     ((<float> +) 1.1 -)
>  =  (+ (<float> 1.1) (<float> -))
>  =  (+ 1.1 flo-)

- yes, or (<+-float> 1.1 -) if defined.

>     ((<float> +) 1.1 'a)
>  =  (+ (<float> 1.1) (<float> '#(2.2)))

- sorry, not sure what the point was here?

>  =  (+ 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.

- personally I wouldn't expect ((<float> +) 1 'a) to be any less
  sensitive to inconsistent operands than I'd expect (+ 1 'a) to be.