Re: Branch & bound for not everywhere defiend constraints
Vincent Lefevre wrote:
> On 2009-09-07 10:36:36 +0200, Arnold Neumaier wrote:
>> Vincent Lefevre schrieb:
>>> On 2009-09-02 11:26:21 +0200, Arnold Neumaier wrote:
>>>> Vincent Lefevre schrieb:
>>>>> One could also have a flag attached to the returned interval.
>>>>> Alternatively, one could have a function telling whether X' is
>>>>> included in the domain of f.
>>>> The latter can in general be found out only by evaluating;
>>>> so this would double the work whenever one needs both the
>>>> evaluation and the domain check.
>>>
>>> I would have said the opposite, i.e. that the latter doesn't need
>>> evaluation in general. For instance, if the domain is R, then the
>>> result is always TRUE. For the division, the result is TRUE iff
>>> the second argument doesn't contain 0.
>>
>> I meant the domain of a whole expression.
>
> OK, but then, this is out of the scope of the standard, isn't it?
Yes.
> But of course, if one wants to allow user-defined functions with
> complex domains to have exactly the same interface as "common"
> functions (whose domain should be known without much work), then
> I agree.
This doesn't make sense.
For such a function like r(x)=p(x)/q(x), the user can request r to be
evaluated over some interval domain xx. So the syntax tree of the expression
is recursed, and each node in the tree, which represents an elementary
operation, is evaluated. If in NaI mode, some of these may return NaI, in
which case evaluation of the entire expression can be terminated prematurely
to save time and computational effort!!
Otherwise NaI propagates as expected through the evaluation, or no NaI is
generated and a valid interval result is produced. In either case, the
result is returned and there is no overhead.
>
>>> This is what I've said: a flag *attached to the returned interval*.
>>
>> I had intended to say something slightly different:
>> _all_ flags attached to the returned interval.
This is the "decorated interval" mentioned previously.
Nate Hayes