On 2 Apr 2012, at 13:04, Vincent Lefevre wrote:
I vote NO on: Motion P1788/M0032:midpoint
I also vote NO, for the reasons Vincent has given, and some others.
First, even the latest version of the motion says
Coercion to level 2: For some implicit or explicit IFbar
based on a some floating-point system F we have that ...
which, using the terminology I've used in the draft text, would read
"For some implicit or explicit interval type T
based on a some number format F we have that ..."
P1788 currently does not define a meaning for "T based on F" here, for
general types T. Such a meaning is of course defined for inf-sup types,
but even for my (unofficial) definition of a mid-rad type, the midpoint
and radius need not use the same number format. This vagueness conceals
pitfalls, as Vincent's recent counter-example (2 April 2012 14:04:28)
shows.
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. 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.
Second.
Dan has been most eloquent in arguing that NaN is inherently dangerous,
and that 1788 will be a better platform for reliable computing if the
operations that convert interval inputs to floating point results create
as few NaNs as possible, preferably none at all.
I accept there are areas of software where "choose a number -- any
number" gives a safer return-value than a NaN. Maybe one of these is
control of embedded systems. But even there, the case studies Dan has
told me of suggest that a value tailored to the application is what is
needed (e.g. "stick at the maximum, or minimum, allowed"), not a single
catch-all value.
So I remain unconvinced. IMO this should NOT drive our philosophy of how
to handle the interval-to-floating-point interface.
If the rocket blows up and the media scream "'Secure' computer arithmetic
loses taxpayer a billion dollars", we should stick to our guns and say
"It wasn't IEEE 754, it was poor software production, probably for the
usual reasons of faulty analysis and design, poor house-rules for coding,
inadequate testing, and trying to do too much in too little time". Being
human, in other words.
I regret being at odds with Dan, but I believe that for most numerical
computation, it is *easier* to make it secure if, when some real function
has an undefined value at Level 1, it returns a NaN at Level 2. That's
what NaN was designed for.
My suggestions, which I think accord fairly well with Arnold's and some
other folk's, are
a. Level 2 midpoint, with input an X of some interval type T, returning m
of some number format F, should compute
m = roundToNearest_F(exact midpoint of X)
when X is nonempty and bounded and the resulting m is finite; and NaN
otherwise. (So F must support NaN.)
It is of course possible that X is nonempty and bounded, but m isn't
finite, e.g. with the triplex representation of Vincent's 2nd April
example, since this can exactly represent X=[2*realmax,2*realmax] for
instance. In that case I feel m=NaN is better than m=Inf.
b. A "median" function, for splitting intervals in branch-and-bound (or
similar) applications, has different requirements from "midpoint" -- such
as that, for any nonempty X, it should *always* return a finite value m
that is "useful".
c. P1788 should offer one "median" function in the set of Recommended
Functions, for user convenience.
Regards
John Pryce
--------------------P.S.------------------
I am still waiting for someone to produce an implementation of the
Michel/Arnold median function based on "convert to sortable". Meantime,
attached, I offer SMEDIAN2, a hardened-up Matlab version of my
m = smedian(a,b) = sinh( (asinh(a)+asinh(b))/2 )
Level 2 properties (I believe):
- Just uses the operations + - * / sqrt() and hypot().
- For all finite a,b it returns a finite result m that is within
a few ulps of the exact result and is *always* between a and b.
- If either input is NaN it returns NaN.
- Else, if either input is infinite it treats it as a "Level 2
special case" as shown in this table, where H denotes the
largest representable real, realmax.
\ b=
a= \ -inf finite +inf |
-------+--------+--------+--------+
-inf | -inf -H 0 |
finite | -H n/a +H |
+inf | 0 +H +inf |
-------+--------+--------+--------+
Thus if a and b are the bounds of any nonempty representable
interval, it returns a finite value that lies in the interval.
- It is also vectorized.
At Level 1, SMEDIAN2 is monotone, i.e.
a1<=a2, b1<=b2 ==> smedian2(a1,b1) <= smedian2(a2,b2).
Sadly this isn't true for my code, it can fail "by a few ulps". I don't
know how to achieve it without using extra precision.
Please try to break this code.
<smedian2.m>