Yes, you THINK the true answer is 3. But it is not.
format long g
log(2653/2500) / log(51/50)
And that is effectively the exact answer (to 16 significant digits) to the problem you posed. You could have made MATLAB convert that number to a floating point number, using either vpa or double.
What would the true left hand side have been, if 3 had been the correct result?
12000*sym('1.02')^3
So you had 12734.40 in the equation you tried to solve. Should MATLAB have solved a different problem than the one you posed? Surely not! MATLAB cannot know that you only had approximate coefficients, and that you expected an integer result. At least not unless you tell it to look for an approximate solution using some more appropriate solution method.
For example, if I use a solver that can constrain the unknown to be an integer, minimizing the absolute error, I get this:
fun = @(x) 12734.40 - 12000*1.02.^x;
lb = 0;
[xval,fval,exitflag] = ga(@(x) abs(fun(x)),1,[],[],[],[],lb,[],[],1)
Here MATLAB was able to find an integer solution.
