mfocko/blog
1
0
Fork 0
mirror of https://github.com/mfocko/blog.git synced 2024-09-20 02:16:56 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

blog(aoc-2022): fix typos

Browse source 
Signed-off-by: Matej Focko <me@mfocko.xyz>
This commit is contained in:
Matej Focko 2023-01-01 22:42:05 +01:00
parent 5e93a6bf94
commit 933dcc83ac
Signed by: mfocko
GPG key ID: 7C47D46246790496
2 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
blog/aoc-2022/01-week-1.md
View file

@ -227,7 +227,7 @@ It may seem as a very weird decision, but in fact it makes some sense… It allo
you to do intersection of items that may not be possible to copy. Overall this is
a „tax“ for having a borrow checker ~~drilling your ass~~ having your back and
making sure you're not doing something naughty that may cause an **undefined**
**behaviour**.
**behavior**.
:::
@ -328,7 +328,7 @@ A lot of different approaches, knowing that we are dealing with input consisting
solely of ASCII letters, I bit the bullet and went with sliding window and
constructing sets from that window, checking if the set is as big as the window.
One possible optimization could consist of keeping a bitvector (i.e. `usize`
One possible optimization could consist of keeping a bit-vector (i.e. `usize`
variable) of encountered characters and updating it as we go. However this has
a different issue and that is removal of the characters from the left side of the
window. We don't know if the same character is not included later on.
@ -401,7 +401,7 @@ Then I looked up some implementations of trees or linked lists and decided to tr
`Box<T>` represents a dynamically allocated memory on heap. It is a single pointer,
you can imagine this as `std::unique_ptr<T>` in C++.
`Rc<T>` represents a dynamically allocated mmemory on heap. On top of that it is
`Rc<T>` represents a dynamically allocated memory on heap. On top of that it is
_reference counted_ (that's what the `Rc` stands for). You can imagine this as
`std::shared_ptr<T>` in C++.

8
blog/aoc-2022/02-week-2.md
View file

@ -93,7 +93,7 @@ them both to `usize` type that can be used later on for indexing.
The type signature of the function is where the fun is at :wink: We are trying
to convert unknown type to `usize`, so we must bound the `T` as a type that can
be converted to `usize`, that's how we got `usize: TryFrom<T>` which basically
says that `usize` must implement `TryFrom<T>` trait vand therefore allows us to
says that `usize` must implement `TryFrom<T>` trait and therefore allows us to
convert the indices to actual `usize` indices. Using `.unwrap()` also forces us
to bound the error that can occur when converting `T` into `usize`, that's how
we get `<usize as TryFrom<T>>::Error: Debug` which loosely means
@ -107,7 +107,7 @@ And now we are left only with the first line of the definition.
:::note
Skilled Rustaceans might notice that this implemention is rather flaky and can
Skilled Rustaceans might notice that this implementation is rather flaky and can
break in multiple places at once. I'll get back to it…
:::
@ -358,7 +358,7 @@ where
```
This is all part of the `Solution` trait, which can implement methods while being
dependant on what is provided by the implementing types. In this case, we just
dependent on what is provided by the implementing types. In this case, we just
need to bound the `Output` type to implement `Display` that is necessary for the
`info!` and format string there.
@ -589,7 +589,7 @@ also rolling down the hill…
As I have said in the _tl;dr_, we are looking for the shortest path, but the start
and goal differ for the part 1 and 2. So I have decided to refactor my solution
to a BFS algorithm that takes neccessary parameters via functions:
to a BFS algorithm that takes necessary parameters via functions:
```rust
fn bfs<F, G>(
graph: &[Vec<char>], start: &Position, has_edge: F, is_target: G