Unable to assign result from function to variable

I recently made a function to perform Gaussian Elimination on a matrix, then calculate its determinant if it exists.

It works perfectly fine if I simply call the function. However, the odd part is that I get the "output argument not assigned" error if I attempt to store the result as a variable.

Initialising the output variable to 0 within the function before it gets assigned its actual value returns both numbers, in spite of the output variable being double rather than a vector. Initialising it before declaring my persistent variables makes it worse; it returns three zeroes along with the actual value instead. If I attempt to store the output of the function as a variable after performing this initialisation, it only stores one of the values.

Note that the output variable in the function remains double within the function the entire time. Oh, and I suppose I should mention that the error occurs in the line where I declare the persistent variables. Could that be causing the problem? It's the crux of the code though...

[Stephen23]

If you don't actually post the code, how are we supposed to know what is happening? We have not yet learned to read minds, and surprisingly we also can't read your computer monitor

If you actually want help with this, you need to help us by giving useful information:

http://de.mathworks.com/matlabcentral/answers/6200-tutorial-how-to-ask-a-question-on-answers-and-get-a-fast-answer

Please edit your question to give the exact code that you are using. You can either include this within the text of your question (please format it correctly using the {} Code button) or if it is large then upload it as a file (use the paperclip button).

It would also be useful if we know exactly how you are calling your function.

[Joshua]

Fine. I had just thought that someone might have had the same issue at some point.

Answer 1

[Stephen23]

The error does not really occur on the line persistent ..., it is actually a problem of the code analyzer knowing that one of the outputs will not be defined, and so it highlights the first line of code, which happens to be persistent ....

You can confirm this by inserting disp('hello world') ahead of persistent, and you will find that then this line will be indicated as having the error. Doing this will also show you that the function runs four times without error, and that on the fifth (nested?) call the error occurs.

So the error is your algorithm. But honestly I gave up trying to understand it using the debugger , after the function called itself for the fourth time. So many nested function-calls, multiple persistent variables, loops-galore and an occasionally-self-cleared function, just to calculate the determinant?

If you want reliable code, just use det instead.

[Joshua]

This is an assignment. I'm not supposed to use det.

I'm supposed to write a function that specifically uses Gaussian Elimination to obtain the determinant.

[Stephen23]

Fair enough. Currently you are the person who know this function better than anyone else. I suggest that you use MATLAB's debugging tools to figure this out. Note that this includes being able to set conditional break-points, which might be very useful for you.

[John D'Errico]

The thing is, while it is nice to see modular code employed, that and recursion here are way overkill. A simple for loop is sufficient to compute the determinant directly from Gaussian elimination. You get the determinant from the final pivot element. Be careful that if you are doing row or column exchanges, then there is a power of -1 introduced for every interchange.

The point is, recursion is not in general an efficient way to compute things in MATLAB, because of function call overhead. And as you can see, writing code in a way that requires these extreme efforts makes the code a pure nightmare to debug.

[Joshua]

Okay, managed to rewrite the thing as a while loop without any recursion of the function. Seems to work fine now, so clearly it was the recursion that was causing problems.

And yeah, I agree it was a nightmare to debug. I honestly have no idea why I went with recursion for that thing.

Moral of the story: Avoid recursion where possible.

[John D'Errico]

I think sometimes we see one solution, and it blinds us to other approaches. Recursion is useful at times, although it is often possible to write what seems naturally a recursive scheme using a simple loop.

For example, factorial(n) seems so logically recursive to write, yet it is not at all a good way to implement that function due to the function call overhead. Instead, the implicit loop, prod(1:n) is a far better solution in MATLAB.

Another example is the Fibonacci sequence. IF you write it using the logical recursive function scheme, then you will find yourself making something like O(2^n) recursive calls, when a direct loop that requires O(n) operations is sufficient. In fact, you can write code for the n'th Fibonacci number in a way that requires something like O(log2(n)) operations. So the recursive scheme is obscene there.

At the same time, recursion is a very natural way to write things like an adaptive Simpson quadrature, and it works quite well there. Even that can be written non-recursively though, in a way that will generally be more efficient. I've also found recursion as an effective way to compute the set of all partitions of the number N.

So don't totally give up on the idea. Keep it in your box of programming tricks. Just know when to avoid it.