Leveling the playing field
Because of the wide range of backgrounds of your peers, you can only use the methods discussed in the book in Chapters 1 through 6 of the ISLR book. Any use of any other methods will automatically
disqualify
your submission.
You must use the example code provided in the classes and/or in the ISLR book.
Googling how to's is prohibited. All the information that you need is provided in the book, reading material and examples. Do not use other libraries than those indicated in the materials.
Feature extraction
All the available data may be used. However, you may not use the minor `flaw` in the data collection design: the order of activities was not randomized across participants, and so certain activities tend to occur after other activities.
You
may not
make an external data file that includes both the provided and new features and use that in your entire script
. All data merging should be done inside your R script.
Team effort
You work in teams of 2 or (at most) 3 members. Each team submits their work as a team. For this competition each team can enter 2 submissions. (You will be able to indicate which two submissions have to be used.)
There are
two deadlines
: One for the
first submission
and one for the
second submission
.
Both submissions will be graded
.
Take advantage of the first round of submissions to improve your teams position on the leaderboard. That is, learn from the other teams scripts and 'steal' their good ideas! (Make sure to give credit where credit is due!)
Submissions
How to submit
You have to submit your script in Kaggle via a kernel: Create a kernel and copy and paste your script and submit the script by clicking the
Commit
button. Your commit should finish without errors, and should write the predictions to a file. Files that are created by your script will be saved to the "output" folder from which you can select the file with predictions to submit. You can either use a Notebook kernel or a Script kernel.
You have to set your kernel to 'Public'. This can be done by going to your Notebooks > Your Work, click on the Notebook that contains your kernel, and click on the
🔒 Access
button to make the kernel public. (An open lock symbol 🔓 indicates your kernel is public. It takes some time before your kernel is listed in the Notebooks > Public section.)
Code requirements
Your script should be neat and follow a consistent layout and coding style (e.g., use the
[Tidyverse Style Guide]()
or the
[Google R Style Guide](https://google.github.io/styleguide/Rguide.html)
). Especially pay attention to
[syntax](https://style.tidyverse.org/syntax.html)
.
Scripts can always be broken down in sections that correspond to different conceptual steps. Indicate those with proper
[internal structure commenting](https://style.tidyverse.org/files.html#internal-structure)
.
Use
dplyr
with pipes (
%>%
) where possible (this generalizes much more easily to large data bases such as SQL data bases, makes it much easier to understand processing steps)
mark key steps in your pipes with an inline comment
use of `dplyr` is taken into account in the grade (you’re supposed to learn to work with it, even if you already know how to do it differently)
Presentation
Always explain feature extraction ideas
what (what features are you looking at)
why (what is the motivation/reasoning behind your choice of features? can be reasoning, can be derived from theory, can be derived from comparison of other peoples efforts in this area)
how (how do you compute the features in R)
creativity, originality and effort
model fitting, selection, and performance
present all the algorithms that your group tried out (including performance output),
how performance was measured
how you varied and optimized the flexibility of the algorithm (e.g., feature selections, adding interactions, non-linear transformations)
visualize performance differences within and between algorithms (by means of a chart or by means of a table; whichever makes performances most apparent)
Learning from your peers
learn from others
steal each other’s ideas (crediting the originator!), take each other’s advice
what your team learned from others from the first submission to the next is taken into account in the grading (don't forget to credit the originator)