Combination of controls

[mgao6767]

Currently when making specifications, the specurve choose one from each choice group (e.g., a particular set of control variables, a particular fixed effects choice, a particulart stand error clustering method, etc.). This is intentional.

However, in some cases, we may be only interested in combining control variables within the "control variables" group. For example, we are running 64 regressions with one dependent and one independent variable, same fixed effects etc. If we have 7 sets of controls. One of these sets needs to stay always on, while for the other 6 sets, we want to have all combinations, resulting in 2^6=64 regressions. So technically, we just need 7 lines of controls with indicators and having them marked if the control sets are used. However, if we apply all 64 combinations the graph becomes too messy, such as shown below:

A temporary "fix" is to use the relativesize option to shrink the size of the upper panel. This may result a better looking figure but does not solve the issue. We still have 64 lines of labels for the control variables.

---

I don't yet have a good solution for this. Because the program was initially written for choosing one from each choice group, it's not generalizable to consider combinations within group. Adding to the difficulty is that we need more complicated configuration YAML file. For example, one possible solution is to have

Choices:
  Control Variables - Always:
    - Baseline: age grade collgrad wks_ue ttl_exp 
  Control Variables - Optional: # cause 2^n combinations, n is number of choices in the group
    - Union: union
    - Other: hours wks_work

But for compatibility, I need to evaluate its impact on the existing "Control Variables" group - where the normal choosing-one rule applies. Alternatively, I can allow for extra instructions in comments such as:

Choices:
  Control Variables:
    - Baseline: age grade collgrad wks_ue ttl_exp # @always
    - Union: union # @for_combination
    - Other: hours wks_work # @for_combination

This latter one may work better, but also will lead to significant refactoring of the existing code.

Unfortunately I don't have the time now to re-write the code. Re-introducing Python dependency may solve the problem quite easily, but I'll probably stay with pure Stata implementation. Let me think more on this issue and solutions.