fminunc not giving the correct results
3 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
Athul Shaji
el 11 de Feb. de 2017
Editada: John D'Errico
el 11 de Feb. de 2017
if true
clc
close all
format long
m = 1;
c = 0;
x = linspace(-100,100,10001);
y = m*x + c;
plot(x,y,'r'),grid on, hold on;
costFunc =@(initial_guess) sum((y - (m*initial_guess(1) + initial_guess(2))).^2);
initial_guess = [2 2];
y = initial_guess(1)*x + initial_guess(2);
plot(x,y,'k'),hold on
options = optimoptions('fminunc','Display','iter','StepTolerance',eps);
[optimumValue,fval,exitflag,output] = fminunc(costFunc,initial_guess)
y = optimumValue(1)*x + optimumValue(2);
plot(x,y,'b')
legend('original','initial guess','fminunc output');
end
1 comentario
John D'Errico
el 11 de Feb. de 2017
Editada: John D'Errico
el 11 de Feb. de 2017
Why in the name of god and little green apples are you using fminunc to do a simple linear least squares, when polyfit will do that far faster, far more accurately?
Sorry, but your code is nasty to read. You use and reuse variables (y has several different meanings, as does initial_guess, just in this small block of code), making them mean a variety of things in the same block of code. One nice thing about MATLAB is they don't charge you extra if you use two variables instead of one! But code as you seem to want to write it is hell to read, hell to debug.
The point is, as I tried to read through your code, I'd see a variable. Then I'd need to look back, where did they define it? What was the value of that variable the LAST time it was defined? Reading and debugging code like that is pure hell, especially as your code grows in length.
Respuesta aceptada
John D'Errico
el 11 de Feb. de 2017
Editada: John D'Errico
el 11 de Feb. de 2017
The point about writing bug-inducing code as you are writing, is that you tend to create bugs. Happens very easily with such code. Sorry, but it does.
m = 1;
c = 0;
x = linspace(-100,100,10001);
y = m*x + c;
plot(x,y,'r'),grid on, hold on;
costFunc =@(initial_guess) sum((y - (m*initial_guess(1) + initial_guess(2))).^2);
Look at your cost function. Does it fix the value of m in there? m is just the number 1, NOT the vector x.
So if you are going to use a nonlinear optimization tool to fit a straight line, then you probably want to actually use x instead of m. But then, what do I know? :)
The point is, write slowly. Write CAREFULLY. Learn to not be sloppy in your code. Use good names for variables. Don't reuse variable names, but name them in ways that make their meaning obvious. Your code will improve. It will become less likely to contain bugs.
When you have an optimization, test the objective function. Verify that what it does makes sense. TEST IT, outside of the optimizer. Test all of your code, one line at a time if you are a novice programmer, until you are capable of writing large blocks of code with no errors.
0 comentarios
Más respuestas (0)
Ver también
Categorías
Más información sobre Bounding Regions en Help Center y File Exchange.
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!