Solve model.cond with custom materializer

[grst]

Trying to solve #15 using a custom formulaic materializer.

• wait for Refactor API / Wilcox test #33
• Testcases:
  • ~ A
  • ~ A + B
  • ~ A * B
  • ~ A + C(A) + C(A, contr.treatment(base=x))
  • ~ 0 + A
  • ~ C(A, contr.treatment(base=x))
  • ~ C(A, contr.sum)
  • ~ A + continuous + np.log(continuous)
  • ~ A * C(B, contr.treatment(base='y'))

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 94.00000% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 70.66%. Comparing base (7610d50) to head (9d8add0).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   67.67%   70.66%   +2.98%     
==========================================
  Files          12       14       +2     
  Lines         495      559      +64     
==========================================
+ Hits          335      395      +60     
- Misses        160      164       +4     

Files	Coverage Δ
src/multi_condition_comparisions/_util/__init__.py	100.00% <100.00%> (ø)
src/multi_condition_comparisions/_util/checks.py	100.00% <ø> (ø)
...lti_condition_comparisions/methods/_statsmodels.py	100.00% <ø> (ø)
...rc/multi_condition_comparisions/_util/formulaic.py	98.38% <98.38%> (ø)
src/multi_condition_comparisions/methods/_edger.py	87.09% <75.00%> (-0.79%)	⬇️
.../multi_condition_comparisions/methods/_pydeseq2.py	93.33% <80.00%> (-1.79%)	⬇️
src/multi_condition_comparisions/methods/_base.py	86.00% <88.88%> (-2.00%)	⬇️

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[grst]

Finally made it! As usual with these things it was more complicated than I anticipated, but it seems to work quite robustly now.

High-level description:

• Formulaic uses a "Materializer" class that converts the model specification into a design matrix
• It is possible and supported to make a custom materializer that extends the base class provided by formulaic (intended to generate something different than a pandas data frame)
• I use a custom materializer to hook into the materializer functions to extract factor metadata that we later need for bulding contrast vectors with model.cond.
• model.cond uses this information to check categories and to fill in default values. There might be situations in which the default value can't be inferred, in that case we raise an error.

@const-ae, would be great if you could have a look, too. In particular, if the test cases are correct and if there's any additional (more complex?) model you think that should be tested.

[Zethson]

Thank you so much @grst! This is a loooooot of work (although I have the suspicion that you enjoyed it :) )

I went through the PR but quickly noticed that it's a bit over my head at the moment. I'd need more headspace to give this a review that would deserve the name "review". I might give this another pass later, but I'm sure that the other reviews will have more useful comments.

[ilan-gold]

I'm having trouble following exactly what is going on here or what is solved...I will need to look back. I've never done much with formulaic so still a little bit dazzled....

[ilan-gold]

Why do we need the class declaration inside of another class? This makes reasoning about what goes on a bit challenging

[grst]

Because each class needs to be tied to one specific factor_storage object. The class gets instantiated by formulaic, therefore we can only pass a class, rather than an instance.

Each class is used only for one formulaic formula and stores the formula-specific metadata in the factor_storage object that is tied to it.

[grst]

I can understand that it all looks a bit daunting. I suggest to start reading at def cond(), this is the actual user-facing function to generate contrast vectors. All the other fuzz is about finding the default categories of each categorical variable specified in the model.