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