What is the recommended way to pass long list of parameters between main workspace and function?

In my work I encountered a problem with passing variables betwen main script and function. Of course I can do it manually:

a1=1;a2=2;a3=3;a4=4;a5=5; %The list is much longer in my project, here just example
sum=calcvalues(a1,a2,a3,a4,a5);

function sum=calcvalues(a1,a2,a3,a4,a5)
sum=0;
b=[1,2,3];
    for i=1:3
        sum_tmp=sum_support(a1,a2,a3,a4,a5,b(i));
        sum=sum+sum_tmp;
    end
end

function sum_support = sum_support(a1,a2,a3,a4,a5,b)
    sum_support=a1*a2+a3^b+a4*a5;
end

But I have to retype all values every time, and after any modification in list of function inputs there is no option to sync with other executions. Additionally, the list is very long, and take space in every function, making the code less readable. My intention was to override this with

function sum=calcvalues(varargin)

But this doesn't preserve file names. The output is just a 1x5 cell with anonymouse numbers. So far I managed to use eval to assign names dyanmicaly but this does not looks like a good practise. What is the recommended way to restore/preserve the names?

EDIT to clarify:

Here is the closest solution to what I expected. However this requires to use save command to unpack the structure. Is it possible to do this in more elegant way?

a1=1;a2=2;a3=3;a4=4;a5=5; %The list is much longer in my project, here just example
value_holder=struct('a1',a1,'a2',a2,'a3',a3,'a4',a4,'a5',a5);
sum=calcvalues(value_holder)
    function sum=calcvalues(value_holder)
        sum=0;
        b=[1,2,3];
        for i=1:3
            sum_tmp=sum_support(value_holder,b(i));
            sum=sum+sum_tmp;
        end
    end
    function sum_support = sum_support(value_holder,b)
        save('temp.mat','-struct','value_holder')
        load('temp.mat')
        sum_support=a1*a2+a3^b+a4*a5;
    end

[Stephen23]

"Additionally, the list is very long, and take space in every function, making the code less readable"

Best avoided.

"So far I managed to use eval to assign names dyanmicaly but this does not looks like a good practise."

Only if you want to force yourself into writing slow, complex, inefficient code that makes debugging harder.

"What is the recommended way to restore/preserve the names?"

One structure.

[Karol P.]

I have system of ODE's that require cetratin number of side-values, Nothing to avoid here, they need it, and I cannot do anything to prevent the use of long list of variables. Structure is the same as typing all values manually + I have to re-assign everything to avoid prefixes, or rewrite several dozen of euqtions. so it looks like a very poor way to do this.

[Stephen23]

"However this requires to use save command to unpack the structure."

Which dynamically creates all of the variables in the workspace, so .... best avoided.

"Is it possible to do this in more elegant way?"

Access the data directly from the structure.

"so it looks like a very poor way to do this."

In fact it is probably the best way to do this. Or perhaps nested functions.

Your approach is the opposite of what experienced users would do (e.g. you moved file import/export into the objective function, resulting in slow code) and making variables magically appear (slow, harder to debug, etc). A structure has benefits in terms of memory usage and convenience.

[Karol P.]

It's hard to believe it is the best way. Such a simple task and the answer is to rewrite half of the script? For a reference: some of c# compliers have the option to one-click sync the header of declaration and execution of function. Here I feel like we fight with a problem the Matlab creates artificially.

[Stephen23]

"It's hard to believe it is the best way."

It is very easy to believe, once you know something about how variables are stored and passed.

As an alternative, have you considered using nested functions?

[Karol P.]

Does any of ODE solvers support nested function? If no, @Matt J proposition is so far the best.

[Stephen23]

"Does any of ODE solvers support nested function?"

There is nothing preventing you from using nested functions as the objective function in an ODE solver.

Answer 1

[dpb]

If the variables are such as your example of a sequence of number variables with same root name, that implies they're related/same thing, just different instances. In that case I'd use an array and indexing -- "A" instead.

Alternatively, if they are actually different variables, take those that are related and create a structure to pass for succinctness and then reference the component variables in the struct.

Alternatively, if there are a lot of disparate variables, consider putting them into a table and pass the table.

Would need a lot more information about the actual variables and their use to have specifics, but design the data structure around the problem and then implement it, don't just create variables willy-nilly with no overall structure.

[Karol P.]

They are set of different variables, without simple relation between each other. They are required to solve ODEs set, so structure is very time consuming solution, as I would have to rewrite several dozen of equations withe structure prefixes. Or manually reload each one like:

a1=s.a1;

What do you mean with the table? Manually assign every single variable? It is half of solution. I would have easier job, as I have to pack it to table once, but it still requires lots of work.

If you need any extra details, I did not provided in question and in this comment, please do not hesitate to ask, I appreciate your help.

[Matt J]

as I would have to rewrite several dozen of equations withe structure prefixes. Or manually reload each one like:

instead of writing the unloading commands manually, you could use this code-writing tool,

https://www.mathworks.com/matlabcentral/fileexchange/26216-structure-fields-to-variables?s_tid=FX_rc1_behav

[Karol P.]

This would be good, if it really extract values to workspace, not generate just a text. Again I try to keep my code clean, without of bunch of multilines reloading of values.

[Matt J]

It generates text, but the idea is that you can copy/paste the text, which is much less manual work.

[Karol P.]

I know and I appreciate. It is helpful in some cases. But still the solution I show in EDIT looks much more natural for my project.

[Matt J]

No, it is not more natural. Using the load command without an output argument,

S=load('temp.mat')

is a dangerous and discouraged practice. It is precisely what structvars was created to avoid.

[Karol P.]

I would do use structvars if it unpack variables directly to workspace. But in current form it will make my code very long and hard to work on it. Untill I will found other solution the save/load trick is the only solution. I think as long as I do not re-use temp.mat file it is quite safe.

[Matt J]

But in current form it will make my code very long and hard to work on it.

I don't see why. Even if you had 100 variables, the output of structvars can fit on 10 lines of code, or even less. If your actual calculations involve 100 variables, they would have to consume far more lines than this.

>> args=cell(2,100); args(1,:)=cellstr("a"+(1:100));

>> s=struct(args{:}); whos s

>>structvars(10,s);

a1 = s.a1; a11 = s.a11; a21 = s.a21; a31 = s.a31; a41 = s.a41; a51 = s.a51; a61 = s.a61; a71 = s.a71; a81 = s.a81; a91 = s.a91;

a2 = s.a2; a12 = s.a12; a22 = s.a22; a32 = s.a32; a42 = s.a42; a52 = s.a52; a62 = s.a62; a72 = s.a72; a82 = s.a82; a92 = s.a92;

a3 = s.a3; a13 = s.a13; a23 = s.a23; a33 = s.a33; a43 = s.a43; a53 = s.a53; a63 = s.a63; a73 = s.a73; a83 = s.a83; a93 = s.a93;

a4 = s.a4; a14 = s.a14; a24 = s.a24; a34 = s.a34; a44 = s.a44; a54 = s.a54; a64 = s.a64; a74 = s.a74; a84 = s.a84; a94 = s.a94;

a5 = s.a5; a15 = s.a15; a25 = s.a25; a35 = s.a35; a45 = s.a45; a55 = s.a55; a65 = s.a65; a75 = s.a75; a85 = s.a85; a95 = s.a95;

a6 = s.a6; a16 = s.a16; a26 = s.a26; a36 = s.a36; a46 = s.a46; a56 = s.a56; a66 = s.a66; a76 = s.a76; a86 = s.a86; a96 = s.a96;

a7 = s.a7; a17 = s.a17; a27 = s.a27; a37 = s.a37; a47 = s.a47; a57 = s.a57; a67 = s.a67; a77 = s.a77; a87 = s.a87; a97 = s.a97;

a8 = s.a8; a18 = s.a18; a28 = s.a28; a38 = s.a38; a48 = s.a48; a58 = s.a58; a68 = s.a68; a78 = s.a78; a88 = s.a88; a98 = s.a98;

a9 = s.a9; a19 = s.a19; a29 = s.a29; a39 = s.a39; a49 = s.a49; a59 = s.a59; a69 = s.a69; a79 = s.a79; a89 = s.a89; a99 = s.a99;

a10 = s.a10; a20 = s.a20; a30 = s.a30; a40 = s.a40; a50 = s.a50; a60 = s.a60; a70 = s.a70;

[Karol P.]

Ok, after using profiler I must say that your solution is better. Maybe I will have to add extra few lines, but load/save tasks consume like half of the total operation time, so the choose is quite oblivious. I was not expecting they are so much slower than working inside workspace. Thank you!

[Matt J]

Alright, I'm mentioning this against my better judgement, but you can unpack the variables in the implicit manner that you want by doing,

eval(structvars(s)')

This might be a compromise in performance between load/save and my suggestion. However, eval() has at least the same programming hazards as load(), so take great heed of the discussion here,

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

Answer 2

[Steven Lord]

If all your variables are related and so should remain together, I would pack them into a struct array.

s = struct('a1',1,'a2',2)

s = struct with fields:
    a1: 1
    a2: 2

s.a3 = 3;
s.a4 = 4;
s.a5 = 5

s = struct with fields:
    a1: 1
    a2: 2
    a3: 3
    a4: 4
    a5: 5

Now you can pass s into and out of your function and use the values in its fields in your function. Functions that need some but not all of the fields in the struct can ignore the ones they don't need, and you can add fields to the struct without affecting existing code.

[Karol P.]

Yes, I know this option, however as I said in other comment, I would have to rewrite several dozens od ODEs to add prefixes. It is very time consumming. and makes code less readable. So I cannot do this.

[Steven Lord]

Unpack just the variables that ODE function needs at the top of the ODE function. Or if a variable only appears once in the ODE function, you can index into the struct rather than creating an additional variable.

s = struct('a1',1,'a2',2,'a3',3,'a4',4, 'a5', 5);

function sum=calcvalues(s)
sum=0;

You shouldn't name your variable sum. That identifier already has a meaning in MATLAB.

b=[1,2,3];
    for i=1:3
        sum_tmp=sum_support(s,b(i));
        sum=sum+sum_tmp;
    end
end

function sum_support = sum_support(s,b)
    % The next few lines were added
    a1 = s.a1;
    a2 = s.a2;
    a3 = s.a3;
    a4 = s.a4;
    % a5 = s.a5; % Instead of doing this you can use s.a5
    sum_support=a1*a2+a3^b+a4*s.a5; % like I did here
end

[dpb]

For something that looks likes OP's example of a bunch of constants to retrieve, I think I'd do as you suggest and retrieve in the individual ODE functions the ones needed for the function --

s=struct('coeff',[1:5]);            % put all the coefficients in array instead of many (unuseful anyway) names

Then in each ODE function can write something like

IDX=[1,3,4];                % the needed coefficients for this ODE
S=sum_support(s,IDX);       % call the function with needed index array

function sum_support = sum_support(s,b)
  sum_support=sum(s.coeff(b))
end

At command line to show syntax works as expected...

>> s = struct('coeff',[1:5]);
>> IDX=[1 3];
>> sum(s.coeff(IDX))
ans =
          4.00
>> 

One could make things more simple for using for the ODE functions by creating either a struct array of an element of the coefficients for the given ODE and even have a name to ensure use right array element or if it's not too complicated, use a 2D array where each row contains the coefficents for the given ODE so the very long 1D string is given some structure associated with its use.

The disadvantage is that they are then position dependent so Steven's solution is better in that regards.

Answer 3

[Matt J]

In the case of your posted example, the appropriate re-implementation would be,

a=1:5;
result=calcvalues(a);

function accum=calcvalues(a)
accum=0;
b=[1,2,3];
    for i=1:3
        accum=accum+sum_support(a,b(i));
    end
end

function sum_support = sum_support(a,b)
    sum_support=a(1)*a(2)+a(3)^b+a(4)*a(5);
end

[Karol P.]

I made this values lazy way, they are not the following numbers in real code. So your proposition is not applicable.

[Matt J]

My proposal applies to any vector of numbers a.

[Karol P.]

Yes, but my variables are not a simple vector. Some can be string, some double, others are vectors itself. So it is not possible to use your solution, or I don't understand how.

[Matt J]

But if you have many scalar double variables, you can group them into a vector. If you have many vectors tof the same length, they can be grouped into a matrix or cell array. If you have many strings, they also can be grouped into a vector.

It would be unusual if, even after grouping variables together this way, you still have an unmanageably large number of variables.

[Karol P.]

But why you think the vectors are the same lenght? I never said that.

[Matt J]

I said "if" they are, not that I know that for a fact. If they aren't the same length, you can still possibly use a cell array.

The point though is that you should go through your variables to see which ones are similar in size and type, and which can be grouped into arrays.

Answer 4

[Catalytic]

Do not use load/save to introduce undeclared variables in your workspace. This can have unexpected effects as described in this doc page -

Unexpected Results When Loading Variables Within a Function

which also mentions recommended alternatives.

[Karol P.]

I don't have any conflicts with matlab in-build names. Anyway I'm surprised there is no build in function to unpack structure directly, and we have to use save with '-struct'flag.

[Catalytic]

The title of your question asks what is recommended. You can use the load/save technique at your own risk, but you should see now that it is not what MathWorks and the programmer community recommends.

[Karol P.]

I understand your point of view. However every alternative I see here is to make a lot of extra tasks and/or make the code less readable for user, to reach the same results. This seems not to be a good way to do such simple job.

[Catalytic]

The fact that you have a million different variables in your calculation means that the code will already be unreadable. Like the other contributors, I wonder if your variables could be better aggregated into vectors, matrices, and other array types. The MAT in MATLAB stands for matrix, and you should be using them.

[Karol P.]

The project is very complicated, and no, the values cannot be grouped like you suggest. If it would be that simple I would not bother to ask. Anyway, thank you for your suggestions, in more generalised case, you're right of course.