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.
Alan Watson wrote: > If an implementation uses more than one floating point representation, > when implementing SRFI 77, the implementor must choose between defining > flonum to refer to only one representation (and thus prejudicing the > others) or to all representations (and thus being less efficient). Thus, > if you have more than one representation, it is difficult to obtain > efficiency without prejudicing certain representations. As you have pointed out, the implementors would also have the option of providing multiple versions of the flonum-specific library, one for each precision. > The only motivation for the flonum-specific part of SRFI 77 seems to be > efficiency. I see a lot of value in portability, even where you may see nothing but efficiency. Portable efficiency is better than implementation-dependent efficiency. > Forgive me if I put words into your mouth, but you seem to be saying > that existing implementations use only one floating-point > representation, therefore it is okay to standardize interfaces that are > well-adapted to such implementations but ill-adapted to implementations > that might use more than one floating-point representation. > > This seems to be an argument for eliminating s, f, d, l, and forcing all > future Schemes to use only one floating-point representation. > Furthermore, it also seems to be an argument for forcing all future > Schemes to use only floating-point representations for inexacts. Yes, it is an argument for both of those things. I still see value in the multiple exponent markers, mainly because they are less verbose than the precision marker of SRFI 77 and follow a convention that is common in other languages, but I could still sleep at night if they were to disappear. As for the other, it wouldn't bother me much if the R7RS were to mandate floating point. > > There is little to be gained by requiring implementations to provide > > modules for every precision when most systems provide only one > > precision. > > Perhaps, but there also seems to be little cost: simply make the short, > single, double, and long floating-point modules aliases for the default > module. That's true. On the other hand, a set of libraries that can be implemented as aliases to an R6RS library sounds like a simple SRFI. Those libraries needn't be mandated by the R6RS. > > Before we mandate some procedure on grounds of efficiency, we should > > measure the efficiency to be gained in some real implementation. > > If you are going to promote interfaces on the basis of efficiency (and > there seems to be no other justification for the flonum-specific part of > SRFI 77), you should expect people to use the same arguments against you. Are you suggesting that the efficiency to be gained from using flonum-specific operations has not been measured in real implementations? Will