Why DerivativeCheck would be allowed to be on while there is no GradObj?

When GradObj is off, and DerivativeCheck is on, fmincon starts to run without any error or warning. Why would this be the case? That is, if there is no gradient supplied, there cannot be derivattive check. So why would MATLAB allow the DerivativeCheck to be on if there is no gradient available?

options = optimset(...
    'MaxFunEvals',10000,...
    'TolFun',1e-4,...
    'TolX',1e-4,...
    'Algorithm','sqp',...
    'GradObj','off',...
    'DerivativeCheck','on',...
    'Display','iter',...
    'FunValCheck','off'); 

Answer 1

[Matt J]

Here's a reason why you might want to allow DerivativeCheck to be on even when the analytical gradient computations are all off. Suppose the user has coded 6 different implementations of the gradient calculation and wants to compare them all for speed. Suppose also that she wants to run the optimization with finite difference gradient computations as a baseline for the comparison.

In this situation, you would want to have DerivativeCheck='on' for 6 different runs. To run the finite differencing baseline, however, your proposal would force the user to set both SpecifyObjectiveGradient=false and DerivativeCheck='off'. Some people would prefer just to set SpecifyObjectiveGradient=false and not to have to fuss with additional settings for just that one case.

[Snoopy]

There are many suppositions in this example. I also do not see how it negates my point really. I consider that no message is harmful in the third example above where settings are simply nonsense. That is period for me. Thanks for all the replies.

Answer 2

[John D'Errico]

You can set other options that will be ignored if they are not applicable. Would you rather have the code fail for no reason on a problem that has a solution?

[Snoopy]

No, but it also does not make sense that MATLAB does not complain if the user sets the options inconsistently across options. As MATLAB does not complain, the user assumes that he is using the options correctly. I think, as the provider of the options, MATLAB should lead the user to use the options correctly.

[John D'Errico]

But why does it matter in the least? The options were not set incorrectly in any way that would cause a problem. It is just that one option is not needed, so the state for that property is irrelevant.

This is consistent with all of the optimization toolbox codes. For example, look at fzero.

optimset('fzero')

ans = struct with fields:
                   Display: 'notify'
               MaxFunEvals: []
                   MaxIter: []
                    TolFun: []
                      TolX: 2.2204e-16
               FunValCheck: 'off'
                 OutputFcn: []
                  PlotFcns: []
           ActiveConstrTol: []
                 Algorithm: []
    AlwaysHonorConstraints: []
           DerivativeCheck: []
               Diagnostics: []
             DiffMaxChange: []
             DiffMinChange: []
            FinDiffRelStep: []
               FinDiffType: []
         GoalsExactAchieve: []
                GradConstr: []
                   GradObj: []
                   HessFcn: []
                   Hessian: []
                  HessMult: []
               HessPattern: []
                HessUpdate: []
          InitBarrierParam: []
     InitTrustRegionRadius: []
                  Jacobian: []
                 JacobMult: []
              JacobPattern: []
                LargeScale: []
                  MaxNodes: []
                MaxPCGIter: []
             MaxProjCGIter: []
                MaxSQPIter: []
                   MaxTime: []
             MeritFunction: []
                 MinAbsMax: []
        NoStopIfFlatInfeas: []
            ObjectiveLimit: []
      PhaseOneTotalScaling: []
            Preconditioner: []
          PrecondBandWidth: []
            RelLineSrchBnd: []
    RelLineSrchBndDuration: []
              ScaleProblem: []
       SubproblemAlgorithm: []
                    TolCon: []
                 TolConSQP: []
                TolGradCon: []
                    TolPCG: []
                 TolProjCG: []
              TolProjCGAbs: []
                  TypicalX: []
               UseParallel: []

Here, for example, there are many options that are completely ignored. You can set them as you wish. Only 5 options in that list will be looked at, and there is no flag issued if you set one of the others.

help fzero

 FZERO  Single-variable nonlinear zero finding. 
    X = FZERO(FUN,X0) tries to find a zero of the function FUN near X0, 
    if X0 is a scalar.  It first finds an interval containing X0 where the 
    function values of the interval endpoints differ in sign, then searches 
    that interval for a zero.  FUN is a function handle.  FUN accepts real 
    scalar input X and returns a real scalar function value F, evaluated 
    at X. The value X returned by FZERO is near a point where FUN changes 
    sign (if FUN is continuous), or NaN if the search fails.  
 
    X = FZERO(FUN,X0), where X0 is a vector of length 2, assumes X0 is a 
    finite interval where the sign of FUN(X0(1)) differs from the sign of 
    FUN(X0(2)). An error occurs if this is not true.  Calling FZERO with a
    finite interval guarantees FZERO will return a value near a point where
    FUN changes sign.
 
    X = FZERO(FUN,X0), where X0 is a scalar value, uses X0 as a starting 
    guess. FZERO looks for an interval containing a sign change for FUN and 
    containing X0.  If no such interval is found, NaN is returned.  
    In this case, the search terminates when the search interval 
    is expanded until an Inf, NaN, or complex value is found. Note: if
    the option FunValCheck is 'on', then an error will occur if an NaN or 
    complex value is found.
 
    X = FZERO(FUN,X0,OPTIONS) solves the equation with the default optimization
    parameters replaced by values in the structure OPTIONS, an argument
    created with the OPTIMSET function.  See OPTIMSET for details.  Used
    options are Display, TolX, FunValCheck, OutputFcn, and PlotFcns. 
 
    X = FZERO(PROBLEM) finds the zero of a function defined in PROBLEM. 
    PROBLEM is a structure with the function FUN in PROBLEM.objective, 
    the start point in PROBLEM.x0, the options structure in PROBLEM.options,
    and solver name 'fzero' in PROBLEM.solver. 
 
    [X,FVAL]= FZERO(FUN,...) returns the value of the function described 
    in FUN, at X.
 
    [X,FVAL,EXITFLAG] = FZERO(...) returns an EXITFLAG that describes the
    exit condition. Possible values of EXITFLAG and the corresponding exit
    conditions are
 
      1  FZERO found a zero X.
     -1  Algorithm terminated by output function.
     -3  NaN or Inf function value encountered during search for an interval
          containing a sign change.
     -4  Complex function value encountered during search for an interval 
          containing a sign change.
     -5  FZERO may have converged to a singular point.
     -6  FZERO can not detect a change in sign of the function.
 
    [X,FVAL,EXITFLAG,OUTPUT] = FZERO(...) returns a structure OUTPUT
    with the number of function evaluations in OUTPUT.funcCount, the
    algorithm name in OUTPUT.algorithm, the number of iterations to
    find an interval (if needed) in OUTPUT.intervaliterations, the
    number of zero-finding iterations in OUTPUT.iterations, and the
    exit message in OUTPUT.message.
 
    Examples
      FUN can be specified using @:
         X = fzero(@sin,3)
      returns pi.
         X = fzero(@sin,3,optimset('Display','iter')) 
      returns pi, uses the default tolerance and displays iteration information.
 
      FUN can be an anonymous function:
         X = fzero(@(x) sin(3*x),2)
 
      FUN can be a parameterized function.  Use an anonymous function to
      capture the problem-dependent parameters:
         myfun = @(x,c) cos(c*x);  % The parameterized function.
         c = 2;                    % The parameter.
         X = fzero(@(x) myfun(x,c),0.1)
    
    Limitations
         X = fzero(@(x) abs(x)+1, 1) 
      returns NaN since this function does not change sign anywhere on the 
      real axis (and does not have a zero as well).
         X = fzero(@tan,2)
      returns X near 1.5708 because the discontinuity of this function near the 
      point X gives the appearance (numerically) that the function changes sign at X.
 
    See also ROOTS, FMINBND, FUNCTION_HANDLE.

    Documentation for fzero
       doc fzero

    Other uses of fzero

       optim/fzero

Similarly, that one of the options that fmincon can use under some circumstances is ignored under some combination of the other options, seems irrelevant. You might easily wish to leave that option set, and when a gradient is actually supplied, then it will become active.

Could a warning message be issued? Yes. I suppose the code could check for any out of place options in that list. But why is it remotely an issue?

[Snoopy]

We do not seem to disagree. I do not mean that there is a calculation issue and it is clear that there is none. All I mean is that MATLAB could guide the setting of the options and throw a message when settings by the user are nonsense. Why do I propose this? Because MATLAB, unlike other crap alternatives, do guide the user in many aspects of coding. So why not here too? That is one of the many things that makes MATLAB user frinedly and professional.

Answer 3

[Matt J]

I would say that no warning is strictly necessary because one of two cases are possible:

(1) DerivativeCheck='on' was intentional, but GradObj='off' was unintentional. If so, you will be warned that something is wrong by the fact that no derivative check output appears.

(2) GradObj='off' was intentional, but DerivativeCheck='on' was unintentional. If so, it would be your wish that the optimization proceed without a derivative check and, indeed, that is what happens.

That said, I do agree that an explicit warning message in case (1) would be more aesthetic.

[Snoopy]

In (1) MATLAB will complain anyhow, but an explicit message in that case makes sense. I do not understand anything about what is said in (2).

[Matt J]

In (1) MATLAB will complain anyhow

No, it will not complain. Both (1) and (2) consider the same option settings as in your original post where, as you already mentioned, fmincon runs without errors or warnings.

I do not understand anything about what is said in (2).

In (2), the user has set DerivativeCheck='on' whereas she really meant to set DerivativeCheck='off'. Since she really meant to have DerivativeCheck='off', the fact that no derivative check is done by fmincon does not produce any intended behavior, so it's fine that there are no errors or warnings.

[Snoopy]

Sorry I do not follow anymore. I preserve my claim. How can DerivativeCheck be on if GradObject is off? It cannot. So there should be a warning message because how the user specifies the settings (on or off) in the two options are not compatible with each other.

[Matt J]

I preserve my claim. How can DerivativeCheck be on if GradObject is off?

And our response is the same: what harm do you think is done by omitting a warning/error message?

A warning message is needed when user error leads to unintended code behavior that the user wouldn't otherwise detect. But as I've proposed in (1), the user would detect if GradObj is accidentally 'off' because no derivative check output is produced.

[Snoopy]

The user sees that things still run fine with nonsense settings. And then wonders why that would be, and wonders if he or she is making a mistake. Then comes here and asks why nonsense settings are allowed in MATLAB. And consumes your time and this forum's time and space. I guess that is real and enough harm.

[Matt J]

The user sees that things still run fine with nonsense settings.

It might be overstating things slightly to say that the settings are "nonsense". The main purpose of DerivativeCheck is to prevent the optimization from using analytical gradient calculations that are faulty. However, if SpecifyObjectiveGradient is turned off, the user is not supplying the gradient, and so there is no danger this will occur. So, arguably, the purpose of DerivativeCheck has been fulfilled and the optimization should just proceed care-free.

As I mention in my other answer, it would be nice if Matlab could warn you when you shut off analytical gradient calculations accidentally, or forget to turn them back on. But that is simply not always something Matlab can detect, and in any case is not something DerivativeCheck was primarily designed to protect against.

Answer 4

[Matt J]

So why would MATLAB allow the DerivativeCheck to be on if there is no gradient available?

Because maybe SpecifyConstraintGradient=true, even if SpecyObjectiveGradient=false. In your example, this is not the case. In general however, there are 4 possible combinations of settings for SpecifyObjectiveGradient and SpecifyConstraintGradient and only one of these combinations is suspicious when DerivativeCheck='on'. Therefore, there is very limited protection a warning message could provide against users accidentally turning off analytical gradient computation.

[Snoopy]

My OP has nothing to do with SpecifyConstraintGradient. Besides this, sorry, I do not see the argument. It just does not make sense ithat MATLAB allows nonsense combinations of user settings. It should not. Otherwise is suggesting that nonsense combinations are valid and hence does something, while it does nothing. The user should not need to wonder and see the need to verify that it indeed does not do anything. In fact, MATLAB should ensure the user that nonsense combinations do not have implications, and ensuring would be done with a warning message. The warning message is to tell user that the user is doing something nonsense. Because we are humans and we do nonsense things, especially in complex computations. You should not expect everyone to be experts of built-in functions. It reduces usability of MATLAB. It should not because that is what makes MATLAB good over crap alternatives like R.

[Matt J]

My OP has nothing to do with SpecifyConstraintGradient.

It does, and I explained why. At this point, I'm not sure if you're actually giving any thought to any of the answers being given to you. However, I'll give it one more try...

The following settings are not nonsense. They could have been given intentionally by the user and Matlab has no reason to issue a warning or think anything is wrong:

options = optimoptions('fmincon','DerivativeCheck','on',...
    'SpecifyObjectiveGradient',false,...
    'SpecifyConstraintGradient',true); 

Likewise, the following settings are not nonsense. No warnings are issued and no reason to think there should be.

options = optimoptions('fmincon','DerivativeCheck','on',...
    'SpecifyObjectiveGradient',true,...
    'SpecifyConstraintGradient',false); 

While both of these settings may be innocuous, however, there is also a hazard. Possibly, the user meant to turn both SpecifyObjectiveGradient and SpecifyConstraintGradient on, but mis-entered one of the settings. If so, the optimization will run slower because finite differencing is used instead of an analytical calculation. But Matlab has no way to intercept this hazard. The only way to intercept it is for the user to pay attention to the details of the derivative check output.

Now let's look at the scenario your OP raised:

options = optimoptions('fmincon','DerivativeCheck','on',...
    'SpecifyObjectiveGradient',false,...
    'SpecifyConstraintGradient',false); 

This case has the same hazard as the first two combinations. There is a possibility that one or both of SpecifyObjectiveGradient and SpecifyConstraintGradient were supposed to be turned on. In this case, however, Matlab can intercept the hazard because it is suspicious for both gradient calculations to be turned off yet to have DerivativeCheck='on'. So, what you propose would improve things. However, since the user still has to be alert to the DerivativeCheck output in the other cases, it is a very partial solution to the problem.

[Snoopy]

I would lke to emphasize that I do read the very elaborate responses and I can only thank for that. The discussion has added value I believe. It is only that I sometimes found it difficult how I should interpret some responses but now they are all clear to me. Your last post explains it all and I only agree. My whole or only point is about the last example. In that case we both seem to agree that a warning would not hurt. It would be in line with the overall ecosystem of MATLAB where MATLAB nicely gives warnings for many different suspicous user mistakes while other crap alternatives do not.