Re: arithmetic issues William D Clinger (19 Jan 2006 05:58 UTC)
Re: arithmetic issues Paul Schlie (20 Jan 2006 21:43 UTC)
Re: arithmetic issues Marcin 'Qrczak' Kowalczyk (20 Jan 2006 23:19 UTC)
Re: arithmetic issues Paul Schlie (21 Jan 2006 02:17 UTC)
Re: arithmetic issues Marcin 'Qrczak' Kowalczyk (21 Jan 2006 10:51 UTC)
Re: arithmetic issues Paul Schlie (21 Jan 2006 15:56 UTC)
Re: arithmetic issues Michael Sperber (21 Jan 2006 10:52 UTC)

Re: arithmetic issues Paul Schlie 21 Jan 2006 02:17 UTC

> From: Marcin 'Qrczak' Kowalczyk <xxxxxx@knm.org.pl>
>> Paul Schlie <xxxxxx@comcast.net> writes:
>> - Personally, it seems reasonable to require that a base implementation
>>   support only finite modular integers with a precision sufficient to
>>   represent the larger of:
>>
>>   (integer-range) => <max-positive-representable-integer> or
>>
>>   (length <list-of-all-allocatable-elements-for-a-given-implementation>)
>
> My toy Scheme interpreter is hosted by a language with native bignums,
> and no distinction between fixnums and bignums in the public API.
> A requirement to support modular arithmetic would be inconvenient here.

- then (integer-range) for your implementation would be fairly large, and
  no ambiguity exists unless the maximum bignum value is overflowed.

> (Actually the hosting language does have some unsafe fixnum-only
> operations, but I'm not sure whether to treat them as public.)

- unless I misunderstand, unless a bignum implementation supports unbounded
indefinitely large values (which basically means that an arithmetic
computation may crash a program if requiring more memory than available be
allocated to return an arbitrarily large value), then it seems reasonable
that even bignum implementations should support some bound; and the question
then becomes, what are the semantics of an operation which arithmetically
overflow's the result's bound or insufficient memory exists to safely
allocate to that result (i.e. modulo, +/- Inf, or NaN return value)?

[throwing an exception is most likely less desirable than simply knowing
 that a well defined overflow behavior will result if a value exceeds some
 maxium range, even (or especially) for bignums, as there's no magic in the
 world, they simply can't be indefinitely large]