Run another script via run parameter

Hello,

I have the following issue:

I have different data sets that I define in different files, for example:

fileA.m:

var1 = 5;

var2 = 7;

fileB.m:

var1 = -9;

var2 = 15;

And then I have my main script, in which I need to do something with the var1 and va2 variables. At the time of the calling of the main script, I would like to choose which prior script to run first to populate the workspace with the right var1 and var2. For now, In my main script I call the needed script by hand at the beginning, but that requires me to edit the script content each time I want to change the "database".

What is the best way to solve this? A mat file does not help, as it is a binary file...

I would appreciate all help!

EDIT: I notice that I can also just run scripts one by one, i.e.:

fileA, myEndScript

But not sure whether thats the optimal way for this.

Answer 1

[Jan]

The best way is to avoid scripts and to use functions instead. Scripts increase the complexity of the code, because side effects can appear and influence the behaviour of the program over a long distance. This impedes the debugging.

Example:

% Script 1:
a = zeros(1, 10);
...

% Script 2:
for k = 1:5
    a(k) = k;
end
a(end)   % This is not the 5th element!

Using functions keeps the workspaces clear and avoid unexpected side-effects.

You can store both data sets in one function:

function data = DataSet(Name)
switch Name
    case 'Set 1'
        data.var1 = 5;
        data.var2 = 7;
    case 'Set 2'
        data.var1 = -9;
        data.var2 = 15;
end
end

Now provide the name of the wanted data set to the main function:

function main(DataName)
data = DataSet(DataName)
...
end

Now you can control dynamically, which data are used and do not have to modify the code.

Use variables to access data dynamically. Editing scripts is an indirection to do this. You know the concept of using functions from all of Matlab's toolboxes. Scripts are useful for short hacks only, while productive code should not contain any scripts.

[Lukasz Przenioslo]

Hi Jan, thanks for the answer!

The rationale in my case is to allow different people to create "databases" and provide them for usage with the main calculation script. Because of that, I should not have a switch in the calculation script (or function). A separate file is needed for each data set.

[Steven Lord]

I'm going to put all five functions demonstrating three potential approaches in one "file" here but you could have them separated.

x = approach1('data1')

x = struct with fields:
    fun1: 1
    fun2: 2

y = approach1('data2')

y = struct with fields:
    fun1: 3
    fun2: 4

z = approach2(@data1)

z = struct with fields:
    fun1: 1
    fun2: 2

w = approach2(@data2)

w = struct with fields:
    fun1: 3
    fun2: 4

a = approach3(1)

a = struct with fields:
    fun1: 1
    fun2: 2

b = approach3(2)

b = struct with fields:
    fun1: 3
    fun2: 4

function D = approach1(filename)
% Accepts a "database" function name
f = str2func(filename);
D = f();
end
function D = approach2(fh)
% Accepts a function handle to a "database" function
D = fh();
end
function D = approach3(n)
% Accepts a numeric suffix used with the common prefix for "database"
% function names
f = str2func("data" + n);
D = f();
end

% "database" functions
function s = data1
s = struct('fun1', 1, 'fun2', 2);
end
function s = data2
s = struct('fun1', 3, 'fun2', 4);
end

Approach1 uses the name you pass into it as input to create a function handle to that database function and calls the function via that function handle.

Approach2 requires a little more technical knowledge from your users as they'll need to create the function handle to the database function themselves and pass it into the approach2 function.

Approach3 requires your database functions to have a common prefix for their name. It combines the input number with that common prefix, creates a function handle to it, and calls the database function using the function handle.

[Lukasz Przenioslo]

Hi Steven,

Thank you for the answer. With approach 1, what is the database exactly?

[Steven Lord]

In all three approaches the "database functions" are data1 and data2. Adding a new function data3 would not require any changes to the code of the approach1, approach2, or approach3 functions. It would require a change to how those approach* functions are called.

[Lukasz Przenioslo]

Maybe I just dont grasp itz but it still feels counter untuitive. What is the format of the database, like physically?

[Jan]

Do not provide "data bases" as Matlab scripts. Use binary or text files instead, MAT files or the professional approach is a real data base, of course.

A patchwork of scripts is the horror for productive work. As soon as several persons should this this code, the scripts will get muddy very soon.

[Lukasz Przenioslo]

Hi, Im ok with not using scripts as databases, but at the same time these cannot be mat files, as these are binary. Text file could be ok, but then what would be the format- json, ini, xml? Xml and json are not very human readable. Ini could work, as it would look the same as a script with vars.