Change postprocessing structs subtyping

[jademackay]

Change post-processing structs EqOddsWrapper and LinProgWrapper (back?) to subtype Deterministic rather than DeterministicComposite. Changes enable the content of https://nextjournal.com/ashryaagr/fairness to be run.

Thanks for creating this package!

[ashryaagr]

Thanks a lot for the Pull Request. MLJ Docs (https://alan-turing-institute.github.io/MLJ.jl/dev/composing_models/#Method-II:-Finer-control-(advanced)-1) uses DeterministicComposite for creating composite wrappers and that's why all Fairness algorithms are subtypes of DeterministicComposite. The notebook https://nextjournal.com/ashryaagr/fairness ran perfectly with DeterministicComposite. So, could you please explain what exactly is the need for change of DeterministicComposite to Deterministic

[jademackay]

How curious. I think that the most notable difference between the Deterministic and and DeterministicComposite types is seen in the implementation of fit and predict - in particular, the form of the return value:

• Deterministic: return fitresult, cache, report - as you have done (return fitresult, nothing, nothing) for your postprocessing algorithms (eqodds.jl and linprog.jl) c.f. https://alan-turing-institute.github.io/MLJ.jl/dev/quick_start_guide_to_adding_models/#Fit-1
• DeterministicComposite: return!(mach, composite, verbosity) as you have done for preprocessing algorithms (reweighing.jl) c.f. https://alan-turing-institute.github.io/MLJ.jl/dev/composing_models/#A-composite-model-coupling-component-model-hyper-parameters-1

Could it be that you changed the implementation of fit/predict rather than the model type as I suggested initially?

[ashryaagr]

Ok. This makes sense to me. I somehow didn't know the difference in the usage of both.

I am merging this Pull Request.

Thanks a lot!!