William D Clinger wrote:
>
> There are no roundoff errors with fixnum arithmetic.
> If the arguments are fixnums, they raise an exception
> if and only if the mathematically correct result is
> not representable as a fixnum, i.e. an underflow or
> overflow occurs.
>
In general, I have given up on any future R^nRS being the
language *I* think of as Scheme but, a quick kibbitz:
Underflow and overflow in fixnum arithmetic is a feature,
not a bug. Stick that in your numeric lattice pipe and smoke
it. :-)
-t
>
>>> (let ((i (least-fixnum))
>>> (j (greatest-fixnum)))
>>> (list
>>> (fx+ i i i i i i i i i i j j j j j j j j j j)
>>> (fx* i i i i i i i i i 0 i i i i i i i i i)))
>>>
>>> would not raise an exception ...
>>>
>> I fear I have misunderstood something. The addition
>> expression encounters an overflow error and returns
>> an infinity.
>>
>
> No. We are talking about fixnum arithmetic. Fixnums
> are a proper subset of the exact integers. There is
> no fixnum infinity.
>
>
>> Does it not raise an exception? The
>> multiplication expression, given either associative rule,
>> encounters underflow while multiplying the i's. Does
>> it not raise an exception before it even attempts to
>> multiply by the exact zero?
>>
>
> The specification of fx+ and fx* states:
>
> These procedures return the sum or product of
> their arguments, provided that sum or product
> is a fixnum. An exception with condition type
> &implementation-restriction is raised if that
> sum or product is not a fixnum.
>
> That specification makes sense for an arbitrary
> number of arguments, and my hypothetical example
> showed one consequence of extending their domains
> to arbitrary numbers of arguments. According to
> the specification quoted, whether an exception is
> raised depends solely upon the ultimate sum or
> product, irrespective of any intermediate results.
>
> As the rationale observes, this would require
> extra precision for intermediate results (although
> not as much as is claimed by the rationale; that's
> likely to be just a careless claim of mine that
> somehow got propagated into the draft report).
>
> One could, of course, rewrite the specification so
> that an exception is raised when an intermediate
> result overflows, even if the mathematically correct
> ultimate result would be a fixnum. That would be
> a more complex specification, as it would have to
> specify some operational details that the current
> wording does not. IMO it would also reduce the
> correspondence between + and fx+ and between * and
> fx*. Despite those evils, if the Scheme community
> insists upon generalizing fx+ and fx* to arbitrary
> numbers of arguments, I think it would be better
> to change the specification by introducing those
> operational details and breaking the correspondence
> than by requiring extra precision for intermediate
> results.
>
> Will
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070219/7796defa/attachment.html
Received on Mon Feb 19 2007 - 20:28:38 UTC