How are the variables being changed in this recursive relationship?

Can someone explain how the value of n is being changed in this fibbonaci recursive relationship. Specifically, which line of code causes the value of n to change?

function [out] = recfib(n)
% 1 1 2 3 5 8 13
% nth term = (n-1)th term + (n-2)th term
% Fib(n) = Fib(n-1) + Fib(n-2)
if n <= 2
    out = 1;
    disp(out)
else
    out = recfib(n-1) + recfib(n-2);
    disp(out)
end
end

[Stephen23]

"Specifically, which line of code causes the value of n to change?"

out = recfib(n-1) + recfib(n-2);
%            ^^^   here    ^^^

[Camden Nelson]

So is n simaltaneously 4 and 3 after the first iteration?

[Stephen23]

"So is n simaltaneously 4 and 3 after the first iteration?"

In two different function workspaces, yes (assuming that the input value is 5, which you did not state).

[Camden Nelson]

So how does Matlab distinguish between the two variable assignments when you iterate through the code? Like which one takes precedent?

[Stephen23]

"So how does Matlab distinguish between the two variable assignments when you iterate through the code?"

By creating two separate workspaces.

"Like which one takes precedent?"

Neither one takes precedence: two separate function calls create two separate workspaces.

Answer 1

[Walter Roberson]

out = recfib(n-1) + recfib(n-2);

First MATLAB parses the line of code to ensure that it is syntactically meaningful. If, for example, the line of code was

out = recfib(n-1) + recfib[n-2);

then MATLAB would reject the line before anything is calculated.

Once MATLAB has parsed the line of code, it starts executing the code starting from the left. It finds the recfib(n-1) part and says to itself that function call is a high priority operation: there is no operation that you could place immediately after the recfib(n-1) that would cause it to execute the other operation first. But before it can make the function call, it has to calculate the n-1 part. It does so based on the current n at the current call level of the statement. It does the subtraction, returning an unnamed temporary value. It then makes a function call to recfib, passing in that temporary value. During the time it is making that function call, the rest of the line, the + recfib(n-2) part is suspended . During the call to recfib(n-1), everything at the current level is suspended. Eventually the call to recfib(n-1) will return an unnamed temporary value, and values will be restored, including the n. Then, MATLAB will see the + operation and know that an addition has to be done. But the value to be added is the result of recfib(n-2). MATLAB computes the n-2 -- the n it uses here is the same n that was used for the (n-1) part. The result of the n-2 is passed to recfib suspending the current state while it does that calculation and returning a temporary value. When the call to recfig(n-2) returns, the state is restored, and the temporary value resulting from the recfib(n-1) is added to the result of the recfib(n-2) call, generating a new value that is stored in out at this level. The value is displayed. Then the value of out is returned to the caller.

The code never explicitly modifies n and there is no point in the code at which it modifies n: it just does some calculations based upon n and passes the result of the calculation to a function. The function that is called has its own state.

Suppose the code had instead been

function [out] = recfib_alternate(n)
if n <= 2
    out = 1;
else
    out = allegro(n-1) + pontify(n-2);
end
end

where allegro and pontify were some other functions that did some calculation. Then the flow at the MATLAB level would be the same: n-1 would be calculated, the result would be passed to allegro(), the result of the call would be remembered, n-2 would be calculated, the result would be passed to pontify(), the result of the call would be remembered, the two calculated values would be added. So the fact that recfib() calls itself does not matter to MATLAB: it is exactly the same flow as in the case where recfib_alternate calls two different functions. And the code for those could be

function out = allegro(n_minus_1)
    out = recfib_alternate(n_minus_1);
end
function out = pontify(n_minus_2)
   out = recfib_alternate(n_minus_2);
end

It does not matter to MATLAB (other than execution speed and possible memory overflow) that these functions (neither of which has any variable named n) end up calling recfib_alternate to do the work, and it does not matter that eventually the n-1 or n-2 will become known as the "nickname" n when recfib_alternate is eventually called.

It is important to understand that in (most) computer programming, there is not just one single global location for any particular variable name: that (most) names are local names.

Using local contextual names is common in every-day life. For example, when I was growing up, one of my grandmother's formal name was similar to Guinevere Wallace, but her family called her a name similar Ginny (which is also the name she used at work). There are other "Ginny" in the world, but within that context using "Ginny" was enough. Family tradition on both my mother's side and father's side was that grandmothers are called "Nana", so my siblings and I needed a way to distinguish the two Nana. So we called Guinevere Wallace "Big Nana" and my other grandmother "Little Nana" when we needed to distinguish, but "Nana" when dealing with them individually. One entity with multiple local names that are usable within context. And it is perfectly understandable to say that we went to one set of grandparents on Christmas and gave a present to Nana there ("Little Nana") and then we went to the other set of grandparents the same day and gave a present to Nana there ("Big Nana", also known as "Nana", also known as "Ginny", formally "Guinevere Magdeline Wallace" for legal purposes, which might maybe have been globally unique over history but probably the combination had occurred at some other point in history.)

We deal with local names all the time in real life. Perhaps at some point you yourself were "Closing Manager on Duty" somewhere -- and the next day when you were not scheduled there, someone else might have been "Closing Manager on Duty". It is not confusing to say that "The Closing Manager on Duty is responsible for setting the alarm system" and to understand that it does not refer to a single globally unique person but rather to the person currently undertaking the role of "Closing Manager on Duty".

So it is that you can have two different function call layers both referring to n without requiring there be only "one" n that is getting modified. You might be the Closing Manager on Duty in one establishment, but if you walked next door to pick up a coffee you would probably not be the Closing Manager on Duty at that establishment. The same entity can have multiple contextual names and roles, and any one particular local name can contextually refer to different entities.