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.

> 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:

Option a violates R5RS section 6.2.5, which says "For any Scheme number,
precisely one of these predicates is true."

Option b is ruled out by R5RS 6.2.3, which says "An implementation of
Scheme must support exact integers throughout the range of numbers that
may be used for indexes of lists, vectors, and strings."  Consequently,
even the most useless Scheme system must support at least #e0.

Option c is conceivable, but you are compelled to make sure that all
flonum operations that produce inexact results report implementation
violations, which is hardly practical.

> 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.

> 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.

> 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).

> If the Report does allow multiple towers (which I think is a
> foregone conclusion), a built-in procedure with a name something
> like numeric-features should be required, this will allow portable
> code to verify that it is running on a sufficiently-capable
> system. numeric-features could return a list of tower criteria that
> the system supports. The criteria, and their symbol names, should be
> defined by the Report.

I've approached this with a set of cond-expand names, but the WG hasn't
voted on them yet.

> Finally, I can't leave the subject of numeric towers without putting in
> a plug for decimal floating-point values as per the current revision
> of IEEE-754. This of course would be for WG2, and VERY definitely not
> WG1, but there are important reasons why modern programming languages
> ought to support this data type (at least as an optional library). For
> more information on the reasons for supporting decimal arithmetic
> (unnormalized decimal floating-point, not your granny's decimal fixed
> point, if your granny is named COBOL), please see Mike Cowlishaw's page
> at http://speleotrove.com/decimal. I hope that this can be placed on
> WG2's list of topics to consider.

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.

I'm going to post your letter with some of these comments (excluding
the 754r stuff) to NumericTower.

--
After fixing the Y2K bug in an application:     John Cowan
        WELCOME TO <censored>                   cowan@ccil.org
        DATE: MONDAK, JANUARK 1, 1900           http://www.ccil.org/~cowan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports