From 63fa8f937d33ea13a86f409f206a3a8e5bc811c0 Mon Sep 17 00:00:00 2001 From: BethanyG Date: Wed, 6 Nov 2024 15:12:12 -0800 Subject: [PATCH] Hopefully, the last typos of this round. --- concepts/bitwise-operators/about.md | 2 +- exercises/practice/bob/.approaches/introduction.md | 2 +- .../practice/nth-prime/.approaches/generator-fun/content.md | 6 ++++-- .../practice/roman-numerals/.approaches/introduction.md | 4 ++-- 4 files changed, 8 insertions(+), 6 deletions(-) diff --git a/concepts/bitwise-operators/about.md b/concepts/bitwise-operators/about.md index a4ddb509c1..a68e5378f1 100644 --- a/concepts/bitwise-operators/about.md +++ b/concepts/bitwise-operators/about.md @@ -117,7 +117,7 @@ This means that all bits are inverted and a number is _**interpreted as negative Positive numbers have an MSB of `0`. This representation has the advantage of only having one version of zero, so that the programmer doesn't have to manage `-0` and `+0`. -This way of representing negative and positive numbers adds a complication for Python: there are no finite-integer concepts like `int32` or `int64` internally in the core langauge. +This way of representing negative and positive numbers adds a complication for Python: there are no finite-integer concepts like `int32` or `int64` internally in the core language. In 'modern' Python, `int`s are of unlimited size (_limited only by hardware capacity_), and a negative or bit-inverted number has a (_theoretically_) infinite number of `1`'s to the left, just as a positive number has unlimited `0`'s. This makes it difficult to give a useful example of `bitwise not`: diff --git a/exercises/practice/bob/.approaches/introduction.md b/exercises/practice/bob/.approaches/introduction.md index 07d68d1a1e..b9a54b9f57 100644 --- a/exercises/practice/bob/.approaches/introduction.md +++ b/exercises/practice/bob/.approaches/introduction.md @@ -13,7 +13,7 @@ Regardless of the approach used, some things you could look out for include - Use the [`endswith`][endswith] method instead of checking the last character by index for `?`. -- Don't copy/paste the logic for determining a shout and for determing a question into determing a shouted question. +- Don't copy/paste the logic for determining a shout and for determining a question into determining a shouted question. Combine the two determinations instead of copying them. Not duplicating the code will keep the code [DRY][dry]. diff --git a/exercises/practice/nth-prime/.approaches/generator-fun/content.md b/exercises/practice/nth-prime/.approaches/generator-fun/content.md index 39290335a0..b7fc867ab7 100644 --- a/exercises/practice/nth-prime/.approaches/generator-fun/content.md +++ b/exercises/practice/nth-prime/.approaches/generator-fun/content.md @@ -19,11 +19,13 @@ Using a lambda expression, we `filter` out any numbers above two that are prime. Doesn't this result in an infinite loop? No - `filter` _also_ returns a generator object (which are [evaluated lazily][generator]), so while it's too will produce values infinitely if evaluated, it doesn't hang to program at the time of instantiation. -`itertools.islice` takes in a generator object and an end count, returning a generator object which _only evalutes until that end count_. +`itertools.islice` takes in a generator object and an end count, returning a generator object which _only evaluates until that end count_. The next line exhausts all the values in the generator except the end, and we finally return the last element. -We can utilize the `functools.cache` decorator for greater speeds at higher values of `number`, so we take it out. The added bonus is that a very long line of code is cleant up. +We can utilize the `functools.cache` decorator for greater speeds at higher values of `number`, so we take it out. +The added bonus is that a very long line of code is cleaned up. + ```python from itertools import islice, count diff --git a/exercises/practice/roman-numerals/.approaches/introduction.md b/exercises/practice/roman-numerals/.approaches/introduction.md index 35f73e3ace..49060c2029 100644 --- a/exercises/practice/roman-numerals/.approaches/introduction.md +++ b/exercises/practice/roman-numerals/.approaches/introduction.md @@ -186,11 +186,11 @@ As the textbooks say, further analysis of this approach is left as an exercise f ## Which approach to use? In production, it would make sense to use the `roman` package. -It is debugged and supports Roman-to-Arabic conversions in addtion to the Arabic-to-Roman approaches discussed here. +It is debugged and supports Roman-to-Arabic conversions in addition to the Arabic-to-Roman approaches discussed here. Most submissions, like the `roman` package implementation, use some variant of [`loop-over-romans`][loop-over-romans]. -Using a [2-D lookup table][table-lookup] takes a bit more initialization, but then everthing can be done in a list comprehension instead of nested loops. +Using a [2-D lookup table][table-lookup] takes a bit more initialization, but then everything can be done in a list comprehension instead of nested loops. Python is relatively unusual in supporting both tuples-of-tuples and relatively fast list comprehensions, so the approach seems a good fit for this language. No performance article is currently included for this exercise.