Re: Table 4 proposal version 0.1...
On 2012-02-21 17:20:47 -0800, Dan Zuras Intervals wrote:
> I still have no good answer for midpoint(Empty) so that
> is still not part of this proposal. However, I disagree
> with some that it should be NaN on several grounds.
> I believe the user would be better served by an arbitrary
> choice such as 0 than by introducing errors into a
> potentially error free standard. That goal is worth the
> occasional arbitrary choice, IMHO.
I wouldn't regard NaN as an error, not more than +inf and -inf.
> ----------
>
> Level 1: mid(X) = for non-empty X only: if (X==Entire) then 0
> else (inf(X) + sup(X))/2
>
> Property: X \subset Y ==> if (inf(X)==inf(Y)) then mid(X) <= mid(Y) &
> if (sup(X)==sup(Y)) then mid(X) >= mid(Y)
>
> Coercion: mid_F(X) = if (abs_F(round2Nearest_F(mid(X))) = +inf)
> then roundToZero_F(mid(X))
> else round2Nearest_F(mid(X))
For X = [0,+inf], this would give:
* mid(X) = +inf
* abs_F(round2Nearest_F(mid(X))) = +inf
* roundToZero_F(mid(X)) = roundToZero_F(+inf) = +inf
while I think you wanted Fmax_F. I don't think you can avoid it,
except artificially, e.g. with nextDown(+inf).
[...]
> required for the definition of rad to work. The
> midpoint of Entire is arbitrary. Any finite value
> would do. But 0 is as good as any other & splits
> Entire right down the middle (even though it has
> no middle). Someday we may need to make a similar
> argument concerning midpoint(Empty). Can we choose
> 0? I don't know yet. But I believe almost any
> arbitrary choice will serve us better than a NaN.
> (Still, that choice is for the future & not part
> of this proposal.)
IMHO, if a non-NaN datum is returned, it should match the practical
use. But I don't see how 0 (or any other real value) could be useful.
> ----------
>
> Level 1: wid(X) = if (X==Empty) then 0
> else if (X==Entire) then +inf
> else sup(X) - inf(X)
I recall that if X = Entire, then sup(X) - inf(X) = +inf.
So, X==Entire isn't an exception to the general formula.
>
> Property: X \subset Y ==> wid(X) <= wid(Y)
>
> Coercion: wid_F(X) = roundUp_F(wid(X))
> Property still holds if weak monotonicity holds
> in your arithmetic. Sufficiently wide finite
> intervals may have an infinite width returned
> if F has insufficient dynamic range to express
> that width. And care should be taken that the
> expressions +/-inf - +/-inf either never arise
> or are dealt with properly (easy to do). The
> "else if" clause is only needed for systems
> that choke on +inf - -inf & return a NaN (there
> are still such systems around). After that,
> there is guaranteed to be one finite term in
> the "else" clause. At least at level 1. Both
> John & Vincent argue that wid(Empty) = -inf on
> much the same grounds as mag(Empty) = -inf.
> I prefer 0 on Least Astonishment grounds but
> would have no great objection to the change.
Well, "Least Astonishment grounds" is subjective (like for mag).
There are various reasons for which one might expect -inf:
* For X = Empty, sup(X) - inf(X) = -inf.
* Similarly, one would have wid(X) = sup { a - b | a, b in X }
for all X.
If 0 is chosen, it should be said that the width definition
comes from the measure.
> ----------
>
> Level 1: rad(X) = if (X==Empty) then 0
> else mag(X - mid(X))
>
> Property: X \subset Y ==> rad(X) <= rad(Y)
>
> Coercion: rad_F(X) = if (X==Empty) then 0
> else mag_F(X - mid_F(X))
> This one is a bit tricky. Note that the coercion
> is subtly different from all the others & is needed
> for both weak monotonicity & (22) to hold. Given
> that, property still holds if (1) mid_F returns the
> nearest representable finite number in F rather than
> a NaN whether or not it is in the interior of X &
> (2) weak monononicity holds in your arithmetic.
> Some finite intervals will return an infinite result
> if F is unable to represent the finite value. Care
> should be taken that +/-inf - +/-inf either never
> arises or is dealt with properly (easy to do).
> Further, Nate's (22)
>
> X \subset [mid_F(X) - rad_F(X), mid_F(X) + rad_F(X)]
>
> holds so long as not both mid_F(X) & rad_F(X) are
> infinite. It would also hold for Empty if mid(Empty)
> is not a NaN. But chances are, that's too much to
> ask for. Equation (22) is going to be needed if we
> want to use X -> <mid_F(X),rad_F(X)> to preserve
> containment on conversion to mid-rad. We already
> have X -> [inf_F(X),sup_F(X)] for inf-sups. We will
> need both. Note that we can have rad_F(X) > wid_F(X)/2
> in some cases. Indeed, we can have rad_F(X) = wid_F(X).
> I could make a good mathematical argument for why this
> is so but only another mathematician would fall for it.
> In the end, it is because wid() & rad() are defined
> very differently. For the moment, we cannot have
> rad(X) > wid(X) but if John's & Vincent's arguments
> about Empty hold sway we will have rad(Empty)=0 >
> wid(Empty)=-inf. Perhaps an argument against it.
> Perhaps not. Because John & Vincent would also have
> rad(Empty) = -inf. Note that cannot be so & still
> preserve containment on conversion to mid-rad. That
I disagree. Containment is preserved with rad(Empty) = -inf,
since this would give Empty \subset Empty.
Moreover, IMHO, the standard should require that Empty be preserved
on conversion to mid-rad. This means that you must not have at the
same time mid(Empty) = 0 and rad(Empty) = 0.
> is, IF we can settle on an answer for mid(Empty). :-)
> Perhaps that works for you. It does not for me.
> Vincent pointed out that mag(X - mid(X)) makes no
> sense when mid(X) = inf. While true, Vincent also
> notes that the width of an interval is unaffected by
> translation. Thus, an infinite interval is still
> infinite no matter how you shift it. The real
> problem would come from the subtraction of infinities
> at level 2. And this is avoided by clamping all
> midpoints to finite values.
>
> ----------
>
> Level 1: midRad(X) = for non-empty X only: <mid(X),rad(X)>
>
> Property: mid property holds for mid part & rad for rad.
>
> Coercion: midRad_F(X) = <mid_F(X),rad_F(X)>
> This is a derived function, really. So its
> behavior is derived from its components.
> Kind of by definition of midRad, we have
> that its version of (22) namely
>
> X \subset midRad_F(X)
>
> holds so long as not both mid_F(X) & rad_F(X)
> are infinite & mid(X) not NaN. BTW, this
> suggests to me that we might define an infSup(X)
> which returns [inf(X),sup(X)]. And maybe both
> this & midRad belong elsewhere than table 4.
See my remark above. This should also be defined for Empty,
and the result should be a valid representation for Empty.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)