On Sun, 2014-04-20 at 21:20 -0400, John Cowan wrote: > 1) Should R7RS-large require arbitrarily large (up to implementation > restrictions like memory) exact integers?
I'd object if the standard required more than 65536 bit representations or allowed smaller than 60-bit representations for exact integers. I would consider any implementation in which it is possible to add two or more like-signed exact numbers and get an opposite-signed exact result to be Wrong, and believe that the standard should specifically forbid that wraparound error. When the range available in exact numbers is overflowed, it should make sense to return an inexact result (the standard should permit but not require this behavior). Therefore I think the standard should require inexact numbers larger (and smaller) than the maximum (and minimum) values representable as exact numbers. This may affect the range of exact integers that an implementation chooses to represent. Or it may affect the representation of inexact numbers, or both. > 2) Should R7RS-large require support for exact rational numbers? > (This is independent of #1: Wraith Scheme provides ratios of fixnums > but not bignums). I specifically dislike exact rationals whose size is unlimited out to the absolute boundaries of memory. They can cause mathematically correct code to rapidly occupy all memory and crash. I think the standard should require exact rationals having both numerator and denominator in a fixed range - equal to or possibly smaller than the range of exact integers. When the precision available in exact rational is overflowed, it should make sense to return an inexact number (the standard should permit but not require this behavior); therefore I believe the standard should require inexact numbers having values within "a few percent" of any representable exact number. Of course the absolute range available in inexact numbers may be much greater, but there should be inexacts throughout the range of exact numbers. > 3) Should R7RS-large require support for exact complex numbers? Yes, subject to the same ranges and precisions applicable to real number integers and ratios. > 4) Should R7RS-large require inexact complex numbers, to consist of > pairs of 64-bit IEEE binary floats? I believe the standard should require inexact complex numbers having the range and precision of a pair of inexact real numbers on that implementation, with a strong recommendation that this should be _at_least_ the range and precision of a representation as a pair of 64-bit IEEE floats. If individual implementations are using representations for inexact reals that have more precision or range than a 64-bit IEEE float, they should be using those same representations for their inexact complex numbers. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
