mirror of
https://github.com/mfocko/blog.git
synced 2024-12-26 22:31:30 +01:00
fix: use appropriate quotes in English
Signed-off-by: Matej Focko <mfocko@redhat.com>
This commit is contained in:
parent
277213ce23
commit
4ce489459d
10 changed files with 33 additions and 33 deletions
|
@ -30,10 +30,10 @@ Though I prefer to use only one language.
|
|||
For this year I have been deciding between _Rust_, _C++_ and _Pascal_ or _Ada_.
|
||||
|
||||
I have tried Rust last year and have survived with it for 3 days and then gave
|
||||
up and switched to _Kotlin_, which was pretty good given it is „Java undercover“.
|
||||
up and switched to _Kotlin_, which was pretty good given it is “Java undercover”.
|
||||
I pretty much like the ideas behind Rust, I am not sure about the whole cult and
|
||||
implementation of those ideas though. After some years with C/C++, I would say
|
||||
that Rust feels _too safe_ for my taste and tries to „_punish me_“ even for the
|
||||
that Rust feels _too safe_ for my taste and tries to “_punish me_” even for the
|
||||
most trivial things.
|
||||
|
||||
C++ is a very robust, but also comes with a wide variety of options providing you
|
||||
|
@ -67,7 +67,7 @@ export RUST_LOG=trace
|
|||
```
|
||||
|
||||
And for the one of the most obnoxious things ever, we will use a script to download
|
||||
the inputs instead of „_clicking, opening and copying to a file_“[^1]. There is
|
||||
the inputs instead of “_clicking, opening and copying to a file_”[^1]. There is
|
||||
no need to be _fancy_, so we will adjust Python script by Martin[^2].
|
||||
```py
|
||||
#!/usr/bin/env python3
|
||||
|
@ -124,7 +124,7 @@ year: 2022
|
|||
|
||||
### Libraries
|
||||
|
||||
Looking at the list of the libraries, I have chosen „a lot“ of them. Let's walk
|
||||
Looking at the list of the libraries, I have chosen “a lot” of them. Let's walk
|
||||
through each of them.
|
||||
|
||||
[`tracing`] and [`tracing-subscriber`] are the crates that can be used for tracing
|
||||
|
@ -150,11 +150,11 @@ during runtime.
|
|||
|
||||
[`itertools`] provides some nice extensions to the iterators from the `std`.
|
||||
|
||||
### My own „library“
|
||||
### My own “library”
|
||||
|
||||
When creating the crate for this year's Advent of Code, I have chosen a library
|
||||
type. Even though standard library is huge, some things might not be included and
|
||||
also we can follow _KISS_. I have 2 modules that my „library“ exports, one for
|
||||
also we can follow _KISS_. I have 2 modules that my “library” exports, one for
|
||||
parsing and one for 2D vector (that gets used quite often during Advent of Code).
|
||||
|
||||
Key part is, of course, processing the input and my library exports following
|
||||
|
@ -232,7 +232,7 @@ fn parse_input(path: &str) -> Input {
|
|||
}
|
||||
```
|
||||
|
||||
This „parser“ will take a path to the file, just in case we would like to run the
|
||||
This “parser” will take a path to the file, just in case we would like to run the
|
||||
sample instead of input.
|
||||
|
||||
OK, so now we can write a `main` function that will take all of the pieces and
|
||||
|
|
|
@ -221,7 +221,7 @@ the third set, it has just the values themselves, without any references.
|
|||
|
||||
It may seem as a very weird decision, but in fact it makes some sense… It allows
|
||||
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**
|
||||
**behavior**.
|
||||
|
||||
|
@ -347,7 +347,7 @@ directories that take a lot of space and should be deleted.
|
|||
|
||||
### Solution
|
||||
|
||||
We need to „_build_“ a file system 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
|
||||
|
@ -377,7 +377,7 @@ $ ls
|
|||
There are few ways in which you can achieve this and also you can assume some
|
||||
preconditions, but why would we do that, right? :)
|
||||
|
||||
You can „slap“ this in either [`HashMap`] or [`BTreeMap`] and call it a day.
|
||||
You can “slap” this in either [`HashMap`] or [`BTreeMap`] and call it a day.
|
||||
And that would be boring…
|
||||
|
||||
:::tip
|
||||
|
@ -478,8 +478,8 @@ dynamically allocated memory. Specifically:
|
|||
`Rc<RefCell<T>>`
|
||||
|
||||
Now, in Rust it is a bit more complicated, because the type that represents the
|
||||
„shared pointer“ is `Rc<T>`. What `RefCell<T>` does is making sure that there is
|
||||
only one „owner“ of a mutable reference at a time (and dynamically, as opposed
|
||||
“shared pointer” is `Rc<T>`. What `RefCell<T>` does is making sure that there is
|
||||
only one “owner” of a mutable reference at a time (and dynamically, as opposed
|
||||
to the `Cell<T>`).
|
||||
|
||||
Therefore to be precise and correct about the equivalents of `std::shared_ptr<T>`
|
||||
|
|
|
@ -36,10 +36,10 @@ way:
|
|||
|
||||
:::caution
|
||||
|
||||
I'm getting familiar with Rust and starting to „abuse“ it… While doing so, I'm
|
||||
also uncovering some „features“ that I don't really like. Therefore I will mark
|
||||
all of my rants with _thicc_ **«↯»** mark and will try to „lock“ them into their
|
||||
own „box of hell“.
|
||||
I'm getting familiar with Rust and starting to “abuse” it… While doing so, I'm
|
||||
also uncovering some “features” that I don't really like. Therefore I will mark
|
||||
all of my rants with _thicc_ **«↯»** mark and will try to “lock” them into their
|
||||
own “box of hell”.
|
||||
|
||||
:::
|
||||
|
||||
|
@ -121,7 +121,7 @@ Let's split it in multiple parts:
|
|||
borrow checker validates all of the _borrows_ (or references), so we need to
|
||||
specify that our returned value has _the same lifetime_ as the vector we have
|
||||
taken by a reference, i.e. returned reference must live at least as long as the
|
||||
`v`. This way we can „be sure“ that the returned reference is valid.
|
||||
`v`. This way we can “be sure” that the returned reference is valid.
|
||||
|
||||
##### Issues
|
||||
|
||||
|
@ -149,7 +149,7 @@ behind syntactic sugar of `container[idx]`.
|
|||
However, implementing of traits is not allowed for _external_ types, i.e. types
|
||||
that you haven't defined yourself. This means that you can implement indexing
|
||||
over containers that you have implemented yourself, but you cannot use your own
|
||||
types for indexing „built-in“ types.
|
||||
types for indexing “built-in” types.
|
||||
|
||||
Another part of this rabbit hole is trait `SliceIndex<T>` that is of a relevance
|
||||
because of
|
||||
|
@ -294,7 +294,7 @@ visited with the rope's tail.
|
|||
|
||||
By this day, I have come to a conclusion that current skeleton for each day
|
||||
generates a lot of boilerplate. And even though it can be easily copied, it's
|
||||
just a waste of space and unnecessary code. Let's „simplify“ this (on one end
|
||||
just a waste of space and unnecessary code. Let's “simplify” this (on one end
|
||||
while creating monster on the other end). I've gone through what we need in the
|
||||
preparations for the AoC. Let's sum up our requirements:
|
||||
- parsing
|
||||
|
@ -415,8 +415,8 @@ macro_rules! test_sample {
|
|||
```
|
||||
|
||||
We have used it in a similar way as macros in C/C++, one of the things that we
|
||||
can use to our advantage is defining „type“ of the parameters for the macro. All
|
||||
parameters have their name prefixed with `$` sign and you can define various „forms“
|
||||
can use to our advantage is defining “type” of the parameters for the macro. All
|
||||
parameters have their name prefixed with `$` sign and you can define various “forms”
|
||||
of your macro. Let's go through it!
|
||||
|
||||
We have following parameters:
|
||||
|
@ -821,7 +821,7 @@ which I haven't managed to be able to parse. And that's how I got rid of the err
|
|||
:::note
|
||||
|
||||
If I were to use 2D-indexing over `[C; N]` slices, I'd probably just go with the
|
||||
copy-paste, cause the cost of this „monstrosity“ outweighs the benefits of no DRY.
|
||||
copy-paste, cause the cost of this “monstrosity” outweighs the benefits of no DRY.
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
@ -201,7 +201,7 @@ cubes.
|
|||
|
||||
This day is kinda interesting, because it shows how easily you can complicate the
|
||||
problem and also how much can you screw yourself over with the optimization and
|
||||
„smart“ approach.
|
||||
“smart” approach.
|
||||
|
||||
For the first part you need to find the surface area of an obsidian that is
|
||||
approximated by cubes. Now, that is a very easy thing to do, just keep the track
|
||||
|
@ -209,7 +209,7 @@ of already added cubes, and check if the newly added cube touches any face of an
|
|||
other cube. Simple, and with a `BTreeSet` relatively efficient way to do it.
|
||||
|
||||
However the second part lets you on a secret that there may be some surface area
|
||||
from the „inside“ too and you want to know only the one from the outside of the
|
||||
from the “inside” too and you want to know only the one from the outside of the
|
||||
obsidian. I have seen some solutions later, but if you check your data, you might
|
||||
notice that the bounding box of all the cubes isn't that big at all. Therefore I
|
||||
chose to pre-construct the box beforehand, fill in the cubes and then just run a
|
||||
|
@ -246,7 +246,7 @@ to realize that this is the issue.
|
|||
### Solution
|
||||
|
||||
I have tried implementing a circular linked list for this… and I have failed
|
||||
miserably. To be fair, I still have no clue why. It was „fun“ to play around with
|
||||
miserably. To be fair, I still have no clue why. It was “fun” to play around with
|
||||
the `Rc<RefCell<T>>`. In the end I failed on _wrong answer_. I have also encountered
|
||||
a rather interesting issue with `.borrow_mut()` method being used on `Rc<RefCell<T>>`.
|
||||
|
||||
|
|
|
@ -502,7 +502,7 @@ Playing around with a numbers in a _special_ base.
|
|||
|
||||
:::
|
||||
|
||||
Getting flashbacks to the _IB111 Foundations of Programming_… Very nice „problem“
|
||||
Getting flashbacks to the _IB111 Foundations of Programming_… Very nice “problem”
|
||||
with a rather easy solution, as the last day always seems to be.
|
||||
|
||||
### Solution
|
||||
|
|
|
@ -4,7 +4,7 @@ title: Introduction
|
|||
slug: /
|
||||
---
|
||||
|
||||
In this part you can find „random“ additional materials I have written over the
|
||||
In this part you can find “random” additional materials I have written over the
|
||||
course of teaching _Algorithms and data structures I_.
|
||||
|
||||
It is a various mix of stuff that may have been produced as a follow-up on some
|
||||
|
|
|
@ -16,7 +16,7 @@ Each year there is a lot of confusion regarding time complexity of the `extend`
|
|||
|
||||
## Technicalities
|
||||
|
||||
At the beginning we should clear some of the „myths“ regarding extending of the lists. There is a common misunderstanding regarding differences between `a += b`, `a.extend(b)` and `a + b`.
|
||||
At the beginning we should clear some of the “myths” regarding extending of the lists. There is a common misunderstanding regarding differences between `a += b`, `a.extend(b)` and `a + b`.
|
||||
|
||||
- `a.extend(b)` - adds all elements from `b` to `a`.
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ backtracking can be even without anything else at your hand.
|
|||
### Environment
|
||||
|
||||
You are given a robot that is present in a maze and is looking for an exit. Maze
|
||||
consists of different walls and exit is marked with a single so-called „beeper“.
|
||||
consists of different walls and exit is marked with a single so-called “beeper”.
|
||||
|
||||
Walking into a wall results in a permanent damage of the robot.
|
||||
|
||||
|
@ -37,7 +37,7 @@ You can control the robot using the following interface:
|
|||
- notice that you are not given `turn_right` or `turn_around`, but feel free
|
||||
to implement them yourself
|
||||
- `robot.pick_beeper()` and opposite operation `robot.put_beeper()` — that
|
||||
allows you to either pick or put „beeper“ from or onto the current position
|
||||
allows you to either pick or put “beeper” from or onto the current position
|
||||
- queries — you can use them to check the current state of the robot and its
|
||||
surroundings
|
||||
- `robot.beepers_present()` — to check if there are any beepers at the robot's
|
||||
|
@ -157,7 +157,7 @@ the ZIP-file, you can there:
|
|||
## Solution
|
||||
|
||||
Solution to this problem will be released as a second part, so that you can try
|
||||
it out by yourself without any influence of „example solution“.
|
||||
it out by yourself without any influence of “example solution”.
|
||||
|
||||
If you want to get any feedback, feel free to mail me your solution (including
|
||||
all the steps that lead to your final solution, if you wish to get feedback on
|
||||
|
|
|
@ -33,7 +33,7 @@ By having a look at the graph we started from, we can see that we have a path
|
|||
|
||||
## Proof by contradiction
|
||||
|
||||
Let's keep the same graph, but break the lower bound, i.e. I have gotten a lower bound $2$, but „there must be a shorter path“! ;)
|
||||
Let's keep the same graph, but break the lower bound, i.e. I have gotten a lower bound $2$, but “there must be a shorter path”! ;)
|
||||
|
||||
Now the more important question, is there a shorter path in that graph? The answer is no, there's no shorter path than the one with length $2$. So what can we do about it? We'll add an edge to have a shorter path. Now we have gotten a lower bound of $2$, which means the only shorter path we can construct has $1$ edge and that is ‹$e, h$› (no intermediary vertices). Let's do this!
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ begin
|
|||
end VisitedDFS;
|
||||
```
|
||||
|
||||
This implementation is correct, does the DFS traversal as it should, however it has one „smallish“ downside and that is the time complexity. The usage of set raises the time complexity, of course it is implementation dependant. However in case of either RB-tree or hash-table implementation, we get look-up in time $\mathcal{O}(n)$ for hash-table in worst-case or $\mathcal{O}(\log n)$ for the other in the worst-case. Both are not ideal compared to checking color on vertex.
|
||||
This implementation is correct, does the DFS traversal as it should, however it has one “smallish” downside and that is the time complexity. The usage of set raises the time complexity, of course it is implementation dependant. However in case of either RB-tree or hash-table implementation, we get look-up in time $\mathcal{O}(n)$ for hash-table in worst-case or $\mathcal{O}(\log n)$ for the other in the worst-case. Both are not ideal compared to checking color on vertex.
|
||||
|
||||
### Iterative DFS from the exercises
|
||||
|
||||
|
|
Loading…
Reference in a new issue