Re: I vote NO on: Motion P1788/M0032:midpoint
On 2012-04-06 16:11:36 +0100, John Pryce wrote:
> What I *have* proposed in the Level 2 draft is the reverse: that
> there should be a particular "F associated with T" for each T. Some
> people have disagreed with this, some are sympathetic. Some,
> including Vincent, have proposed some basic properties such an F be
> required to possess. I hope Vincent will make a motion on this soon.
FYI, I currently have a draft, but before submitting it, I first need
to do some verifications and finish to read other stds-1788 mail in
case I forgot something. Perhaps later today.
> If we get a suitable set of properties (maybe of T's as well as
> their F's), possibly we can eliminate counterexamples such as
> Vincent's.
My current text doesn't eliminate this one, and it could be artificial
to eliminate it. I think that the property
X \subset Y ==> if (inf_F(X)==inf_F(Y)) then mid_F(X) <= mid_F(Y)
is just bad because it mixes Level 1 and Level 2. The problem is
the following one. One may have:
[--- X ---]
[---- Y ----]
with F such that inf_F(X) == inf_F(Y). Note that this is not possible
with an inf-sup format, because inf_F(X) = inf(X) and ditto for Y.
Note: here mid_F(X) <= mid_F(Y) would mean in practice that one has
the equality mid_F(X) == mid_F(Y).
So, if around inf(X) and inf(Y), F is sparse enough (so that
inf_F(X) == inf_F(Y)) and around mid(X) and mid(Y), F is dense enough,
then one won't be able to have mid_F(X) <= mid_F(Y) all the time. With
a floating-point format, this problem is more likely to occur in high
radices when inf(X) and inf(Y) are negative and mid(X) and mid(Y) have
a smaller exponent.
--
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)