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

*To*: bear@xxxxxxxxx*Subject*: Re: arithmetic issues*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 21 Oct 2005 21:17:13 -0400 (EDT)*Cc*: jcowan@xxxxxxxxxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <Pine.LNX.4.58.0510210910130.18969@xxxxxxxxxxxxxx> (message from bear on Fri, 21 Oct 2005 09:38:58 -0700 (PDT))*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <20051021155906.GC16464@NYCMJCOWA2> <Pine.LNX.4.58.0510210910130.18969@xxxxxxxxxxxxxx>

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

**Follow-Ups**:**Re: arithmetic issues***From:*Thomas Bushnell BSG

**References**:**arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*John.Cowan

**Re: arithmetic issues***From:*bear

- Prev by Date:
**Re: Exactness** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):