[r6rs-discuss] Why are fx+ and fx* restricted to two arguments

From: William D Clinger <will>
Date: Mon Feb 19 11:12:09 2007

I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors.

Mikael Tillenius wrote:
> However wouldn't it be useful to define "(fx+ x1 x2 x3 ...)" as
> equivalent to "(fx+ (fx+ x1 x2) x3 ...)", that is specify fx+ as doing
> pair-vise addition of its arguments in a specified order checking for
> overflow after each pair? Similar for "fx*".

It would be convenient, but whether its net usefulness
would be positive depends upon the cost you assign to
unexpected exceptions and to the degree of forethought
encouraged by providing these procedures only in binary
form. The first is arbitrary, but the second could in
principal be addressed by an empirical study. At the
moment, we have little beyond the anecdotal fact that
you thought enough about it to start this thread.

> Related to the above, how is ordinary "+" for handled. According to
> IEEE, + (and -, *, /, sqrt) should first be done _exact_ and then
> rounded. Of course IEEE speeks only about binary "+".

The +, -, /, and fl+ procedures do not raise exceptions
on overflow. The ordering is implementation-dependent,
but that generally affects roundoff error only, which
cannot lead to exceptions within the procedures you
named.

> Do we compute the
> exact sum of all arguments and then round or do we add and round pairs
> of numbers? If so, in what order? Same for "fl+".

When all of the arguments are exact, the result will
also be exact and the order doesn't matter. When one
or more of the arguments are inexact, implementations
are allowed to compute the exact sum, in any order
they desire, before delivering an inexact result, but
I doubt whether any implementations do that. Most
use some fixed implementation-dependent order,
computing exactly so long as the arguments are exact,
and then switching to inexact computation when the
first inexact argument is encountered.

Programmers who want complete control over the order
can express their desires by writing binary operations.

That is consistent with the recommendations contained
within appendices B and C of the October 2006 draft
of IEEE-754R. I haven't checked the more recent draft,
and I should note in any case that the draft R6RS does
not propose to require IEEE floating point arithmetic.

Will
Received on Mon Feb 19 2007 - 11:11:54 UTC