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