From b841daccf770ef2e8c1d21e260b3400f65d3772d Mon Sep 17 00:00:00 2001 From: Matej Focko Date: Thu, 20 Jul 2023 20:30:38 +0200 Subject: [PATCH] =?UTF-8?q?chore:=20switch=20to=20=E2=80=B9ThemedSVG?= =?UTF-8?q?=E2=80=BA=20where=20possible?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Matej Focko --- .../{extend.md => extend.mdx} | 7 +++++- ib002/08-rb-trees/{rules.md => rules.mdx} | 25 +++++++++++++++---- ib002/10-graphs/{bfs-tree.md => bfs-tree.mdx} | 10 +++++--- 3 files changed, 32 insertions(+), 10 deletions(-) rename ib002/03-time-complexity/{extend.md => extend.mdx} (96%) rename ib002/08-rb-trees/{rules.md => rules.mdx} (93%) rename ib002/10-graphs/{bfs-tree.md => bfs-tree.mdx} (76%) diff --git a/ib002/03-time-complexity/extend.md b/ib002/03-time-complexity/extend.mdx similarity index 96% rename from ib002/03-time-complexity/extend.md rename to ib002/03-time-complexity/extend.mdx index 2d697ca..a9ce564 100644 --- a/ib002/03-time-complexity/extend.md +++ b/ib002/03-time-complexity/extend.mdx @@ -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: -![Rendered construction of the list](/files/ib002/extend/construction_light.svg#gh-light-mode-only)![Rendered construction of the list](/files/ib002/extend/construction_dark.svg#gh-dark-mode-only) + Let us assume that you extend the result with the list that you get from the recursive call. diff --git a/ib002/08-rb-trees/rules.md b/ib002/08-rb-trees/rules.mdx similarity index 93% rename from ib002/08-rb-trees/rules.md rename to ib002/08-rb-trees/rules.mdx index e6387ce..386ca3c 100644 --- a/ib002/08-rb-trees/rules.md +++ b/ib002/08-rb-trees/rules.mdx @@ -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: -![Red-black tree with black height](/files/ib002/rb-trees/rules/rb_height_light.svg#gh-light-mode-only)![Red-black tree with black height](/files/ib002/rb-trees/rules/rb_height_dark.svg#gh-dark-mode-only) + 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 | | :-----------------------------: | :---------------: | | ![1ª insertion](/files/ib002/rb-trees/rules/red-root/br_0_light.svg#gh-light-mode-only)![1ª insertion](/files/ib002/rb-trees/rules/red-root/br_0_dark.svg#gh-dark-mode-only) | ![1ª insertion](/files/ib002/rb-trees/rules/red-root/rr_0_light.svg#gh-light-mode-only)![1ª insertion](/files/ib002/rb-trees/rules/red-root/rr_0_dark.svg#gh-dark-mode-only) | @@ -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: -![Red-black tree](/files/ib002/rb-trees/rules/rb_light.svg#gh-light-mode-only)![Red-black tree](/files/ib002/rb-trees/rules/rb_dark.svg#gh-dark-mode-only) + 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 | -| :-----------------: | :----------------: | -| ![correct](/files/ib002/rb-trees/rules/red-node-black-children/correct_light.svg#gh-light-mode-only)![correct](/files/ib002/rb-trees/rules/red-node-black-children/correct_dark.svg#gh-dark-mode-only) | ![incorrect](/files/ib002/rb-trees/rules/red-node-black-children/incorrect_light.svg#gh-light-mode-only)![incorrect](/files/ib002/rb-trees/rules/red-node-black-children/incorrect_dark.svg#gh-dark-mode-only) | +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + + + + + + + + + + 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 diff --git a/ib002/10-graphs/bfs-tree.md b/ib002/10-graphs/bfs-tree.mdx similarity index 76% rename from ib002/10-graphs/bfs-tree.md rename to ib002/10-graphs/bfs-tree.mdx index 388d17b..bef5f0d 100644 --- a/ib002/10-graphs/bfs-tree.md +++ b/ib002/10-graphs/bfs-tree.mdx @@ -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: -![BFS graph](/files/ib002/bfs-tree/bfs_graph_light.svg#gh-light-mode-only)![BFS graph](/files/ib002/bfs-tree/bfs_graph_dark.svg#gh-dark-mode-only) + We run BFS from the vertex $a$ and obtain the following BFS tree: -![BFS tree](/files/ib002/bfs-tree/bfs_tree_light.svg#gh-light-mode-only)![BFS tree](/files/ib002/bfs-tree/bfs_tree_dark.svg#gh-dark-mode-only) + 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! -![BFS tree](/files/ib002/bfs-tree/bfs_graph_with_additional_edge_light.svg#gh-light-mode-only)![BFS tree](/files/ib002/bfs-tree/bfs_graph_with_additional_edge_dark.svg#gh-dark-mode-only) + 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? ::: -![BFS tree](/files/ib002/bfs-tree/bfs_tree_with_additional_edge_light.svg#gh-light-mode-only)![BFS tree](/files/ib002/bfs-tree/bfs_tree_with_additional_edge_dark.svg#gh-dark-mode-only) + Oops, we have gotten a new BFS tree, that has a height difference of 1.