mirror of
https://github.com/mfocko/blog.git
synced 2024-09-20 02:16:56 +02:00
chore: switch to ‹ThemedSVG› where possible
Signed-off-by: Matej Focko <mfocko@redhat.com>
This commit is contained in:
parent
568b9194d2
commit
b841daccf7
GPG key ID:
7C47D46246790496
3 changed files with 32 additions and 10 deletions
|
|
@ -10,6 +10,8 @@ tags:
|
|||
- recursion
|
||||
---
|
||||
|
||||
import ThemedSVG from "@site/src/components/ThemedSVG";
|
||||
|
||||
## Introduction
|
||||
|
||||
Each year there is a lot of confusion regarding time complexity of the `extend` operation on the lists in Python. I will introduce two specific examples from previous year and also will try to explain it on one of the possible implementations of `extend` operation.
|
||||
|
|
@ -83,7 +85,10 @@ As we could observe in the example above, `extend` iterates over all of the elem
|
|||
|
||||
Consider constructing of this list:
|
||||
|
||||
|
||||
<ThemedSVG
|
||||
source="/files/ib002/extend/construction"
|
||||
alt="Rendered construction of the list"
|
||||
/>
|
||||
|
||||
Let us assume that you extend the result with the list that you get from the recursive call.
|
||||
|
||||
|
|
@ -7,6 +7,8 @@ tags:
|
|||
- balanced trees
|
||||
---
|
||||
|
||||
import ThemedSVG from "@site/src/components/ThemedSVG";
|
||||
|
||||
## Introduction
|
||||
|
||||
Have you ever thought about the red-black tree rules in more depth? Why are they
|
||||
|
|
@ -52,7 +54,10 @@ my child would be colored red.
|
|||
Example of a red-black tree that keeps count of black nodes on paths to the
|
||||
leaves follows:
|
||||
|
||||
|
||||
<ThemedSVG
|
||||
source="/files/ib002/rb-trees/rules/rb_height"
|
||||
alt="Red-black tree with black height"
|
||||
/>
|
||||
|
||||
We mark the _black heights_ in superscript. You can see that all leaves have the
|
||||
black height equal to $1$. Let's take a look at some of the interesting cases:
|
||||
|
|
@ -134,6 +139,7 @@ black root property.
|
|||
If we decide to omit this condition, we need to address it in the pseudocodes
|
||||
accordingly.
|
||||
|
||||
{/* TODO: Switch to the themed SVG */}
|
||||
| Usual algorithm with black root | Allowing red root |
|
||||
| :-----------------------------: | :---------------: |
|
||||
|  |  |
|
||||
|
|
@ -153,7 +159,7 @@ some other way? Let's go through some of the possible ways I can look at this an
|
|||
how would they affect the other rules and balancing.
|
||||
|
||||
We will experiment with the following tree:
|
||||
|
||||
<ThemedSVG source="/files/ib002/rb-trees/rules/rb" />
|
||||
|
||||
We should start by counting the black nodes from root to the `nil` leaves based
|
||||
on the rules. We have multiple similar paths, so we will pick only the interesting
|
||||
|
|
@ -221,9 +227,18 @@ further.
|
|||
Let's assume that we do not enforce this rule, you can see how it breaks the
|
||||
balancing of the tree below.
|
||||
|
||||
| Enforcing this rule | Omitting this rule |
|
||||
| :-----------------: | :----------------: |
|
||||
|  |  |
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="enforcing" label="Enforcing this rule">
|
||||
<ThemedSVG source="/files/ib002/rb-trees/rules/red-node-black-children/correct" />
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="omitting" label="Omitting this rule">
|
||||
<ThemedSVG source="/files/ib002/rb-trees/rules/red-node-black-children/incorrect" />
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
We can create a **big** subtree with only red nodes and **even** when keeping
|
||||
the rest of the rules maintained, it will break the time complexity. It stops us
|
||||
|
|
@ -7,6 +7,8 @@ tags:
|
|||
- bfs
|
||||
---
|
||||
|
||||
import ThemedSVG from "@site/src/components/ThemedSVG";
|
||||
|
||||
## Introduction
|
||||
|
||||
As we have talked on the seminar, if we construct from some vertex $u$ BFS tree on an undirected graph, we can obtain:
|
||||
|
|
@ -18,11 +20,11 @@ As we have talked on the seminar, if we construct from some vertex $u$ BFS tree
|
|||
|
||||
Consider the following graph:
|
||||
|
||||
|
||||
<ThemedSVG source="/files/ib002/bfs-tree/bfs_graph" />
|
||||
|
||||
We run BFS from the vertex $a$ and obtain the following BFS tree:
|
||||
|
||||
|
||||
<ThemedSVG source="/files/ib002/bfs-tree/bfs_tree" />
|
||||
|
||||
Let's consider pair of vertices $e$ and $h$. For them we can safely lay, from the BFS tree, following properties:
|
||||
|
||||
|
|
@ -37,7 +39,7 @@ Let's keep the same graph, but break the lower bound, i.e. I have gotten a lower
|
|||
|
||||
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!
|
||||
|
||||
|
||||
<ThemedSVG source="/files/ib002/bfs-tree/bfs_graph_with_additional_edge" />
|
||||
|
||||
Okay, so we have a graph that breaks the rule we have laid. However, we need to run BFS to obtain the new BFS tree, since we have changed the graph.
|
||||
|
||||
|
|
@ -49,7 +51,7 @@ Do we need to run BFS after **every** change?
|
|||
|
||||
:::
|
||||
|
||||
|
||||
<ThemedSVG source="/files/ib002/bfs-tree/bfs_tree_with_additional_edge" />
|
||||
|
||||
Oops, we have gotten a new BFS tree, that has a height difference of 1.
|
||||
|
||||
Loading…
Reference in a new issue