Simpson's rule for integration- finding area and centroid, program does not work.

5 views (last 30 days)
I have written a program for finding the area and centroid for a mathematical function, unfortunately it does not seem to work, and i am getting various errors.
Here is my code in full: main-
function main()
global a b h n temp
a=(-0.5);
b=0.5;
n=100;
h=(b-a)/n;
[area, temp]= simpson(fun, fun2);
area=2*area;
Xc=(1/area)*temp;
disp(area)
disp(Xc)
end
Simpson's method, the action itself-
function [ area, temp] = simpson( fun, fun2 )
%Simpson's 1/3 integration method and calculating required values
global a b h
[se1, se2]=sumev(h);
[so1, so2]=sumod(h);
area= (h/3)*(fun(a)+fun(b)+(2*se1)+(4*so1));
temp= (h/3)*(fun2(a)+fun2(b)+(2*se2)+(4*so2));
end
summing even intervals-
function [ se1, se2] = sumev( h )
%Looping function for summing the values in even intervals for
%each function
global n
for j=0:2:n-2
v=(2*j+2)*h;
se1=se1+fun(v);
se2=se2+fun2(v);
end
summing odd intervals-
function [ so1, so2 ] = sumod( h )
%Looping function for summing the values in odd intervals for
%each function
global n
for j=0:2:n-1
v=(2*j+1)*h;
so1=so1+fun(v);
so2=so2+fun2(v);
end
The first function-
function [ q ] = fun(v)
%The mathematical function to integrate for the area
q=(2*(v^2)+0.2*v+0.08)*sqrt(1-4*(v^2));
end
Second function, used to find the centroid-
function [ e ] = fun2(v)
%The mathematical function to integrate for the area
e=v*(2*(v^2)+0.2*v+0.08)*sqrt(1-4*(v^2));
end
As far as i see, it's a very simple program, i don't see any missed letters or variable names, yet i'm getting these errors when i try to run main-
Error using fun (line 3) Not enough input arguments.
Error in main (line 8) [area, temp]= simpson(fun, fun2);
Any ideas and help debugging would be much appreciated

Accepted Answer

John D'Errico
John D'Errico on 30 May 2015
I think you do not understand functions.
You have defined fun1 and fun2 as taking input arguments. READ THE ERROR MESSAGE!
Error using fun (line 3) Not enough input arguments.
Error in main (line 8) [area, temp]= simpson(fun, fun2);
Then you call them with no inputs.
[area, temp]= simpson(fun, fun2);
What did you expect to happen? Should MATLAB guess what to pass in? Of course not. You need to tell it.
  4 Comments
Rob Dunham
Rob Dunham on 30 May 2015
Thank you for taking so much time to try and help- a lot of advice in here, and i'll be applying it all from now on. Especially in regards to code readability.
A little update- my program was actually ok, all i had to do was define so/se 1 and 2 as zeroes for an initial value, and leave the parenthesis in "simpson" empty (both when calling the function and in the function line itself)
The reason i am using global variables and splitting every simple calculation into a function of its own is that i have to comply with the instructions, though it makes absolutely no sense, and makes things messier.
Anyways- everything works now, code also changed to be much easier to read, notes left in the code with more explanations. Thanks, i appreciate it.
John D'Errico
John D'Errico on 30 May 2015
Edited: John D'Errico on 30 May 2015
You can get away without the globals. If you want to pass n around, for example, simply pass it in as an argument to the function that needs it. Or use nested functions. A nested function can see the variables from the workspace of the caller.
But definitely head for readability as much as possible. I think about it in terms of the person who might inherit my code one year, if for example, I get run down by the cross-town bus. (Ok, there are some crazed people online that might be intentionally driving that bus, aiming it at me.) Would my successor want to inherit unreadable code? Even if the code works, if it is impossible to modify in the future because nobody can figure out how it works, then my legacy will be for naught.
Internal comments are a great way to make you code more readable. I like a target of one line of comment for every line of code, at least in complex code. Nobody says you need to hit that target all the time of course. And use descriptive variable names and function names. These make your code self-documenting, and always easier to read and follow.
So always look at your code as if you are reading it for the first time, as if you are the person who will be taking it over. If you do, your code will get better.

Sign in to comment.

More Answers (0)

Categories

Find more on Just for fun 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!