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

Re: arithmetic issues

> From: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>
>> Paul Schlie <schlie@xxxxxxxxxxx> 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]