[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: Wrapping up SRFI-70*From*: bear <bear@xxxxxxxxx>*Date*: Fri, 19 Aug 2005 11:28:28 -0700 (PDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050819012559.ADAE71B77B4@xxxxxxxxxxxxxxxx>*References*: <20050810030837.1C5711B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0508092135590.25357@xxxxxxxxxxxxxx> <20050815034459.8A6981B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0508161900040.27338@xxxxxxxxxxxxxx> <20050819012559.ADAE71B77B4@xxxxxxxxxxxxxxxx>

On Thu, 18 Aug 2005, Aubrey Jaffer wrote: > We can reasonably talk about mathematics with regard to the ring of > exact integers or the field of exact rationals; but flonums correspond > to no mathematical formalism that I know of. > | An actual overflow, such as (* 2 MAXFLONUM), has an unambiguous > | sign, but is not actually an infinity; it is merely a number > | too large to represent in our current encoding scheme. >(* 2.0 MAXFLONUM) returns an infinity by the definition in SRFI-70: Yes. That's confusing overflows (which do *NOT* alter mathematical identities involving multiplication by zero) with infinities (which do) and that's one of the problems with SRFI-70 IMO. > `+inf.0' represents real numbers greater than can be encoded by finite > inexacts in the implementation (> 179.76931348623157e306 for IEEE-754 > 64-bit flonums). `-inf.0' represents numbers less than can be encoded > by finite inexacts in the implementation (< -179.76931348623157e306 > for IEEE-754 64-bit flonums). If that's the case (if you're using them purely to represent overflows) then abandon any idea about treating them differently than any other number when multiplying by zero, and make the result of dividing by zero (an actual infinity but one of ambiguous sign) into a NaN instead. > | Since > | this isn't actually an infinity, it is quite right to state > | that multiplying such an object by an exact zero may result > | in an exact zero. In fact, it *DOES* result, mathematically > | speaking, in zero; > Mathematically, multiplication exists only in combination with a > domain of eligible operands in a group, ring, or field. An example > of a domain is the integers. To talk of multiplying an integer by > an inexact number is mathematically meaningless. One number must be > mapped into the other's domain and the appropriate operation > performed. You're responding to a side issue that isn't the point. The point is that numbers merely too big to be represented, are not infinite and do not merit any special treatment when multiplied by zero. The result is zero. Numbers which *do* merit special treatment when multiplied by zero are *real* infinities; either the results of a division by zero, or the result of evaluating some other singularity. Their signs are usually ambiguous, undefined, or determined solely by convention. > | Under your current > | formulation, are infinities distinguished from overflows? > No. Overflows result in infinities, like in IEEE-754. > | Do you think > | it would be a reasonable thing to do? > Distinguishing them in error messages might be useful, but I think > the distinction is not important enough to mandate it be testable > from Scheme. >> Do you think it would be a reasonable thing to forbid anyone to do? >Yes, I think inexactness should be contagious without exception. Well, I guess this comes to the point of it then. I think that you are wrong. Overflows and infinities are different kinds of things, and forbidding people to distinguish them is a mistake. If your mind is made up, as you claim it is, then we apparently have nothing more to discuss. Bear

**References**:**Wrapping up SRFI-70***From:*Aubrey Jaffer

**Re: Wrapping up SRFI-70***From:*bear

**Re: Wrapping up SRFI-70***From:*Aubrey Jaffer

**Re: Wrapping up SRFI-70***From:*bear

**Re: Wrapping up SRFI-70***From:*Aubrey Jaffer

- Prev by Date:
**Re: Wrapping up SRFI-70** - Next by Date:
**Re: Wrapping up SRFI-70** - Previous by thread:
**Re: Wrapping up SRFI-70** - Next by thread:
**Re: Wrapping up SRFI-70** - Index(es):