Re: How do I bisect unbounded intervals?

[Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>]

P-1788:

Although I find this topic interesting and am glad it is
being discussed, I now wish to express a personal opinion
about its relevance to P-1788.  Namely, in my own
view, I think specifying a "bisection point" in a
branch and bound algorithm is too application specific to
be a part of our standard.  I think specifying "midpoint"
is well within the scope, in which case we may wish to specify
what is returned for unbounded intervals (just so it will
be known and standard across platforms;  however, IMO specifying
"random" in such cases won't help in portability and reproducibility).
However, specifying "bisection point" different from midpoint, and
designed to be good for branch and bound algorithms, seems a bit
of a stretch of the scope.

Of course, if there is strong sentiment otherwise, I'll go along with it
when I put on my hat as acting chair.

Baker

On 01/12/2012 04:25 PM, Nate Hayes wrote:
> N. M. Maclaren wrote:
> > On Jan 12 2012, Nate Hayes wrote:
> > > Yeah, these are really good points. We've struggled with all of them in
> > > the form of bugs or unexpected algorithm behavior at one point or another
> > > over the years. I don't know if Level 2 bisection rules could be
> > > standardized accross all applications or not, but I would personally find
> > > it very helpful if P1788 might at least provide some informative
> > > information on this topic. ...
> >
> > Good ones can't be. That's a classic result. The optimal bisection is
> > the one that maximises the information gain relative to the cost. It
> > is doubtless possible to produce a general one that is better than
> > anything a naive programmer would invent.
>
>
> Well, let's define what "good" means here... it seems to me we're at
> cross-purposes.
>
> It is very easy (too easy, IMHO) for an unwary programmer to write a
> bisection operation that may cause infinite recursion and crash a program.
> In this sense a general one could be much better than ad-hoc alternatives,
> even if it was not optimal. In other words, I'd settle for "good" to simply
> mean a conforming implementation that is guaranteed not to crash under some
> of the circumstances Vincent outlined.
>
> Nate