[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>
>>> 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.
> 
> integer-range is not feasible because in the current implementation
> for most machines the memory for representing the maximum overflows
> earlier than the theoretical limit of the representation. The actual
> range is not well defined for this reason.
> 
> Arithmetic is definitely not modular wrt. this range. Overflow of
> bignums should generate exceptions, but since it's unimplementable
> with my choice of the bignum library (GMP), the current implementation
> crashes. This is a known bug which won't be fixed in the foreseeable
> future.

- then possibly (exact-integer-precision) could be defined to return
  an implementation's warranted maximum signed log2 precision, thereby
  even an implementation which supported only supported a minimally
  required precision of at least 16 bits, could return a value as
  large as ~2^15 (which seems sufficiently large enough to enable a
  bignum implementation to support nearly indefinite precision, while
  being able to bound it's maximum memory requirements, and return some
  defined standard semantic behavior/value upon an overflow otherwise).

  And possibly (exact-fractional-precision) could be defined analogously
  to return an implementation's warranted minimum log2 signed fractional
  precision, thereby a value of 0 [i.e. (log2 0) => 1] means only integers
  are representable exactly; a value of -16 means fractional values as
  small as (log2 -16) => 1/(2^16) may be represented precisely, etc...

  Thereby an implementation's exact precision may be characterized, and
  potentially even modified if it were defined that these functions could
  be passed a parameter; thereby (exact-integer-precision 128) could
  return #t if accepted, or return #f otherwise.