[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

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.

 | Date: Fri, 21 Oct 2005 09:38:58 -0700 (PDT)
 | From: bear <bear@xxxxxxxxx>
 | On Fri, 21 Oct 2005, John.Cowan wrote:
 | >Aubrey Jaffer scripsit:
 | >
 | >> I recommend 12.bits minimum precision for both fixnums and
 | >> flonums.
 | >
 | > I think that's way too small, particularly if we are going to
 | > explicitly adopt CL's link between fixnums and {string,vector}
 | > indices.
 | Agreed.  R5RS requires an implementation to support "exact
 | integers" through the range that can be used as vector indices,
 | which IMO is the right thing.  To state that the implementation is
 | not allowed to have arrays accessed by non-fixnums is a needless
 | limitation, especially if the fixnum range is chosen very small.
 | 12 bits, minus one for negative numbers, would mean *all* vectors
 | restricted to less than 1023 elements, and that's uncomfortably
 | small.

My 12.bit recommendation was a minimum for fixnums.  Bignums could be
larger; hence indexes could be larger.  We would expect to encounter
this minimum in toy implementations.  My reasoning was that software
is still being developed for 16.bit processors for many products;
12.bit allows for immediate integers in a 16.bit word.

 | As for strings, pfah.  If you work in corpus linguistics it's not
 | too uncommon to have literally millions of characters in a string.
 | I'd really hate to see strings limited to 1023 characters.

That argues against limiting string lengths to fixnums.

 | >> Being error objects, syntax for NaNs should be unspecified.
 | >I don't see how that follows.
 | He means that NaNs should arise from error operations, not from
 | the normal functioning of the reader.  If (read) returns an error
 | object, it should mean that (read) encountered an error.

Your comments motivated changing srfi-70 so that NaNs became error
objects.  As you also pointed out, there are many different NaNs
possible.  Specifying that all of them print as +nan.0 destroys their

I think that an implementation should be allowed to signal an error
under some conditions where an error object is encountered.  Mandating
readable written representations for error objects prevents an
implementation from signaling such errors.