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/