Project Documentation¶
This site provides project documentation. Use the documentation navigation to explore.
How-To Guide¶
Many instructions are common to all our projects.
See ⭐ Workflow: Apply Example to get the example projects running on your machine.
Project Documentation Pages (docs/)¶
- Home - this documentation landing page
- Project Instructions - the standard project workflow
- Your Files - how to copy the example and create your version
- Glossary - project terms and concepts
- API - autogenerated code documentation for the public project interface
Phase 4. Technical Modification¶
For Phase 4, I modified my copy of the example regression app to train and compare three models instead of one, using test sizes of 0.2, 0.3, and 0.4. I changed the training and prediction functions so the test size is passed in each time, split the plotting into a data chart and a coefficient chart, and saved all four charts to docs/images so I could show them.
I chose this change because I wanted to see how the train/test split affects the results on a very small dataset, only 10 rows. I verified it by running the app and reading the logged mean absolute error and R-squared for each split, and by looking at the saved charts.
The results were the confirmation. The mean absolute error was 0.63 at test size 0.2, 0.48 at 0.3, and 1.30 at 0.4. So the error was lowest at 0.3 and jumped at 0.4, about a 171% increase over 0.3, where the model trained on only 6 rows. The R-squared barely moved (1.00, 1.00, 0.99), so it looked perfect every time, while the MAE was the number that actually showed the difference. The predicted score for one fixed student stayed similar across all three splits, 83.5, 83.4, and 84.1, even though the error and the coefficient charts moved. The coefficient chart for the 0.4 split looked very different from the others.
Compared with the example, which trained a single model at one test size, my version makes the effect of the split visible by putting three side by side. What matters is that on a dataset this small, changing the split does not smoothly improve or worsen the model, and a stable-looking R-squared can hide a real change that the MAE reveals.
I would rate this moderate to challenging. It was more than a one-line change, since I had to add parameters, restructure the plotting, and change how the script ran, and it took a fair amount of work to figure out.
Phase 5. Custom Project (OPTIONAL in Module 1)¶
Describe your custom project.
In Module 1, this includes choosing a dataset, identifying a target, and explaining what kind of ML problem it represents.
Basis and Data¶
I started from the example notebook, which characterized the Seaborn penguins dataset with species as the target. I kept the same characterization approach but changed to a different dataset to practice the skills on new data.
My dataset is diabetes.csv, a health survey with 70,692 instances and 22 columns. Each instance is one person, and the columns are health and lifestyle indicators such as high blood pressure, BMI, smoking, physical activity, and general health, along with whether the person has diabetes.
Data source: diabetes.csv was already included in the data/raw folder of the template repository provided by Dr. Case. I chose it because it was provided and I wanted to work with a known, reliable dataset while there was a lot to learn in the first week. Using a dataset I could trust let me focus on learning the workflow and the characterization skills rather than on finding and vetting new data.
One thing I noticed about the data is that every column is stored as a number, even though many are really categories, such as the yes/no health indicators, or ranked scales.
Modeling Approach¶
This is a supervised problem, because I chose a target, Diabetes_binary, the column for whether a person has diabetes. Supervised learning is when the data includes the target you want to predict, and here it does.
It should be a classification problem, because the target is a category, a yes or no, rather than a number to predict. But because the data is stored numerically as 1.0 and 0.0, the notebook's automatic check read the target as numeric and reported the problem type as regression. It flagged all 22 features as numeric for the same reason, even though several are really categories. So the automatic result was regression, but the true problem type is classification. The difference comes from how the data is stored versus what it actually represents.
Summary¶
For this custom project, I copied the example notebook, changed the dataset to diabetes.csv, and reframed the problem for a new target. I updated the load step to read a CSV from data/raw with pandas instead of loading a built-in Seaborn dataset, chose Diabetes_binary as the target, and let the notebook characterize the data and report the implied problem type.
The main result is that the notebook reported the problem as regression, even though the true problem type is classification. It also labeled all 22 features as numeric. Both happened because every column is stored as a number, so the automatic check could not tell a real number from a category recorded as 1.0 or 0.0.
I learned that characterizing a problem is not just running a check and trusting the output. The tool reported regression, but the analyst has to know that a yes/no target is really a classification problem regardless of how it is stored. The judgment sits with the person, not the code.
For a first attempt, and being new to coding, I feel I exercised the core skills of this project reasonably well: naming the instances, features, and target, deciding supervised versus unsupervised, and reasoning about classification versus regression. Applying them to a large, real-world health survey rather than a small clean example made the storage-versus-meaning issue show up clearly, in a way the penguins example would not have. I can also see there is more to learn, especially what comes after framing, once the goal is actually preparing and modeling the data.
These skills apply to many real problems where the first job is framing the question correctly before any modeling: deciding what you are trying to predict, whether the data even supports that question, and whether your data is formatted correctly to get meaningful results.
