Absolute and Relative Approximate Errors for Secant Method in MATLAB

  • Context: MATLAB 
  • Thread starter Thread starter chronicals
  • Start date Start date
  • Tags Tags
    Matlab Method Secant
Click For Summary

Discussion Overview

The discussion revolves around the implementation of the secant method in MATLAB for finding the root of a specific equation. Participants are focused on troubleshooting an infinite loop issue and correctly calculating the absolute relative approximate error at each iteration. The conversation includes technical details about the algorithm, error calculations, and the implications of different approaches to error measurement.

Discussion Character

  • Technical explanation
  • Mathematical reasoning
  • Debate/contested

Main Points Raised

  • One participant describes their initial attempt to implement the secant method and encounters an infinite loop, seeking help to resolve it.
  • Another participant suggests that the calculation of the absolute relative approximate error may be incorrect and questions the use of the current error calculation method.
  • Some participants express confusion about the choice of using the absolute function of the function value (fnnew) as the error metric instead of the relative error based on previous iterations.
  • There is a discussion about the scaling of the relative error by 100 and its implications for understanding the accuracy of the results.
  • One participant argues that using the previous error (err(iter)) is more appropriate for convergence, while another suggests that the current method may lead to incorrect results if the true root is not zero.
  • Participants discuss the potential reasons for the infinite loop, including floating point errors and the behavior of the algorithm around the true answer.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the best approach to calculate the relative approximate error, with differing opinions on the use of scaling and the choice of error metrics. The discussion remains unresolved regarding the optimal method for error calculation in the context of the secant method.

Contextual Notes

There are limitations in the assumptions about the convergence behavior of the algorithm and the definitions of error metrics being used. The discussion highlights the complexity of accurately measuring error in iterative methods without a known true value.

chronicals
Messages
35
Reaction score
0
I try to solve this equation with secant method in MATLAB.

fn=40*n^1.5-875*n+35000

my initial guess is n1=60; n2=68; I want to find root and absolute relative approximate
error at the end of each iteration. I have an infinite loop. Can you help me repair my file?
This is my m-file:

clc
clear
n1=60;
n2=68;
tol=1e-3;
err0=3;
iter=0;
fprintf('iteration n relative approximate error\n')
while err0>=tol
iter=iter+1;
fn1=40*(n1).^1.5-875*(n1)+35000;
fn2=40*(n2).^1.5-875*(n2)+35000;
nnew=n2-fn2*((n2-n1)/(fn2-fn1));
fnnew=40*(nnew).^1.5-875*(nnew)+35000;
err(iter)=(abs((nnew-n2)/nnew))*100;
fprintf('%2d %f %f\n',iter,nnew,err(iter))


if nnew>n1
n1=nnew;

else
n2=nnew;

end

end
nnew
iter
 
Last edited:
Physics news on Phys.org
I rearranged my m-file and i solved infinite loop problem but i think i have mistaken at calculating absolute relative approximate error at the end of each iteration, i think this command is wrong:

err(iter)=(abs((nnew-n2)/nnew))*100;

How can i fix this error calculation problem?



My m-file:

clc
clear
n1=60;
n2=68;
tol=1e-5;
err0=3;
iter=0;
fprintf('iteration n relative approximate error\n')
while err0>=tol
iter=iter+1;
fn1=40*(n1).^1.5-875*(n1)+35000;
fn2=40*(n2).^1.5-875*(n2)+35000;
nnew=n2-fn2*((n2-n1)/(fn2-fn1));
fnnew=40*(nnew).^1.5-875*(nnew)+35000;
err(iter)=(abs((nnew-n2)/nnew))*100;
fprintf('%2d %f %f\n',iter,nnew,err(iter))
err0=abs(fnnew);


if nnew>n1
n1=nnew;

else
n2=nnew;

end

end
nnew
iter
 
Last edited:
Why are using abs(fnnew) as your error, isn't it err(sayac) ? I would also remove the factor of 100 from the relative error unless it is your meaning to express it as a percent relative error. Trivial quibble but the nice thing about the relative error is that the base 10 log of it gives you an estimate on the number of digits it is accurate to in decimal. So by setting your tol to 1e-5, you are desiring to be accurate to at least five digits.
 
Born2bwire said:
Why are using abs(fnnew) as your error, isn't it err(sayac) ? I would also remove the factor of 100 from the relative error unless it is your meaning to express it as a percent relative error. Trivial quibble but the nice thing about the relative error is that the base 10 log of it gives you an estimate on the number of digits it is accurate to in decimal. So by setting your tol to 1e-5, you are desiring to be accurate to at least five digits.

If I use err(iter), I have an infinite loop, so I use abs(fnnew).

These are my results:

iteration n relative approximate error
1 62.759758 8.349685
2 62.689966 8.470309
3 62.691698 0.002762
4 62.691697 0.000001

nnew =
62.6917

iter =
4

how can second iterations' relative approximate error be 8.470309. I think this m-file is calculating 'relative approximate error' wrongly. Please help me fix this error command: err(iter)=(abs((nnew-n2)/nnew))*100;
 
It is 8.4 because you are scaling the relative error by 100. Like I said, if you do not scale then the log of the relative error is indicative of the number of digits of accuracy. Indeed, you note that the first two digits, 62, do not change as you converge. Thus, you started out with two digits of accuracy which would correlate to log(0.08).

Using err(iter) is the proper thing to do. Right now fnnew only works because it is the same as the absolute error since you are trying to find the zero. But if you were trying to converge to any number other than zero then you would never converge properly. Which brings us to the relative error. That is not the relative error because you do not know the true answer. It is a measure of the difference between your old and new values I think. This is still a reasonable metric to use though as long as we assume that you are always converging at a constant or increasing rate (this could allow us to use this metric to estimate the actual relative error but that is unnecessary for most applications). For example, I use this when I do semi-infinite integrations.

From your sample output, it should have converged in four iterations since the "error" is 1.0e-6. If you removed the scaling factor of 100 then this should happen. If it is not ending, then it is probably because the result is fluctuating back and forth around the true answer. If you increased your tolerance slightly this may allow you to achieve convergence. This can happen due to floating point errors, getting trapped around an incorrect guess, or due to deficiencies in the algorithm.

EDIT: Hmmm... probably should be a little more blunt. In this case, you should use abs(fnnew) because you know that the result should be zero and thus abs(fnnew) is the amount by which the result is off from zero. So you can find the residual. That is, you can't find the error in the x you wish to find (since obviously you do not know x apriori) but you can find the error in the f(x) that you want to achieve. This is not always feasible. Sometimes, like say with an integration, you do not have such a metric to use. So using the relative change to the result, like you found in err(), is often a valid metric. Though, as you have found, it may not always be perfectly reliable.
 
Last edited:

Similar threads

  • · Replies 10 ·
Replies
10
Views
4K
Replies
7
Views
9K
  • · Replies 6 ·
Replies
6
Views
4K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 2 ·
Replies
2
Views
2K
Replies
2
Views
42K
  • · Replies 3 ·
Replies
3
Views
3K
  • · Replies 2 ·
Replies
2
Views
4K