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 15:55 UTC

> From: Marcin 'Qrczak' Kowalczyk <xxxxxx@knm.org.pl>
>>> 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.