[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: arithmetic issues
William D Clinger wrote:
Would the following proposal satisfy your goals:
(a) Mandate unlimited size exact integers in the base language.
(b) Push fl+ et al. off into a library module.
No. The fundamental problem with R5RS arithmetic is that
programmers cannot rely on the behavior of the arithmetic
primitives. Mandating exact integers of unlimited size
would help, but programmers would still not know whether
(/ 3 4) will evaluate to 3/4, 0, 1, or 0.75.
To solve this problem, we have to require some subset of
the tower that has reasonable closure properties, while
banishing any arithmetic operations that are not closed
over that subset. We have to do both.
I agree. I would propose that the arithmetic procedures in the base
language be closed over exact integers of unlimited size; that is, I
would banish / and other procedures that are not closed. (Or, maybe,
force them to signal an error, if a suitable error handling mechanism is
defined.) Programmers would then know exactly (sic) the result of all
arithmetic operations in the base language.
Then, I would either mandate the full tower in the library or mandate
SRFI-77 flonum operations in the library. These give the programmer the
full tower, either directly or by using (a modified version of) your
I understand this is postulating some means to push the SRFI-77
operations off into a library, but I don't see the problem. I am not
proposing that SRFI-83 implement a general means to import different
In my opinion, two fairly extreme positions are the most
attractive. Either require the full tower as part of the
base language, or require only the fixnum/flonum foundation
while banishing + and the other generic operations to the
I think the major difference between us on this issue is that you think
that modular fixnum arithmetic is adequate for the base language whereas
I do not. I want exact integers of unlimited size because I can see an
argument[*] for making fixnums smaller than the size needed to reference
the largest possible list, string, or vector, and I cannot imagine the
base language not completely defining these operations.
I also like the idea of the arithmetic operations following standard
arithmetic rather than modular arithmetic.
[*] For example, making fixnums 16-bits wide on a 32-bit machine to
allow for quick determination of overflow on multiplication.
Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México