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

Re: arithmetic issues

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.



> From: William D Clinger <will@xxxxxxxxxxx>
>> 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.