Dr Alan Watson wrote:
> Now, can we agree here that my reasons for using single-precision
> vectors for arguments and results are valid? (I concede that such
> vectors are beyond the scope of SRFI 77.)

I agree with that.

> Let us suppose that the result calculated using single-precision
> operations on some specific arguments is S, that the result calculated
> using double-precision operations on the same arguments (converted to
> double precision) is D, and that the result of truncating D to single
> precision and converting back to double precision is T.
>
> The problem is that there are relations that are satisfied by S or T but
> not by D.

True.

> In practice, calculating T is less convenient for programers; they have
> to remember to do the explicit conversion. However, it is much less of a
> burden on implementors than forcing them to provide single-precision
> arithmetic. Furthermore, it can be accomodated quite naturally even in
> Schemes that do everything in double precision.

To put your argument into perspective, consider double
precision on the IA32.  That architecture's implementation
of double precision arithmetic is not quite correct---it
has the very problem you described in your example.  While
it is possible to perform IEEE-754 double precision arithmetic
correctly on the IA32 architecture by writing every intermediate
result to memory, this correct implementation is so much slower
that most programmers who use double precision on the IA32 prefer
to keep intermediate results in floating point registers despite
its incorrectness.

If you choose to argue that implementors should be required
to solve this problem for single precision arithmetic, then
why aren't you arguing that implementors should be required
to solve it for double precision arithmetic on the IA32?

Will