Use one sampler in split DefaultAlgorithm pipelines

[jeremyliweishih]

Fixes #3076.

[codecov]

Codecov Report

Merging #3696 (0f4f20d) into main (0ac4dae) will increase coverage by 0.1%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##            main   #3696     +/-   ##
=======================================
+ Coverage   99.7%   99.7%   +0.1%     
=======================================
  Files        339     339             
  Lines      34431   34451     +20     
=======================================
+ Hits       34304   34324     +20     
  Misses       127     127             

Impacted Files	Coverage Δ
...valml/automl/automl_algorithm/default_algorithm.py	100.0% <100.0%> (ø)
evalml/pipelines/utils.py	99.5% <100.0%> (+0.1%)	⬆️
...valml/tests/automl_tests/test_default_algorithm.py	100.0% <100.0%> (ø)
evalml/tests/pipeline_tests/test_pipeline_utils.py	99.8% <100.0%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[eccabay]

I like this implementation - it's a smooth way of hooking up these sorts of components into the component graph. Slightly overengineered for the problem at hand, but will make our lives easier if/when we need to add more pre-estimator components in the future. Do you have any sort of plan for how we'll do that if that becomes the case? Since right now, we just have the one sampler and we set the input X and y knowing they'll be reset as the first_pre_estimator_component, but what would this look like with more components?
I don't think this is a blocking question, just something to keep in mind and maybe file an issue to track.

[jeremyliweishih]

this implementation should work with more components if pre_estimator_components is a a component graph that hooks all the pre_estimator_components together. For example I believe the impl still would work if we have:

{sampler.name: [sampler.name, "X", "y"], "StandardScaler": ["StandardScaler, "sampler.X", "Sampler.y"]}

[christopherbunn]

+1 for this implementation, I think this will be super useful in the future. I'm okay with merging it as-is, but we might want to consider updating the parameter names for prior_components and pre_estimator_components to be a bit more precise? Maybe something with a pre/post scheme like pre_pipeline_components/post_pipelines_components.

[jeremyliweishih]

will update @christopherbunn

[christopherbunn]

+1 for this implementation, I think this will be super useful in the future. I'm okay with merging it as-is, but we might want to consider updating the parameter names for prior_components and pre_estimator_components to be a bit more precise? Maybe something with a pre/post scheme like pre_pipeline_components/post_pipelines_components.

[chukarsten]

I think we just need some minor cleanups with respect to logic, but otherwise, good to go.

[chukarsten]

LGTM thanks man.