Why are empty square brackets used in this fsolve function?

Here is the fsolve code.

x0 = [0.001 0.001 0.001 0.993 1 0.0001 5.992 1 0.001 10 10 10]'
T = 1000
[x,fval] = fsolve(@Gibbs, x0, [ ], T)

I don't understand why the empty squre brackets are used..

If it's not used, it shows error message like 'Failure in initial user-supplied objective function evaluation. FSOLVE cannot continue'.

The function of Gibbs is on the x, T (12x1 matrix)

function [ f ] = Gibbs( x,T )
R = 1.9872
ns = sum(x(1:9));
G01= 4.61e3; G02=28.249e3; G03=40.604e3; G04=-94.61e3; G05=-47.942e3; G08=-46.03e3; G09=26.13e3;

f(1,1) = 2*x(4)+x(5)+2*x(6)+x(8)-4
f(2,1) = 4*x(1)+4*x(2)+2*x(3)+2*x(7)+2*x(8)+6*x(9)-14
f(3,1) = x(1)+2*x(2)+2*x(3)+x(4)+x(5)+2*x(9)-2
f(4,1) = x(1)-ns*exp(-G01/(R*T)-1+x(1)/ns-(4*x(11)+x(12)))
f(5,1) = x(2)-ns*exp(-G02/(R*T)-1+x(2)/ns-(4*x(11)+2*x(12)))
f(6,1) = x(3)-ns*exp(-G03/(R*T)-1+x(3)/ns-(2*x(11)+2*x(12)))
f(7,1) = x(4)-ns*exp(-G04/(R*T)-1+x(4)/ns-(2*x(10)+x(12)))
f(8,1) = x(5)-ns*exp(-G05/(R*T)-1+x(5)/ns-(x(10)+x(12)))
f(9,1) = x(6)-ns*exp(-1+x(6)/ns-(2*x(10)))
f(10,1) = x(7)-ns*exp(-1+x(7)/ns-(2*x(11)))
f(11,1) = x(8)-ns*exp(-G08/(R*T)-1+x(8)/ns-(x(10)+2*x(11)))
f(12,1) = x(9)-ns*exp(-G09/(R*T)-1+x(9)/ns-(6*x(11)+2*x(12)))
end

[Alex Sha]

Hi, I get the solution as below:

x1: 0.081717612832349
x2: 1.7165724341752E-7
x3: 3.00019124411767E-10
x4: 0.664820893821221
x5: 1.25346024909972
x6: 1.12289287107677E-11
x7: 5.4196651169683
x8: 1.41689796323103
x9: 4.50177027478041E-7
x10: 24.0518309842135
x11: 0.0510933495572929
x12: 1.1684109105753

Fevl:
-4.35029789969121E-12
1.92326155001865E-11
2.1870061317486E-11
-3.58435503500232E-13
1.75226624980123E-12
-7.92100894796531E-11
-1.33415500869205E-11
1.15079057394496E-11
1.1228928706591E-11
6.44639897018351E-12
2.51931808747941E-12
6.11379418893715E-12

Answer 1

[dpb]

It's an undocumented trap door that allows other parameters to be passed to the objective function; the [] placeholder bypasses the input 'options' third argument and everything past the third argument is passed via varargin

Internally, fsolve ends up with a call that looks like

fuser = feval(funfcn{3},x,varargin{:});

which translates with the above input to

fuser = feval(@Gibbs,x,T);

which is programmatic expression equivalent to writing

fuser = Gibbs(x,T);

at the command line.

I don't recall when the doc removed the explanation; R2014b is earliest I now have installed and it isn't there; by then had replaced the documentation with the illustration of how to use anonymous functions to wrap the actual into a one-argument version or to use nested functions.

But, the syntax hasn't been removed in the input processing; one presumes for backward compatibility. It could, however, break at any time going forward.

[Walter Roberson]

This is a correct explanation.

The documentation on the facility was, IIRC, removed even before MATLAB started using years to name releases.

[Steven Lord]

I haven't checked but I'm guessing it was removed from the documentation in release R14 (not R2014a or R2014b, but the release that came out in 2004. Release numbers started using years with release R2006a.) We introduced anonymous functions in release R14 and those provide a cleaner solution to passing additional parameters into the objective functions, ODE functions, integrand functions, etc. for those functions that accept function handles.

[dpb]

Well, it may be "cleaner" in the interface but it's more painful to get the second parameter into the function when it has to be wrapped into another that hides it from the outer level.

In this case here, one can simply set the desired temperature at the same time; the other way one has to redefine the wrapper function handle to embed the T parameter inside it.

I don't see there being a legitimate reason to not at least document it is a feature.

Then again, if one is old enough and long-enough user to remember the time before so recognized the idiom, one is from the era before all the new-fangled ideas of encapsulation and all were that prevalent so it just seems OK to me. :)

I did have to go and get the exact syntax used to reconstruct the details, but I did recognize the idiom... :)