Improvement: improve code structure to make it easier to change between models we are using

[KarinePistili]

Right now we only have the linear regression model integrated. We would like to have an architecture that facilitate us to changing between this method to other implementations made by the future contributors.

[sitamgithub-MSIT]

@KarinePistili I would like to work on this issue. Can you assign it to me?

[sitamgithub-MSIT]

What I can understand from your issue is that if we have some kind of switching system inside our codebase, users can easily switch between the models for the regression task.

cc: @KarinePistili

[KarinePistili]

hello @sitamgithub-MSIT , assigned!

[KarinePistili]

About your question:

Yes, exactly. We want an easy way to developers to change between the models. It would be important as well, to document how to make the change so it is easy for the users that would like to switch the models for their tests.

We are open to your suggestions on how to implement this, so share with us when you have an idea.

[sitamgithub-MSIT]

About your question:

Yes, exactly. We want an easy way to developers to change between the models. It would be important as well, to document how to make the change so it is easy for the users that would like to switch the models for their tests.

We are open to your suggestions on how to implement this, so share with us when you have an idea.

Upon initial inspection, I have been considering the idea of maintaining a model configuration file. The objective is to allow for the running of our gaze_tracker.py file for a specific model simply by modifying the model configuration file.

The configuration file should contain the models and their corresponding hyperparameters, as well as a training flag, which is essentially a boolean field. If set to true, training will be performed for the selected model; otherwise, it will not.

[sitamgithub-MSIT]

This is the initial idea that I had. Although I will try to find another way to figure it out.

[KarinePistili]

I think it could work. @hvini what do you think about this?

[sitamgithub-MSIT]

I looked into the backend codebase a little bit. I started by looking at the main.py file, which contains a reference to session.py from the app routes. Furthermore, we can see that the gaze_tracker.py file is actually being used if we go back and use the session.py file. Ultimately, the pre-processing steps and models we use are contained in this gaze_tracker.py file.

As of right now, the gaze_tracker.py file appears to be the only functional file for this issue. And as I mentioned earlier, we can control the models used in the gaze_tracker.py file by using an .yaml file. Correct me if I am wrong, but this is my basic understanding.

cc: @KarinePistili @hvini

[sitamgithub-MSIT]

One more thing I would like you to clarify for me is that, although the gaze_tracker.py file contains a number of methods, we are only using the predict method. Please let me know if it is untrue.

As seen below, there are two more comparable situations in the predict method where we initialize our models:

model = make_pipeline(PolynomialFeatures(2), linear_model.LinearRegression())
model.fit(X_train_x, y_train_x)
y_pred_x = model.predict(X_test_x)
===================================================
model = make_pipeline(PolynomialFeatures(2), linear_model.LinearRegression())
model.fit(X_train_y, y_train_y)
y_pred_y = model.predict(X_test_y)

What I am interested in knowing right now is whether there is a slim possibility that we will use two distinct models for the x and y coordinates. If not, repetitive code can be removed.

[sitamgithub-MSIT]

I think it could work. @hvini what do you think about this?

This is possibly how the .yaml file looks. Though subject to change during implementation based on project requirements and workability.

model_type: linear_regression
hyperparameters:
  degree: 2
  alpha: 0.1

And our model code part can look like this:

# Select model based on model_type
if model_type == 'linear_regression':
        model = make_pipeline(StandardScaler(), PolynomialFeatures(config['hyperparameters']['degree']), 
                              linear_model.Ridge(alpha=config['hyperparameters']['alpha']))
else:
        raise ValueError("Invalid model type")

Nevertheless, I have not tested it yet. To me, the frontend codebase and configuration remain unexplored. It could take some time to set up and configure Firebase. However, in my opinion, we can test it eventually without actually setting anything up. For the purpose of testing whether it works or not, even an YAML file, the gaze_tracker file, and an artificially generated dataset similar to actual data will do!