carpentries-incubator / carpentries-incubator/machine-learning-neural-python

General feedback after teaching

Open
#21 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
7
Forks
10
PR merge metrics
No merged PRs in 30d

Description

We've run a workshop with this lesson yesterday at Newcastle University, and I thought it would be a good idea to leave some feedback from our experiences.

First of all, many thanks for all your hard work in the lesson, it is a great resource and it proved very popular with learners. It goes without saying but what follows is meant to be helpful feedback, rather than harsh criticism. With that in mind, here are some of the things that I've noticed:

- Timings should be more generous -- although the amount of code is relatively small and problem-free, we had lots of questions from the audience from the very start. On average, I think each chapter took about one hour, with the exception of the very first one for which 30 minutes was adequate;
- In general, more exercise suggestions would be useful, at least one per episode;
- Instructors might need a bit more support in the later episodes, in particular episode 4 about the reasons for implementing that particular model architecture (i.e., why those numbers of layers, why those kernel sizes, is this a starting point to be improved, borrowed from a popular model, completely original...)
- In general, places where models can be tweaked to improve (or simply alter) their performance could be signposted better -- that was a common question from learners;
- Although the term 'normalization' is used in episode 2 (under image pre-processing) and is generally used for this stage in ML, it was pointed out during the lesson that the actual operation being performed is 'standardization', so a note could be added about that distinction; some further explanation on why we downsample and normalise image data (and what effects they could have on model performance) could also be helpful for instructors;
- Reusing variable names should be avoided, particularly when transforming the structure or shape of the dataset. An eagle-eyed helper spotted a particularly problematic spot, when in episode 4 we add a new dimension to the dataset
```
dataset = dataset[..., np.newaxis]
labels = labels[..., np.newaxis]
```
If that cell needs to be re-run for any reason, the resulting dataset will get more and more dimensions, which might not be picked up until much later in the lesson (in our case, during model training)

Finally, a couple of specific problems/questions with code:
- link to data downloads a corrupted file (but you already know that #8 )
- In the data augmentation section: shouldn't the options for `ImageDataGenerator` have different values? I.e., having everything at zero will simply create duplicates of existing images, no?
- In the data augmentation section: shouldn't this `augmented_images = [val_generator[0][0][0] for i in range(batch_size)]` be `augmented_images = [val_generator[i][0][0] for i in range(batch_size)]` otherwise we plot 5 equal images.
- In the model architecture section there's a discrepancy between the comment explanation and the function used:
```
# Global max pooling reduces dimensions back to the input size
x = GlobalAveragePooling2D()(x)
```

That's it! Hope this is useful, and thanks again for your great work!

Contributor guide

Open the contributing guide

Research direction

Start by reviewing episodes 1–4, especially the exercise sections, image preprocessing, data augmentation, and model architecture examples described in the feedback. Compare the lesson text and displayed code with each requested correction, then verify that timings, exercises, instructor guidance, terminology, variable handling, augmentation examples, and pooling comments are consistently updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
documentation, machine-learning
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.