Clear Filters
Clear Filters

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

4 views (last 30 days)
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');

Accepted Answer

Matt J
Matt J on 29 Jan 2023
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.
  1 Comment
Snoopy
Snoopy on 29 Jan 2023
Edited: Snoopy on 29 Jan 2023
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.

Sign in to comment.

More Answers (3)

John D'Errico
John D'Errico on 27 Jan 2023
Moved: Walter Roberson on 27 Jan 2023
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?
  3 Comments
John D'Errico
John D'Errico on 29 Jan 2023
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
Snoopy on 29 Jan 2023
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.

Sign in to comment.


Matt J
Matt J on 28 Jan 2023
Edited: Matt J on 28 Jan 2023
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.
  6 Comments
Snoopy
Snoopy on 28 Jan 2023
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
Matt J on 29 Jan 2023
Edited: Matt J on 29 Jan 2023
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.

Sign in to comment.


Matt J
Matt J on 28 Jan 2023
Edited: Matt J on 28 Jan 2023
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.
  3 Comments
Matt J
Matt J on 29 Jan 2023
Edited: Matt J on 29 Jan 2023
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
Snoopy on 29 Jan 2023
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.

Sign in to comment.

Categories

Find more on Historical Contests in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!