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: >> I don't know what to expect from inexact real numbers. Do they behave >> like floats, or like ratios with inexactness bit? It does matter! > > So we need a way to query those questions. Querying is too late: when program needs a particular characteristic, it doesn't help it that it could detect that the implementation doesn't meet its expectations. > Scheme doesn't have "flonums" and that's a good and rational design > choice. I disagree. There are programs which require flonums or something which behave similarly. All Scheme implementations I know and all other general-purpose languages I know provide flonums. Consider the example at the end of R5RS run on a typical Scheme implementation with floats and ratios, augmented with displaying all elements of the lazy list it produces. It runs fine. But when we replace the two inexact numbers in the initial state with exact ones of the same values, fractions become bigger and bigger, even though the growing precision it accumulates is useless: the algorithm is inexact to begin with! Consider its format of output, when we use "display" for individual elements. It's fair to assume that it uses the same format as number->string, whose specification has a special clause which forces it to use the decimal notation whenever possible - this is good, and even not enough control the programmer has over the representation. But if the implementation interpreted .01 as something other than a flonum, perhaps as 1/100 with inexactness bit, the decimal format of the output would be incorrect (it wouldn't round-trip) and the implementation would have to use some other format. It's definitely not what the programmer expected, he will consider any other format as wrong and the implementation as broken. Expectations that this program uses the decimal format is technically speaking unportable, although it's true everywhere in practice. This is bad. > So if you want an implementation of + that is guaranteed not to use > more memory in the result than in the operands, we can have that. > No problem. Such a function should also have optional arguments that > specify what happens if the result doesn't fit in the space needed. I want portable flonums. If I don't get it from Scheme, I have plenty of other languages to choose from. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/