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.
Thomas Bushnell BSG <tb@xxxxxxxxxx> writes: > It's not. There may actually be programs out there that depend on > exact division doing the mathematically right thing. You want to > break them all? There must have been some misunderstanding. I don't want to change / from performing exact division if given exact arguments (rational or complex-rational). I want to make more predictable when the programmer will obtain a ratnum and when a flonum. And I want him to be sure that he will not obtain some weird representation like "a ratnum with inexactness bit" or "fixed-size decimal fraction" without explicitly asking for it. >> (The difference between fixnums and bignums should not be exposed >> except perhaps by some weird functions used as an efficiency hack. >> Other representations are important though.) > > See, this is where you're wrong. Constant-width addition is valuable > for integers too, not just floats. But when people doing integer > arithmetic want that, it's an "efficiency hack", and when you want it > for floating point, it's Absolutely Essential. What do you mean by constant-width addition? a) Addition modulo 2^N, where N is a well-defined number like 32. b) Addition of integers which the given implementation can represent more efficiently than others, where the programmer hopes that the range will be sufficient for his needs (e.g. they are indices into a vector), and he values efficiency very much. My answers: a) is a legitimate need which should be fulfilled by other operations than the standard + (because + is already agreed on to do a different thing for integers), or at most by other type than standard integers. I'm not convinced that Scheme should provide this in the standard though, because the need is quite rare, and Scheme aims to be minimalistic. There are other unstandarized features which are much more important, like read-line and hash tables. b) is an efficiency hack, because the wanted behavior is a subset of the standard + and because it's unsafe (i.e. has either undefined behavior or a clearly wrong outcome when misused). It makes sense only when it's unsafe; checking types and checking for overflow is about as costly as switching to bignums when needed. Fixed-size floating point arithmetic differs in that it's safe, that people expect it to be slightly inexact (or should be taught to expect this), and that often the performance difference between fixed size floating point and exact ratios is huge, while the difference in the answer is small. Of course the programmer can use exact ratios instead if he chooses. It should be his choice, not the Scheme implementor's choice. > I think the best way to provide it is by functions that cleary specify > which behavior they get, preserving backward compatibility with the > existing standard. Letting (+ 1.2 3.4) perform fixed-size binary floating point arithmetic is compatible with both the existing standard and common practice. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/