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

> 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]