roj / recsys-comparison Goto Github PK

Implement or add to the code an option to search for parameters.

Possibilities are:

· Grid search
· Random tuning (works better when there are a large number (>2) of parameters).

This option should also produce a csv file that lists the metrics for each tried set of hyperparameters. There should be a .ipynb that analyses these results.

Use matplotlib so that each axis has its own scale.

Like MRR, for example.

Maybe it could just work with significant figures?

Currently, the crossfold and similar tasks change their behaviour based on the specified dataset.

Instead of having a method with different behaviour for each possible state, we should have different methods that do the task for a specific dataset (i.e. crossfoldML100k, crossfoldBookCrossing, etc.)

Basically, title.

It's easier to see results and to re-run them.

Note: this also implies that there should be a results folders with only the .csv that lists the metrics' values for each algorithm (one dataset per file).

If it is the same as PersMean then we don't need both!

Before we run the batch, we need to test every dataset.

RMSE generally gives NaNs for FunkSVD on some datasets (lastfm, for example). The CSV that evaluate generates doesn't include this metric (it skips it), but I don't know why.

Move the maxMemory and threadcount properties to a gradle.properties file. It's cleaner that way.

Try and do the same with jsse.enableSNIExtension setting.

However, don't commit gradle.properties files.

Check if this plot is right or if we have to invert it.

This is specifically for branch hyperparameters.

The goal is to have a process for analyze that does all the process and having also analyze from our versionated data results.

Same thing as issue #2 but for fetchdata. It's OK to assume that the user has already downloaded the files (i.e. don't download them unless absolutely necessary).

It's also better as gradle --tasks is more informative (with these changes) than just "downloads the dataset".

There's a trick you can do to reduce some of the code duplication, specifically the 'buildscript' blocks at the header of every gradle file. If you create a 'buildSrc' directory, that will be used for a 'local gradle plugin'; if you put in that directory a 'build.gradle' file that has the 'repository' and 'dependencies' lines necessary to use the LensKit Gradle plugin (as top-level blocks, just like a normal Gradle project, not within 'buildscript'), then it will be available through the whole project without needing to duplicate that code.

Transformation of the dataset is not needed, it's better for the errors to reflect the true nature of the data. So, for example, do not normalize Jester from [-10,10] to [1,5].