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

*To*: Alan Watson <a.watson@xxxxxxxxxxxxxxxx>*Subject*: Re: Some comments relating to ICFP contest*From*: bear <bear@xxxxxxxxx>*Date*: Mon, 4 Sep 2006 10:31:02 -0700 (PDT)*Cc*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, Andre van Tonder <andre@xxxxxxxxxxxxxxxxx>, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20060726083636.M20092@xxxxxxxxxxxxxxxx>*References*: <Pine.GSO.4.60.0607251525060.12732@xxxxxxxxxxxxxxxxx> <y9lodvdrm96.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20060726083636.M20092@xxxxxxxxxxxxxxxx>

On Wed, 26 Jul 2006, Alan Watson wrote: > Consider data types with 32 bits and 64 bits but which are not > numbers in the sense that the generic arithmetic operations cannot > be used with them without an explicit conversion. Appropriate type- > specific arithmetic and logical operations could be defined for > these types. This would not be especially difficult to implement in > a well-designed Scheme. I agree with this. Once you're worried about exact width in bits you're not using them as numbers any more. They are bitfields, and they have a beginning and an end. There should be "bitmath" operators that do (well-defined modular) math on bitfields assuming particular binary representations of numbers, to the same extent that there should be "bitstring" operations that do well-defined character-manipulation operations on bitfields assuming particular binary representations of strings. But we should not guarantee errors in the math routines we use on (generic) numbers; an overflow or roundoff error is just that, an error, and the standard ought never prohibit an implementor from trying to avoid errors. Nor should we ever guarantee that certain values cannot be represented as numbers, because once again that puts the standard in the position of requiring errors. Bear

**References**:**Some comments relating to ICFP contest***From:*Andre van Tonder

**Re: Some comments relating to ICFP contest***From:*Michael Sperber

**Re: Some comments relating to ICFP contest***From:*Alan Watson

- Prev by Date:
**Re: div0 and mod0** - Previous by thread:
**Re: Some comments relating to ICFP contest** - Next by thread:
**Re: Some comments relating to ICFP contest** - Index(es):