| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Vincent Lefevere wrote:
On 2012-01-13 03:13:24 +0100, Vincent Lefevre wrote:On 2012-01-13 03:11:28 +0100, Vincent Lefevre wrote: > > May I even be so bold as to suggest the "midpoint" of any > > interval [u,v] could be NaN if u and v are two adjacent Level 2 > > datums, regardless if u and v are both finite or not? The > > rationale: this also avoids infinite recursion in naive B&B > > algorithms if midpoint of [u,v] is otherwise defined to be u or > > v. > > This may be a good idea. And this would mean that the following > property would hold at Level 2: u < midpoint([u,v]) < v. ... of course, when NaN doesn't occur.Hmm... The case [u,u] has been forgotten. What would the spec be? Can this happen in B&B algorithms?
If midpoint([u,v]) = NaN when u and v are adjacent Level 2 datums, then I can't really think of any way to obtain [u,u] in B&B unless this is the initial input provided by a user (that would be rather silly, but I suppose this could happen). Returning NaN for midpoint([u,u]) may still be safest, anyways: in general the interval extentsion f([u,u]) is likely have some interval width and this could still cause a naive B&B algorithm to try and bisect [u,u] leading again to a state of infinite recursion. From a mathematical perspective if we define the natural domain of the midpoint operation to be all Level 2 intervals [u,v] such that there exists some Level 2 datum m u < m < v, then returning NaN for midpoint([u,u]) would make sense because [u,u] is not in the natural domain of the operation. Nate