On 2011-01-06, at 17:56, John Cowan wrote: Vincent Manis scripsit: 1. ----: this seems appropriate in implementations for limited embedded
processors.
The trick is here to make sure that / returns the right answer or reports an implementation restriction, which is often not done.
Agreed. I'm happy on such an implementation if / fails for a nonzero remainder, as long as it's documented. 2. --+-, --++: there seem to be two kinds of possible implementation:
a Chicken-like system that provides fixnums and flonums, and a system
that provides flonums only (and therefore there is no such thing as
an exact integer). Lua, with default build options, works this way,
as does _javascript_. Both variations seem defensible to me.
The second kind of implementation is very unlikely to be be conformant, for it entails that either (a) all numbers are both exact and inexact, (b) all numbers are inexact, or (c) all numbers are exact:
Agreed that R5RS prohibits it. I was just pointing out that it is possible to design a Scheme-like language that supports the second kind. I don't really want it, but was merely putting its potential existence on the table. 3. +-+-, +-++: I believe that the implication here is that bignums
are provided as well.
Yes, provided you don't get hung up on the bigness of the bignums. A system could have a really small range of exact integers, but as long as it reports an implementation violation rather than producing an inexact result, it is technically exactness-preserving. I think this is unlikely in any system with inexact numbers.
An implementation that used only fixnums, and carefully reported implementation violations, would indeed be correct wrt R5RS. Such an implementation would be valid, but hardly very popular. Adding complex numbers to an implementation that doesn't support them
can be done almost entirely as a library module, apart from issues such
as read and write syntax.
If your implementation is carefully written, all you have to do is hook NUMBER->STRING and STRING->NUMBER, as Chicken does.
The only other thing might be error handling. Since I don't have much of an idea what WG1's error handling will look like, other than that error will be provided, it's not clear to me whether this is an issue. I therefore think that there are three defensible core towers, namely
(a) ----, (b) --+-, and (c) +-+-, [...]
I hope that the Report can be written in such a way that this smaller
number of towers is either preferred or required.
So you are basically ruling out bignums with flonums, the -x+x towers (x = don't care).
I intended to rule out --++, but did want to keep --+-. Or did I misunderstand your comment? I've approached this with a set of cond-expand names, but the WG hasn't
voted on them yet.
I withdraw my request for numeric-features, I had forgotten (or not known) that WG1 intends to include cond-expand. <my comments on decimal arithmetic>
I'll add this to the list of things for WG2 to consider providing.
AFAIK they are inexact rationals with different restrictions than the
usual sort of flonums.
Exactly. They fit quite well along with regular flonums into a maximal ++++ tower, though there might be some tweaking about compatibility with other numeric types. Decimal floating-point also might bring back issues about multiple precisions, which I believe WG1 has decided not to support, though I don't know about WG2. I don't feel that's a big deal, though.
-- vincent
|