Correcting documentation mistakes.

Author: CreatingNull

Diff for: src/day5/README.md

@@ -7,8 +7,8 @@ This package contains the source and data for [day 5](https://adventofcode.com/2
 
 ## Post-Task Thoughts
 
-Fun task, basically computation of Cartesian points.
-Because we are iterating through multiple vents trying to look for matching points, storing points in a dictionary makes a lot of sense as you can utilise the efficiency of hashed lookups.
+Fun task, basically just computation of Cartesian points.
+Because we are iterating through multiple vents trying to look for matching points, storing points in a dictionary made a lot of sense as you can utilise the efficiency of hashed lookups.
 It was easy to design for this task as it was clear in part 1 what the scope of the second part was going to be (diagonal lines), so I think everyone was able to prepare themselves for handling this case.
 
 One library I found particularly helpful for this task that I have previously not used extensively, was the [operator](https://docs.python.org/3/library/operator.html) lib.

Diff for: src/day6/README.md

@@ -8,11 +8,11 @@ This package contains the source and data for [day 5](https://adventofcode.com/2
 ## Post-Task Thoughts
 
 This was the easiest task to date, and also my highest leaderboard position so far this year.
-As soon as the task mentioned exponential growth, I knew I was going to haves to be careful with how I stored and computed data.
-Fortunately storing this in a python dictionary was a very simple solution to this issue mapping a `day countdown timer` integer key to a `sum of fish` value for that countdown.
+As soon as the task mentioned exponential growth, I knew I was going to have to be careful with how I stored and computed data.
+Fortunately storing this in a python dictionary was a very simple solution to this issue, mapping a `day countdown timer` integer key to a `sum of fish` value.
 This means the 'exponential' part of the data is simply captured in 9 integer values, which isn't particularly computationally intensive to operate on.
 
 I think the 'gotcha' in this task would be with languages that have static length integers, fortunately in python 3 you don't have to worry about this.
-CPython uses a 'bignum' arithmetic variant, where it's broken up into chunks and can essentially grow indefinitely (provided you don't overflow system memory).
-This scaling property barely ever comes in handy for me, but in this case it's lovely to not be using a language like java that use staic-length integers.
+CPython uses a variation on 'bignum' arithmetic, where integers are broken up into chunks and can essentially grow indefinitely (provided you don't overflow system memory).
+This scaling property barely ever comes in handy for me, but in particular problem it's lovely to not be using a language like java that use static-length integers.
 My final sum was `1,572,358,335,990` which needs about 41 bits (6 bytes in practical reality) which is several orders of magnitude above the 32-bit signed integer types many languages have by default.