{"id":1005,"date":"2023-04-04T05:38:13","date_gmt":"2023-04-04T09:38:13","guid":{"rendered":"https:\/\/blogs.mathworks.com\/matlab\/?p=1005"},"modified":"2023-04-04T15:08:49","modified_gmt":"2023-04-04T19:08:49","slug":"the-new-combinations-function-in-matlab-for-cartesian-products-and-parameter-sweeps","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/matlab\/2023\/04\/04\/the-new-combinations-function-in-matlab-for-cartesian-products-and-parameter-sweeps\/","title":{"rendered":"The new combinations function in MATLAB – for cartesian products and parameter sweeps"},"content":{"rendered":"
I've always been a <\/span>release notes<\/span><\/a> nerd as I think that you can learn a lot from the raft of enhancements that come with every new release of software like MATLAB. Even before I worked here, when a new version of MATLAB dropped I would spend ages picking through the release notes looking for anything that might be useful or just straight-up interesting.<\/span><\/div>
I like to think about the stories behind each feature. Why did the developers choose to work on this thing and why now? What problems does it solve? Why is it designed as it is? Why are there obvious limitations...didn't the developers notice these? How might I use it? <\/span><\/div>
This brings me to the new <\/span>combinations<\/span><\/a> function in R2023a which, when I looked at the release notes, I didn't really understand the point of since I could think of a bunch of other ways to achieve what it did. I reached out to the head of the development team who built <\/span>combinations<\/span> and asked for the story. Here's what I learned.<\/span><\/div>

What does combinations do?<\/span><\/h3>
The doc tells us that combinations will <\/span>\"Generate all element combinations of arrays\".<\/span> The output is <\/span>always<\/span> a table. A couple of examples speaks better than 1000 words:<\/span><\/div>
T = combinations([1 8 6],[9 3 2])<\/span><\/span><\/div>
T = <\/span>9\u00d72 table <\/span><\/div>
 <\/span><\/th>Var1<\/span><\/th>Var2<\/span><\/th><\/tr><\/thead>
1<\/span><\/th>1<\/span><\/td>9<\/span><\/td><\/tr>
2<\/span><\/th>1<\/span><\/td>3<\/span><\/td><\/tr>
3<\/span><\/th>1<\/span><\/td>2<\/span><\/td><\/tr>
4<\/span><\/th>8<\/span><\/td>9<\/span><\/td><\/tr>
5<\/span><\/th>8<\/span><\/td>3<\/span><\/td><\/tr>
6<\/span><\/th>8<\/span><\/td>2<\/span><\/td><\/tr>
7<\/span><\/th>6<\/span><\/td>9<\/span><\/td><\/tr>
8<\/span><\/th>6<\/span><\/td>3<\/span><\/td><\/tr>
9<\/span><\/th>6<\/span><\/td>2<\/span><\/td><\/tr><\/tbody><\/table><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
Every row is a combination with the first element coming from the first vector and the second element from the second vector. <\/span><\/div>
The <\/span>combinations<\/span> function can take as many input arguments as you want and you can mix data types. The fact that you can mix data types is why the output is always a table since tables allow the input datatypes to be conserved.<\/span><\/div>
experimentID = [1 2 3];<\/span><\/span><\/div><\/div>
method = [<\/span>\"kmeans\" \"dbscan\" \"kmedoids\"<\/span>];<\/span><\/span><\/div><\/div>
date = categorical([<\/span>\"small\" \"large\"<\/span>]);<\/span><\/span><\/div><\/div>
 <\/div><\/div>
T = combinations(experimentID,method,date)<\/span><\/span><\/div>
T = <\/span>18\u00d73 table <\/span><\/div>
 <\/span><\/th>experimentID<\/span><\/th>method<\/span><\/th>date<\/span><\/th><\/tr><\/thead>
1<\/span><\/th>1<\/span><\/td>\"kmeans\"<\/span><\/td>small<\/span><\/td><\/tr>
2<\/span><\/th>1<\/span><\/td>\"kmeans\"<\/span><\/td>large<\/span><\/td><\/tr>
3<\/span><\/th>1<\/span><\/td>\"dbscan\"<\/span><\/td>small<\/span><\/td><\/tr>
4<\/span><\/th>1<\/span><\/td>\"dbscan\"<\/span><\/td>large<\/span><\/td><\/tr>
5<\/span><\/th>1<\/span><\/td>\"kmedoids\"<\/span><\/td>small<\/span><\/td><\/tr>
6<\/span><\/th>1<\/span><\/td>\"kmedoids\"<\/span><\/td>large<\/span><\/td><\/tr>
7<\/span><\/th>2<\/span><\/td>\"kmeans\"<\/span><\/td>small<\/span><\/td><\/tr>
8<\/span><\/th>2<\/span><\/td>\"kmeans\"<\/span><\/td>large<\/span><\/td><\/tr>
9<\/span><\/th>2<\/span><\/td>\"dbscan\"<\/span><\/td>small<\/span><\/td><\/tr>
10<\/span><\/th>2<\/span><\/td>\"dbscan\"<\/span><\/td>large<\/span><\/td><\/tr>
11<\/span><\/th>2<\/span><\/td>\"kmedoids\"<\/span><\/td>small<\/span><\/td><\/tr>
12<\/span><\/th>2<\/span><\/td>\"kmedoids\"<\/span><\/td>large<\/span><\/td><\/tr>
13<\/span><\/th>3<\/span><\/td>\"kmeans\"<\/span><\/td>small<\/span><\/td><\/tr>
14<\/span><\/th>3<\/span><\/td>\"kmeans\"<\/span><\/td>large<\/span><\/td><\/tr>
\u22ee<\/th><\/tr><\/tbody><\/table><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
That's pretty much it! There are some <\/span>additional details that are covered in the doc of course<\/span><\/a> but if you understand the two examples above, you've got the gist of it.<\/span><\/div>

What problem does combinations solve?<\/span><\/h3>
Element combinations are commonly used for parameter sweeps. For example, imagine I have 3 experiments with IDs 1,2 and 3. <\/span><\/div>
experimentID = [1 2 3];<\/span><\/span><\/div><\/div><\/div>
I'm going to cluster the data using one of three methods<\/span><\/div>
method = [<\/span>\"kmeans\" \"dbscan\" \"kmedoids\"<\/span>];<\/span><\/span><\/div><\/div><\/div>
I have data from these experiments conducted on different days <\/span><\/div>
date = datetime([<\/span>\"15-Oct-2013\"<\/span>,<\/span>\"20-Nov-2014\"<\/span>]);<\/span><\/span><\/div><\/div><\/div>
I can form all possible combinations of these input variables:<\/span><\/div>
T = combinations(experimentID,method,date)<\/span><\/span><\/div>
T = <\/span>18\u00d73 table <\/span><\/div>
 <\/span><\/th>experimentID<\/span><\/th>method<\/span><\/th>date<\/span><\/th><\/tr><\/thead>
1<\/span><\/th>1<\/span><\/td>\"kmeans\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
2<\/span><\/th>1<\/span><\/td>\"kmeans\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
3<\/span><\/th>1<\/span><\/td>\"dbscan\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
4<\/span><\/th>1<\/span><\/td>\"dbscan\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
5<\/span><\/th>1<\/span><\/td>\"kmedoids\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
6<\/span><\/th>1<\/span><\/td>\"kmedoids\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
7<\/span><\/th>2<\/span><\/td>\"kmeans\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
8<\/span><\/th>2<\/span><\/td>\"kmeans\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
9<\/span><\/th>2<\/span><\/td>\"dbscan\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
10<\/span><\/th>2<\/span><\/td>\"dbscan\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
11<\/span><\/th>2<\/span><\/td>\"kmedoids\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
12<\/span><\/th>2<\/span><\/td>\"kmedoids\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
13<\/span><\/th>3<\/span><\/td>\"kmeans\"<\/span><\/td>15-Oct-2013<\/span><\/td><\/tr>
14<\/span><\/th>3<\/span><\/td>\"kmeans\"<\/span><\/td>20-Nov-2014<\/span><\/td><\/tr>
\u22ee<\/th><\/tr><\/tbody><\/table><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
Once I have all of these combinations in a table, I can run my analysis function on all of them. One way to do this would be to use <\/span>rowfun<\/span><\/a> which uses the contents of each row of the input table as the arguments to my function. I have defined a trivial <\/span>myAnalysis<\/span> function at the end of this article to show how this would work.<\/span><\/div>
results = rowfun(@myAnalysis,T);<\/span><\/span><\/div>
Working on ID=1 dated Tuesday October 15 2013 wih method kmeans\r\nWorking on ID=1 dated Thursday November 20 2014 wih method kmeans\r\nWorking on ID=1 dated Tuesday October 15 2013 wih method dbscan\r\nWorking on ID=1 dated Thursday November 20 2014 wih method dbscan\r\nWorking on ID=1 dated Tuesday October 15 2013 wih method kmedoids\r\nWorking on ID=1 dated Thursday November 20 2014 wih method kmedoids\r\nWorking on ID=2 dated Tuesday October 15 2013 wih method kmeans\r\nWorking on ID=2 dated Thursday November 20 2014 wih method kmeans\r\nWorking on ID=2 dated Tuesday October 15 2013 wih method dbscan\r\nWorking on ID=2 dated Thursday November 20 2014 wih method dbscan\r\nWorking on ID=2 dated Tuesday October 15 2013 wih method kmedoids\r\nWorking on ID=2 dated Thursday November 20 2014 wih method kmedoids\r\nWorking on ID=3 dated Tuesday October 15 2013 wih method kmeans\r\nWorking on ID=3 dated Thursday November 20 2014 wih method kmeans\r\nWorking on ID=3 dated Tuesday October 15 2013 wih method dbscan\r\nWorking on ID=3 dated Thursday November 20 2014 wih method dbscan\r\nWorking on ID=3 dated Tuesday October 15 2013 wih method kmedoids\r\nWorking on ID=3 dated Thursday November 20 2014 wih method kmedoids<\/div><\/div><\/div><\/div><\/div>
Now that we've seen an example of the new workflows that <\/span>combinations<\/span> allows. I thought that it would be fun to explore some of the thinking behind its design.<\/span><\/div>

Older solutions #1 - combvec<\/span><\/h3>
Of course, people have been doing parameter sweeps for a long time and there are a range of solutions in common use. There are issues with all of these, however, that led to us deciding to create something new. <\/span><\/div>
One such function is <\/span>combvec<\/span><\/a> in the Deep Learning toolbox -- a function so old that it was in Deep Learning toolbox before Deep Learning was cool and we called it Neural Network Toolbox. <\/span><\/div>
a1 = [1 2 3; 4 5 6];<\/span><\/span><\/div><\/div>
a2 = [7 8;9 10];<\/span><\/span><\/div><\/div>
a4 = combvec(a1,a2)<\/span><\/span><\/div>
a4 = <\/span>4\u00d76<\/span><\/div><\/div>
1 2 3 1 2 3\r\n 4 5 6 4 5 6\r\n 7 7 7 8 8 8\r\n 9 9 9 10 10 10\r\n<\/div>
<\/div>
<\/div><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
Seems to do the job! I can have as many input vectors as I like and each combination is a column. One issue, however, is that this requires a license for Deep Learning Toolbox which is unhelpful for those who want to generate parameter sweeps for anything other than Deep Learning. We did consider simply moving <\/span>combvec<\/span> to core MATLAB but there are aspects of the design we'd do differently today; starting with the fact that we wouldn't call it <\/span>combvec<\/span> since it works with more than just vectors. <\/span>combvec<\/span> also doesn't support nonumeric data:<\/span><\/div>
v1 = [1 7 4];<\/span><\/span><\/div><\/div>
v2 = [9 42 8];<\/span><\/span><\/div><\/div>
v3 = [<\/span>\"a\" \"c\"<\/span>];<\/span><\/span><\/div><\/div>
v4 = combvec(v1,v2,v3)<\/span><\/span><\/div>
v4 = <\/span>3\u00d718<\/span><\/div><\/div>
1 7 4 1 7 4 1 7 4 1 7 4 1 7 4 1 7 4\r\n 9 9 9 42 42 42 8 8 8 9 9 9 42 42 42 8 8 8\r\n NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN\r\n<\/div>
<\/div>
<\/div><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
To bring this into core MATLAB in a way that would satisfy the user requirements we've been collecting would require quite a hefty redesign. This would break backwards compatibility and so we decided against it. This decision kicked off our thought processes though; we wanted to do something! If not move <\/span>combvec<\/span> into core MATLAB then what? Let's look around at other ways people solve the combinations problem.<\/span><\/div>

Older Solutions #2 - meshgrid, ndgrid and allcomb<\/span><\/h3>
Three other functions are frequently recommended on MATLAB Answers to solve this problem:<\/span> <\/span>meshgrid<\/span><\/a>,<\/span> <\/span>ndgrid<\/span><\/a> <\/span>and <\/span>allcomb<\/span><\/a>.<\/span> The first two are built into MATLAB while allcomb is a popular function on File Exchange. <\/span>allcomb <\/span>is a superb piece of work that has been downloaded almost 25,000 times. Several of the reviews asked why such a useful piece of functionality wasn't part of core MATLAB. Quite!<\/span><\/div>
All of these work just fine in certain circumstances. For example, consider these inputs<\/span><\/div>
v1 = [1 2];<\/span><\/span><\/div><\/div>
v2 = [3 4];<\/span><\/span><\/div><\/div><\/div>
I could use meshgrid like this<\/span><\/div>
[am, bm] = meshgrid(v1,v2);<\/span><\/span><\/div><\/div>
M2 = [am(:), bm(:)]<\/span><\/span><\/div>
M2 = <\/span>4\u00d72<\/span><\/div><\/div>
1 3\r\n 1 4\r\n 2 3\r\n 2 4\r\n<\/div>
<\/div>
<\/div><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
ndgird like this<\/span><\/div>
[an, bn] = ndgrid(v1,v2);<\/span><\/span><\/div><\/div>
M3 = [an(:), bn(:)]<\/span><\/span><\/div>
M3 = <\/span>4\u00d72<\/span><\/div><\/div>
1 3\r\n 2 3\r\n 1 4\r\n 2 4\r\n<\/div>
<\/div>
<\/div><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
Finally, the File exchange's allcomb gives us\t<\/span><\/div>
M1 = allcomb(v1,v2)<\/span><\/span><\/div>
M1 = <\/span>4\u00d72<\/span><\/div><\/div>
1 3\r\n 1 4\r\n 2 3\r\n 2 4\r\n<\/div>
<\/div>
<\/div><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
So far so good but if I add the following two vectors<\/span><\/div>
v3 = [<\/span>\"a\" \"c\"<\/span>];<\/span><\/span><\/div><\/div>
v4 = categorical(v3);<\/span><\/span><\/div><\/div><\/div>
The above solutions no longer work:<\/span><\/div>
[am, bm, cm, dm] = meshgrid(v1,v2, v3, v4);<\/span><\/span><\/div>
Error using meshgrid
Too many input arguments.<\/div>
<\/div><\/div><\/div><\/div><\/div><\/div>
[an, bn, cn, dn] = ndgrid(v1,v2,v3,v4);<\/span><\/span><\/div><\/div>
result = [an(:), bn(:), cn(:) dn(:)]<\/span><\/span><\/div>
Error using categorical\/horzcat
Unable to concatenate a double array and a categorical array.<\/div>
<\/div><\/div><\/div><\/div><\/div><\/div>
allcomb(v1,v2,v3,v4)<\/span><\/span><\/div>
Error using categorical\/cat
Unable to concatenate a double array and a categorical array.<\/div>

Error in allcomb (line 111)
A = reshape(cat(NC+1,A{:}), [], NC) ;<\/div><\/div><\/div><\/div><\/div><\/div>
The new <\/span>combinations<\/span> function works just fine though<\/span><\/div>
combinations(v1,v2,v3,v4)<\/span><\/span><\/div>
ans = <\/span>16\u00d74 table <\/span><\/div>
 <\/span><\/th>v1<\/span><\/th>v2<\/span><\/th>v3<\/span><\/th>v4<\/span><\/th><\/tr><\/thead>
1<\/span><\/th>1<\/span><\/td>3<\/span><\/td>\"a\"<\/span><\/td>a<\/span><\/td><\/tr>
2<\/span><\/th>1<\/span><\/td>3<\/span><\/td>\"a\"<\/span><\/td>c<\/span><\/td><\/tr>
3<\/span><\/th>1<\/span><\/td>3<\/span><\/td>\"c\"<\/span><\/td>a<\/span><\/td><\/tr>
4<\/span><\/th>1<\/span><\/td>3<\/span><\/td>\"c\"<\/span><\/td>c<\/span><\/td><\/tr>
5<\/span><\/th>1<\/span><\/td>4<\/span><\/td>\"a\"<\/span><\/td>a<\/span><\/td><\/tr>
6<\/span><\/th>1<\/span><\/td>4<\/span><\/td>\"a\"<\/span><\/td>c<\/span><\/td><\/tr>
7<\/span><\/th>1<\/span><\/td>4<\/span><\/td>\"c\"<\/span><\/td>a<\/span><\/td><\/tr>
8<\/span><\/th>1<\/span><\/td>4<\/span><\/td>\"c\"<\/span><\/td>c<\/span><\/td><\/tr>
9<\/span><\/th>2<\/span><\/td>3<\/span><\/td>\"a\"<\/span><\/td>a<\/span><\/td><\/tr>
10<\/span><\/th>2<\/span><\/td>3<\/span><\/td>\"a\"<\/span><\/td>c<\/span><\/td><\/tr>
11<\/span><\/th>2<\/span><\/td>3<\/span><\/td>\"c\"<\/span><\/td>a<\/span><\/td><\/tr>
12<\/span><\/th>2<\/span><\/td>3<\/span><\/td>\"c\"<\/span><\/td>c<\/span><\/td><\/tr>
13<\/span><\/th>2<\/span><\/td>4<\/span><\/td>\"a\"<\/span><\/td>a<\/span><\/td><\/tr>
14<\/span><\/th>2<\/span><\/td>4<\/span><\/td>\"a\"<\/span><\/td>c<\/span><\/td><\/tr>
\u22ee<\/th><\/tr><\/tbody><\/table><\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
So far so good but I have to confess to you that some aspects of this function triggered me in ways that I'll need to discuss with my therapist so I tortured development even further with my questions.<\/span><\/div>

Why is the output a table?<\/span><\/h3>
Returning the result as a table allows input datatypes to be preserved in the output since each column can hold a different datatype. We could have also chosen a cell but decided against it because we find that most users consider using cell arrays to be advanced manueuvers. Also, it was very strange to see a cell array as output when all of the inputs are double! Most people on the design team preferred tables<\/span><\/div>

Why not allow the user to change output format?<\/span><\/h3>
Although I appreciate the elegance of a table format, I can imagine times when I'd prefer my output to be something else. The most obvious being an array when all inputs are numeric or cell array if I'm the kind of person who prefers them to tables. Why not just allow something like the following?<\/span><\/div>
% A design option that we didn't go with<\/span><\/span><\/div>
C = combinations(v1,v2,<\/span>\"OutputFormat\"<\/span>,<\/span>\"array\"<\/span>);<\/span><\/span><\/div><\/div>
After accepting my $5 donation to the \"just\" Jar, development told me that they considered this idea but the problem lies with the ambiguity between inputs and name-value pairs. Given the pair <\/span>\"OuputFormat\",\"array\", the<\/span> question becomes <\/span>\"is that pair defining an option or two additional inputs\"<\/span>? We could do exact matching; that is if an input is \"<\/span>OutputFormat\"<\/span> then consider it an option switch but what if you want the input to be <\/span>\"OutputFormat\"<\/span>?<\/span><\/div>
Since R2021a, MATLAB has supported a different way of defining name-value arguments so we could have insisted that ONLY the new format be accepted. i.e.<\/span><\/div>
% A design option that we didn't go with<\/span><\/span><\/div>
C = combinations(v1,v2,OutputFormat=<\/span>\"array\"<\/span>);<\/span><\/span><\/div><\/div>
The issue here is that a huge number of our users have been using the traditional <\/span>\"name\",\"value\"<\/span> pairs for many years. At the moment, it doesn't matter which method you use in most functions. In those cases where it does matter, it will likely be only the old syntax that's supported because the developer hasn't gotten around to supporting the new method yet. Starting to introduce functions in core MATLAB that <\/span>only<\/span> support the newer <\/span>name=\"value\"<\/span> syntax might result in annoying more people than this solution satisfies. <\/span><\/div>
OK, someone countered, why not just pack the inputs in curly braces <\/span>{}<\/span> to avoid ambiguity? We could just do<\/span><\/div>
% A design option that we didn't go with<\/span><\/span><\/div>
C = combinations({v1,v2},OutputFormat=<\/span>\"array\"<\/span>);<\/span><\/span><\/div><\/div>
Another $5 in the 'just' jar. The reason we didn't go with this may be contentious. Personally, I like it! It solves the problem by removing ambiguity between inputs and options defined as name-value pairs. However, over the years MathWorks has learned that always forcing users to pack inputs in a cell array makes the function signature a little unusual, which can be confusing to our users. This consideration won out and the design was discarded.<\/span><\/div>
One more option: We could have introduced a required FORMAT argument. That is, the function call would have looked like this<\/span><\/div>
% A design option that we didn't go with<\/span><\/span><\/div>
C = combinations(FORMAT,v1,v2)<\/span><\/span><\/div><\/div>
for example<\/span><\/div>
% A design option that we didn't go with<\/span><\/span><\/div>
C = combinations(<\/span>\"cell\"<\/span>,v1,v2)<\/span><\/span><\/div><\/div>
The main issue with this is that users will always need to type the required argument. When most people end up using <\/span>\"table\"<\/span> there will be cries of \"Why didn't you make <\/span>\"table\"<\/span> the default\"? It's also not extensible, there could never be any additional options. Not many people liked it! <\/span><\/div>
Eventually, it was decided that we just won't provide the option to choose output type. Tables support the majority of the use cases we were targeting and utility functions exist to convert tables to other datatypes. <\/span><\/div>
If you have a workflow where this causes an issue for us, do let us know! <\/span><\/div>

Combinations and rowfun -- your new combination for parameter sweeps<\/span><\/h3>
I hope you enjoyed this peek behind the curtain...and it really is just a peek! I've attempted to summarise a huge amount of discussion here and I apologise to my <\/span>colleagues in development if I have misrepresented their thinking in any way. When all is said and done, I think we have a beautiful new way to support conducting parameter sweeps in MATLAB and I hope you enjoy it <\/span><\/div>
%Create arguments to sweep over<\/span><\/span><\/div><\/div>
experimentID = [1 2 3];<\/span><\/span><\/div><\/div>
method = [<\/span>\"kmeans\" \"dbscan\" \"kmedoids\"<\/span>];<\/span><\/span><\/div><\/div>
date = datetime([<\/span>\"15-Oct-2013\"<\/span>,<\/span>\"20-Nov-2014\"<\/span>]);<\/span><\/span><\/div><\/div>
 <\/div><\/div>
%Form all combinations of the arguments <\/span><\/span><\/div><\/div>
T = combinations(experimentID,method,date);<\/span><\/span><\/div><\/div>
 <\/div><\/div>
%Perform analysis using all arguments<\/span><\/span><\/div><\/div>
results = rowfun(@myAnalysis,T);<\/span><\/span><\/div><\/div><\/div>

Helper functions<\/span><\/h3>
function <\/span>result = myAnalysis(ID,method,date)<\/span><\/span><\/div><\/div>
date.Format =<\/span>\"eeee MMMM d yyyy\"<\/span>;<\/span><\/span><\/div><\/div>
fprintf(<\/span>\"Working on ID=%d dated %s wih method %s\\n\"<\/span>,ID,date,method);<\/span><\/span><\/div><\/div>
%% DO THE ANALYSIS HERE<\/span><\/span><\/div><\/div>
result = rand(); <\/span>%% A proxy for real work<\/span><\/span><\/div><\/div>
end<\/span><\/span><\/div><\/div><\/div>
<\/span><\/div>
<\/div>\r\n<\/div>