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 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 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** 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 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. 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 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 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. 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, `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++. 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 _reference counted_ (that's what the `Rc` stands for). You can imagine this as
`std::shared_ptr<T>` in C++. `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 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 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 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 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 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 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 :::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… 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 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 need to bound the `Output` type to implement `Display` that is necessary for the
`info!` and format string there. `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 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 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 ```rust
fn bfs<F, G>( fn bfs<F, G>(
graph: &[Vec<char>], start: &Position, has_edge: F, is_target: G graph: &[Vec<char>], start: &Position, has_edge: F, is_target: G