Re: Bisection methods (was Structured support...)
Michel Hack wrote:
Nate Hayes wrote:
-- The current P-1788 draft says the midpoint of an unbounded interval
is undefined at Level 1.
-- When I asked "does this mean other interval bisection methods such
as geometric mean, smedian2, etc. are also undefined at Level 1
for
unbounded intervals?" John's answer was "yes".
-- When I asked "does this mean all of these interval bisection
methods
are undefined for unbounded intervals at Level 2, as well?"
John's
answer was "yes, and let it return NaN at Level 2..."
We happen to agree with John on these points. However, this leaves many
interval algorithms undefined at Level 1 and Level 2, returning NaNs.
By "these interval bisection methods" John meant any that are described
at Level 1. This does not preclude Level 2 from offering other pragmatic
bisection methods that ARE defined to return a specific format-dependent
finite value at Level 2.
I understand, Michel, but my position is the same as when John made the same
argument to me just the other day:
Nate Hayes wrote:
My only problem with this idea is it means users can no longer design
interval algorithms (or prove them correct) at Level 1, and we feel it
encourages users to ignore the Level 1 definitions. We believe overflow
avoids this problem by providing the necessary mathematical framework at
Level 1a.
Michel Hack wrote:
It may well be that there can be no agreement one one (or perhaps a
small number) of such pragmatic bisection functions, as different
applications would prefer a different bisection rule). However, if
a large number of applications can agree on a small-enough set, it
would be USEFUL to offer these in the standard -- perhaps only as
recommended functions, so as to avoid the need for everybody to
reinvent the same wheel.
Or, with overflow the necessary mathematical framework can be put in place
that allows users to write thier own well-defined bisection methods at Level
1a, none of which need to be standardized except perhaps for some minimal
standard (hence the analogy in section 3.2.5).
Nate