Re: General pow(xx,yy) function in Motion 10
Michel Hack wrote:
The only exception is in nonlinear integer programming, where it is
conceivable that one has intervals for integers acting as exponents.
Yes -- but such an exponent range is not an interval, because it is
strictly a set of integers and does not include the real numbers in
between. So using intervals to represent it during an exploratory
part of an algorithm requires to programmer to keep this in mind, and
correct for the consequences, as the usual Interval Theorems don't
apply anymore.
This is always done in mixed integer nolinear programing using branch
and bound techniques. One accounts for integrality by splitting at half
an integer and rounding the two new bounds to the next integer.
This is enough to make everything work correctly, as far as pruning
regions is concerned. Of course, existence statements beyond that (such
as Brouwer's fixed-point theorem) needed only for computer-assisted
proofs) need to fix integers when integrality constraints are present,
before they apply.
Suppose for some reason the function 1/cospi(x) is involved over a
range that only includes integers. It's "interval" hull would then
be [-1,+1] (but would in fact only contain the endpoints), when the
true interval hull would be Entire.
This is why I'm also wary of interval functions like sign, ceil etc.,
because their range is by definition a set of isolated integral points.
Lots of application optimization problems written by inexperienced
users into excel sheets have discontinuities.
Thus one really needs interval extensions of discontinuous functions.
Of course, we need them together with the exception information in
case a discontinuity is possibly inside the interval (to avoid
claiming existence when only covering information is valid).
This is one of the reason why the decoration for continuity is important.
Michel.
P.S. Singletons are rational, so an implementation of pow(xx,yy) can
always switch to the applicable pow_r(xx) function when yy is a
singleton. Of course the double-indexed pow_n_d(xx) allows a
wider choice of rational exponents, and pow_n(xx) together with
root_n(xx) probably cover the desired ground. The general pow()
function is indeed insufficient to capture root_n() semantics.
Based on this, Motion 10 should indeed have included at least
root_n(xx) among the required functions.
I very much suspect that a later motion will make pow_n(xx) and
and root_n(xx) mandatory, so the only real choice is whether some
pow(xx,yy) should be mandatory, and what its semantics should be.
Perhaps Dan will also propose his powPos(xx,yy) and powNeg(xx,yy)
functions...
---Sent: 2009-12-07 13:27:12 UTC