Dipole scanning using only command lines

[JoonasJL]

People who are using command-based scripting would like to give the input parameters without GUI to the solver. However, the tool has the following lines (5-7):

    invMethod=eval( 'zef.dipole_app.InversionmethodDropDown.Value');
    regType=eval( 'zef.dipole_app.regType.Value');
    inv_leadfield_lambda=eval( 'zef.dipole_app.inv_leadfield_lambda.Value');

These lines are pointing towards opened app. One can of course add a line, e.g., zef.dipole_app.regType.Value = 1 and problem is solved, but this has already caused a great confusion, so it would be better if they are accessible as variables. Moreover, if one want to save the settings, the values should be stored to zef structure in a way or another because otherwise they are gone when the app is closed.

[SeSodesa]

The function could be written such that it takes name–value arguments with sensible default values as input with an arguments block, as can be seen here: https://github.com/SeSodesa/zeffiro_interface/blob/inversion-scripts-galore/%2Bgoodness_of_inversion/mne.m#L37. Another option is that the dipole scan routine could be implemented as a method of a DipoleScanInverter class, and class property validation could then take care of the validity of the state of the inverter object.

Both of these approaches also allow for better documentation, since with a function you could call

>> help dipole_scan

to get the documentation on the command line, or if a class was used, you could even query for the documentation of individual properties at a time with

>> help DipoleScanInverter.signal_to_noise_ratio

assuming of course that they all had their documentation comments in place.

[SeSodesa]

Also, those calls to eval should really not be there, as they add the performance penalty of running the string provided to them through the Matlab interpreter. An invocation of eval does not magically conjure zef into existence, if it does not already exist in the function symbol table or workspace, by the time those lines are reached. Calls to eval in this context are then only harmful.

The only reason eval exists in Matlab, Python, Julia and other languages that provide a REPL (Read Eval Print Loop) or an interactive command line, is because Matlab itself needs the function to interpret the strings the user inputs on the command line. It should really not be used in any other contexts, and is only available to Matlab users because Matlab can't really hide the functions it knows about from said users.

We should probably create an issue and a corresponding branch for removing all evals from the code.

[SeSodesa]

As for saving values into zef, the code must call the Dipole Scan function somewhere, so if the necessary values are returned by the function, the caller of the function can then take the responsibility of doing the saving. It should really not be the responsibility of the function that forms the resolution matrix / reconstruction to save things into zef.

A well written function that follows the principle of separation of concerns has a single well-defined job, and should not be doing a million or even two things at once.

[SeSodesa]

Unless those 2 things the function does are directly related to each other, of course, like building the resolution matrix and the reconstruction are. Computing results and saving the results to a separate data structure or disk are two orthogonal things.

[JoonasJL]

I full heartedly agree. Because there is so many pre-process done before you can give the crucial objects to the main thing that should be the inverse solver itself, and because of these processes, we need post-processes too. In this case it would be ideal to ZI to read the app and scripts that is about to be installed to ZI, and it forms tailored script environment around the inverter. Some conventions maybe needed for inverse script, but this is totally doable in my opinion. In BrainStorm, when you want to create a new inverse solver, it spits a template to you, where is the given slot to the inverter, but I don't think there should be need for tool maker to study the template and learn all the variables needed.

But this is way ahead the current state we are now.