Push functionality from experiment subclasses #400
Assignees
Comments
thcrock
added a commit
that referenced
this issue
May 1, 2018
The execution-oriented experiment subclasses (SingleThreadedExperiment, MultiCoreExperiment) duplicate a lot of functionality in a way that means they can get out of sync if developers are not careful enough. This also harms readability: if you are looking for code relating to the experiment algorithm (anything that has to do with data science), none of that information should be in the experiment subclasses, but right now it is. The ExperimentBase (and the components it delegates to) should have all of that code. To make this easier, there are two things introduced: 1. The ModelTester component, which encapsulates prediction, individual importance, and evaluation for a single train/test split. It uses a similar pattern to the ModelTrainer of generating and processing tasks only serializable arguments. This is important because a lot of the extra code in those experiment subclasses was related to model testing. 2. The SerializableDbEngine. One of the worst foes for readability in the ExperimentBase and subclasses was the component 'factory' methods that were introduced as a workaround for database engines not being serializable across process boundaries. Now, all components which use a database engine use a SerializableDbEngine that upon serialization (via `__setstate__`) removes the engine but saves the url, so that it may be reinstantiated later. This removes a lot of extra code from the ExperimentBase and subclasses, allowing instance methods on components (e.g. `self.model_trainer.process_train_task`) to be used as task functions that can be sent to different execution contexts. The result is that subclasses need only implement four methods: `process_query_tasks`, `process_matrix_build_tasks`, `process_train_tasks`, and `process_model_test_tasks`. These generally involve passing through task arguments to the correct component (as opposed to caring what the task arguments are), which should leave the subclasses uninteresting to readers unless they actually want to mess with execution context. To test out this refactoring's usefulness, there is a third subclass introduced: The RQExperiment (available through the package extra 'rq', e.g. `pip install triage[rq]`), which simply enqueues each task onto an RQ Queue and waits for the group of tasks to be finished before moving on.
thcrock
added a commit
that referenced
this issue
May 15, 2018
Refactor functionality to ExperimentBase class [Resolves #400]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is much duplicated code in the SingleThreadedExperiment and MultiCoreExperiment, because they are responsible for too much. The only code in the subclasses should be related to experiment execution, not experiment logic. The ExperimentBase should at the very least take responsibility for this. Ideally it should delegate as much functionality as possible to another component, but most problematic is the fact that the subclasses themselves are implementing much of it.
The text was updated successfully, but these errors were encountered: