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

16
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.
@ -341,7 +341,7 @@ of 26 elements that keeps count for each lowercase letter.
:::info tl;dr
Let's simulate [`du`] to get some stats about our filesystem and then pinpoint
Let's simulate [`du`] to get some stats about our file system and then pinpoint
directories that take a lot of space and should be deleted.
:::
@ -351,7 +351,7 @@ directories that take a lot of space and should be deleted.
### Solution
We need to „_build_“ a filesystem from the input that is given in a following form:
We need to „_build_“ a file system from the input that is given in a following form:
```
$ cd /
$ ls
@ -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++.
@ -419,7 +419,7 @@ to have `Rc<RefCell<T>>`.
:::
So, how are we going to represent the filesystem then? We will use an enumeration,
So, how are we going to represent the file system then? We will use an enumeration,
hehe, which is an algebraic data type that can store some stuff in itself :weary:
```rust
type FileHandle = Rc<RefCell<AocFile>>;
@ -443,7 +443,7 @@ Now to the fun part! `AocFile` value can be represented in two ways:
contain map matching the name of the files (or directories) within to their
respective file handles
I will omit the details about constructing this filesystem, cause there are a lot
I will omit the details about constructing this file system, cause there are a lot
of technicalities introduced by the nature of the input. However if you are
interested, you can have a look at my solution.
@ -466,7 +466,7 @@ solution.
One of the more exotic options would be precomputing the required information at
the same time as parsing. That could be done by adding additional fields to the
nodes which would allow storing such information and updating it as we construct
the filesystem.
the file system.
## Post Mortem

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