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.