Re: Table 4 proposal version 0.1...
On 02/29/2012 05:00 PM, Dan Zuras Intervals wrote:
Date: Wed, 29 Feb 2012 15:47:49 +0100
From: Arnold Neumaier<Arnold.Neumaier@xxxxxxxxxxxx>
To: 1788<stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Table 4 proposal version 0.1...
On 02/29/2012 03:23 PM, Vincent Lefevre wrote:
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.
As I keep saying, mid(Empty) is not part of this proposal.
We can continue this debate until someone HAS a proposal
that makes sense. I do not have one yet.
I made a proposal which is mathematically sound and uniform (and is
the only mathematically sound choice), but conflicts with your
definition on unbounded intervals, which _is_ in the proposal.
Taking infinity as the midpoint of [0,Inf] is against all common sense
as it is as far from any point of the interval as is conceivable.
No midpoint in any conceivable interpretation. There is no midpoint,
and the result should reflect that. Labeling Inf as 'the' midpoint is
misleading,
On the other hand, a function split(X) [if provided by the standard]
should return a sensible splitting point if one exist, and NaN
otherwise, i.e., if X contains at most two machine numbers. What is
most sensible would have to be discussed. I thought for some time that
returning the median of the machine numbers is good but this would
split the interval [0,1] at an extremely tiny number, which is not
warranted. It seems that there is no ''natural'' such function, thus
the standard should not provide one.
Instead, I propose to provide a function flmedian(X) that provided the
median, so that users can make their own split routine based on mid,
flmedian, and scaling considerations.
I have not written it down yet, but I have an algorithm in
mind for split(X) that would work at level 1 with only one
new piece of information: namely the radix (2 or 10) within
which your arithmetic is done.
This split(X) would return a Real number that is nearest to
the median of representable numbers in any system of any
precision with that radix. When converted to a level 2 F
of that radix, the intervals [inf(X),split(X)]&
[split(X),sup(X)] would have the same number of representable
elements +/- 1.
But there is a fly in the ointment: Unless I know the range
of the exponent, I do not know how to properly split either
semi-infinite intervals or intervals containing zero. Where
"properly" is defined as +/-1 on each side. The reason for
this is that numbers "bunch up" around zero in much the same
way as they bunch up near infinity. And how much they bunch
up is a function of the exponent range& whether or not your
arithmetic supports subnormals.
There is another fly, which makes this useless for branch and bound.
Many problems have bounds [0,1], and your proposal would split this
interval somewhere close to the sqrt of the smallest normalizable
number. This produces a tiny interval (containing half the floats)
and an interval essentially as wide as before (containing the other
half). For most functions people would apply b&b to, this is a totally
unproductive split.
The split must be adapted to the problem, not to the number system. Thus
it cannot figure sensibly in a standard. Instead, the standard should
provide the building blocks needed to construct a variety of sensible,
problem-adapted splitting rules.
There are 2 general ways to go: (1) make Emax ALSO a parameter
to the split,& (2) split off the infinities& zero BEFORE you
start "proper" splitting.
Neither catches the second fly.