Bear scripsit:

> I'd object if the standard required more than 65536 bit
> representations or allowed smaller than 60-bit representations for
> exact integers.

I think 32-bit software is still important, even if 32-bit hardware
is rapidly becoming scarce.  I'm reluctant in 2014 to build a 64-bit
assumption into the standard yet.

It's actually common for bignum systems to track the number of bigits
(base 64K or 64K^2 digits) rather than bits, so in practice bignums
larger than this are representable, though not addressable on 32-bit
systems.  The R6RS language "limited only by available memory" is then
the effective bound.

> 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.

R7RS-small, like R5RS and R6RS, already does:

    Rational operations such as + should always produce exact results
    when given exact arguments. If the operation is unable to produce
    an exact result, then it may either report the violation of
    an implementation restriction or it may silently coerce its
    result to an inexact value. However, (/ 3 4) must not return
    the mathematically incorrect value 0.

So nothing more needs to be said here.  A few existing Schemes violate
this rule (SigScheme, Shoe, TinyScheme, JScheme, BDC, XLisp, Schemik,
SXM, Dfsch), but they are quite simply non-conformant, often in more
ways than this.

> 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).

This is already true: see above.

> 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.

Does being able to represent +inf.0 and -inf.0 count as representing an
infinite range of inexact numbers?  If so, this constraint is met by
doing IEEE.  But if not, then any Scheme with standard bignums and IEEE
floats violates it.  I am reluctant to say that such implementations
aren't conformant.

> I specifically dislike exact rationals whose size is unlimited out to
> the absolute boundaries of memory. [...] 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.

It's one thing to require at least such a range of ratios ...

> 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.

... but not to make the combination of bignum-based ratios and IEEE floats
downright non-conformant, with no escape hatch as above.  I can't accept
something so different from existing practice as a requirement.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
Do what you will / this Life's a Fiction
And is made up of / Contradiction.  --William Blake

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.