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.
Thank you, Marc, for your comments and for your correction to the specification of flexpt. When such corrections are reported, I have been making the changes and committing them to the R6RS version control system. Marc Feeley wrote: > I have noticed that the specification of flexpt, flsqrt, > flatan and many other procedures may return a meaningless > result for certain ranges of arguments. It would be better > to say "it is an error", so that Scheme systems that wish > to do so can signal an error in these cases to improve > debugging. Scheme implementations would still be allowed > to return a meaningless result, if that simplifies > implementation or improves performance. Another reason for returning a meaningless result (usually a NaN) is that this is standard practice in most languages that use IEEE floating point. If you identify some of the fl operations with the corresponding operations of IEEE-754, then the IEEE standard could be interpreted (in some cases) as requiring the procedure to return a NaN without raising an exception. The problem with saying "it is an error" is that this phrase has often been misinterpreted to mean that an error *should* be signalled. As you may recall, the R6RS editors once considered the possibility of requiring all "is an error" situations of the R5RS to signal an error, which would have been a huge mistake IMO. I agree that the fl procedures should be allowed to raise an exception whenever they are allowed to return a NaN or meaningless value, but they should not be required to raise an exception in those cases. > What is the rationale for flodd? and fleven? . I don't > see a need for these operations. One rationale is to simplify construction of generic arithmetic and the full numeric tower from the fixnum and fl procedures. This is not a compelling rationale, because flodd? and fleven? can be written pretty easily using the other fl procedures. A more compelling rationale is that parallelism between the fl and generic primitives simplifies the porting process you described. > Note that a small specification change for fl+ and fl* > would be required because when applied to no arguments > they return inexact 0 and 1 respectively, whereas + and > * return exact 0 and 1 respectively. Good point. > Either the specification for fl+ and fl* in this case > should be changed to return exact 0 and 1, That would change the type of these procedures in a way that interferes with flow analysis, so I would oppose this change. > or these operations should require at least one argument That wouldn't break their closure property, but it would break the porting process you described: changing (+) to (fl+) would not be allowed. In my opinion, using (+) in an inexact computation is probably a performance bug anyway. Changing (fl+) to (+) when porting from R6RS to R5RS would introduce that performance bug. In either direction, the code would probably continue to work. I think it might be better to allow that performance bug than to complicate the porting process. Will