usrfun must define the nonlinear portion of the problem functions , along with its gradient elements . (A dummy method is needed even if and all functions are linear.)
In general, usrfun should return all function and gradient values on every entry except perhaps the last. This provides maximum reliability and corresponds to the default option setting, .
In practice it is often convenient not to code gradients. e04vh is able to estimate them by finite differences, using a call to usrfun for each variable for which some needs to be estimated. However, this reduces the reliability of the optimization algorithm, and it can be very expensive if there are many such variables .
As a compromise, e04vh allows you to code as many gradients as you like. This option is implemented as follows. Just before usrfun is called, each element of the derivative array g is initialized to a specific value. On exit, any element retaining that value must be estimated by finite differences.
Some rules of thumb follow:
(i) | for maximum reliability, compute all gradients; |
(ii) | if the gradients are expensive to compute, specify optional parameter Nonderivative Linesearch and use the value of the input parameter needg to avoid computing them on certain entries. (There is no need to compute gradients if on entry to usrfun.); |
(iii) | if not all gradients are known, you must specify . You should still compute as many gradients as you can. (It often happens that some of them are constant or zero.); |
(iv) | again, if the known gradients are expensive, don't compute them if on entry to usrfun; |
(v) | use the input parameter status to test for special actions on the first or last entries; |
(vi) | while usrfun is being developed, use the optional parameter Verify Level to check the computation of gradients that are supposedly known; |
(vii) | usrfun is not called until the linear constraints and bounds on are satisfied. This helps confine to regions where the functions are likely to be defined. However, be aware of the optional parameter Minor Feasibility Tolerance if the functions have singularities on the constraint boundaries; |
(viii) | set if some of the functions are undefined. The linesearch will shorten the step and try again; |
(ix) | set if you want e04vh to stop. |
Syntax
C# |
---|
public delegate void E04VH_USRFUN( ref int status, int n, double[] x, int needf, int nf, double[] f, int needg, double[] g ) |
Visual Basic |
---|
Public Delegate Sub E04VH_USRFUN ( _ ByRef status As Integer, _ n As Integer, _ x As Double(), _ needf As Integer, _ nf As Integer, _ f As Double(), _ needg As Integer, _ g As Double() _ ) |
Visual C++ |
---|
public delegate void E04VH_USRFUN( int% status, int n, array<double>^ x, int needf, int nf, array<double>^ f, int needg, array<double>^ g ) |
F# |
---|
type E04VH_USRFUN = delegate of status : int byref * n : int * x : float[] * needf : int * nf : int * f : float[] * needg : int * g : float[] -> unit |
Parameters
- status
- Type: System..::..Int32%On entry: indicates the first and last calls to usrfun.
- There is nothing special about the current call to usrfun.
- e04vh is calling your method for the first time. You may wish to do something special such as read data from a file.
- e04vh is calling your method for the last time. This parameter setting allows you to perform some additional computation on the final solution.
- The current x is optimal.
- The problem appears to be infeasible.
- The problem appears to be unbounded.
- An iterations limit was reached.
If the functions are expensive to evaluate, it may be desirable to do nothing on the last call. The first executable statement could beOn exit: may be used to indicate that you are unable to evaluate or its gradients at the current . (For example, the problem functions may not be defined there.)During the linesearch, is evaluated at points for various step lengths , where has already been evaluated satisfactorily. For any such , if you set , e04vh will reduce and evaluate again (closer to , where is more likely to be defined).If for some reason you wish to terminate the current problem, set .
- n
- Type: System..::..Int32On entry: , the number of variables, as defined in the call to e04vh.
- x
- Type: array<System..::..Double>[]()[][]On entry: the variables at which the problem functions are to be calculated. The array must not be altered.
- needf
- Type: System..::..Int32On entry: indicates whether f must be assigned during this call of usrfun.
- f is not required and is ignored.
- The components of corresponding to the nonlinear part of must be calculated and assigned to f.
If is linear and completely defined by the th row of , , then the associated value is ignored and need not be assigned. However, if has a nonlinear portion that happens to be zero at , then it is still necessary to set . If the linear part of a nonlinear is provided using the arrays iafun, javar and a, then it must not be computed again as part of .
needf may also be ignored with Derivative Linesearch and . In this case, needf is always , and f must always be assigned.
- nf
- Type: System..::..Int32On entry: is the length of the full vector as defined in the call to e04vh.
- f
- Type: array<System..::..Double>[]()[][]On entry: concerns the calculation of .On exit: f contains the computed functions (except perhaps if ).
- needg
- Type: System..::..Int32
- g
- Type: array<System..::..Double>[]()[][]On entry: concerns the calculations of the derivatives of the function .On exit: contains the computed derivatives (unless ).These derivative elements must be stored in g in exactly the same positions as implied by the definitions of arrays igfun and jgvar. There is no internal check for consistency (except indirectly via the optional parameter Verify Level), so great care is essential.