From 85cda31779e076b8543c2f3e963edf57312a915f Mon Sep 17 00:00:00 2001 From: Matej Focko Date: Wed, 6 Sep 2023 19:41:01 +0200 Subject: [PATCH] =?UTF-8?q?fix:=20revert=20the=20=E2=80=B9ThemedSVG?= =?UTF-8?q?=E2=80=BA=20shite?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Matej Focko --- ...-03-31-extend.mdx => 2021-03-31-extend.md} | 8 +--- ...23-06-10-rules.mdx => 2023-06-10-rules.md} | 39 ++++++++++--------- ...30-bfs-tree.mdx => 2022-04-30-bfs-tree.md} | 15 ++++--- 3 files changed, 32 insertions(+), 30 deletions(-) rename ib002/03-time-complexity/{2021-03-31-extend.mdx => 2021-03-31-extend.md} (96%) rename ib002/08-rb-trees/{2023-06-10-rules.mdx => 2023-06-10-rules.md} (72%) rename ib002/10-graphs/{2022-04-30-bfs-tree.mdx => 2022-04-30-bfs-tree.md} (76%) diff --git a/ib002/03-time-complexity/2021-03-31-extend.mdx b/ib002/03-time-complexity/2021-03-31-extend.md similarity index 96% rename from ib002/03-time-complexity/2021-03-31-extend.mdx rename to ib002/03-time-complexity/2021-03-31-extend.md index b1a7110..49568d4 100644 --- a/ib002/03-time-complexity/2021-03-31-extend.mdx +++ b/ib002/03-time-complexity/2021-03-31-extend.md @@ -13,8 +13,6 @@ last_update: date: 2021-03-31 --- -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. @@ -88,10 +86,8 @@ 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/time-complexity/extend/construction_light.svg#gh-light-mode-only) +![Rendered construction of the list](/files/ib002/time-complexity/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/2023-06-10-rules.mdx b/ib002/08-rb-trees/2023-06-10-rules.md similarity index 72% rename from ib002/08-rb-trees/2023-06-10-rules.mdx rename to ib002/08-rb-trees/2023-06-10-rules.md index e7d296d..51a85e5 100644 --- a/ib002/08-rb-trees/2023-06-10-rules.mdx +++ b/ib002/08-rb-trees/2023-06-10-rules.md @@ -10,8 +10,6 @@ last_update: date: 2023-06-10 --- -import ThemedSVG from "@site/src/components/ThemedSVG"; - ## Introduction Have you ever thought about the red-black tree rules in more depth? Why are they @@ -57,10 +55,8 @@ 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: @@ -144,15 +140,15 @@ accordingly. | 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) | +| ![2ª insertion](/files/ib002/rb-trees/rules/red-root/br_1_light.svg#gh-light-mode-only)![2ª insertion](/files/ib002/rb-trees/rules/red-root/br_1_dark.svg#gh-dark-mode-only) | ![2ª insertion](/files/ib002/rb-trees/rules/red-root/rr_1_light.svg#gh-light-mode-only)![2ª insertion](/files/ib002/rb-trees/rules/red-root/rr_1_dark.svg#gh-dark-mode-only) | +| ![3ª insertion](/files/ib002/rb-trees/rules/red-root/br_2_light.svg#gh-light-mode-only)![3ª insertion](/files/ib002/rb-trees/rules/red-root/br_2_dark.svg#gh-dark-mode-only) | ![3ª insertion](/files/ib002/rb-trees/rules/red-root/rr_2_light.svg#gh-light-mode-only)![3ª insertion](/files/ib002/rb-trees/rules/red-root/rr_2_dark.svg#gh-dark-mode-only) | +| ![4ª insertion](/files/ib002/rb-trees/rules/red-root/br_3_light.svg#gh-light-mode-only)![4ª insertion](/files/ib002/rb-trees/rules/red-root/br_3_dark.svg#gh-dark-mode-only) | ![4ª insertion](/files/ib002/rb-trees/rules/red-root/rr_3_light.svg#gh-light-mode-only)![4ª insertion](/files/ib002/rb-trees/rules/red-root/rr_3_dark.svg#gh-dark-mode-only) | +| ![5ª insertion](/files/ib002/rb-trees/rules/red-root/br_4_light.svg#gh-light-mode-only)![5ª insertion](/files/ib002/rb-trees/rules/red-root/br_4_dark.svg#gh-dark-mode-only) | ![5ª insertion](/files/ib002/rb-trees/rules/red-root/rr_4_light.svg#gh-light-mode-only)![5ª insertion](/files/ib002/rb-trees/rules/red-root/rr_4_dark.svg#gh-dark-mode-only) | +| ![6ª insertion](/files/ib002/rb-trees/rules/red-root/br_5_light.svg#gh-light-mode-only)![6ª insertion](/files/ib002/rb-trees/rules/red-root/br_5_dark.svg#gh-dark-mode-only) | ![6ª insertion](/files/ib002/rb-trees/rules/red-root/rr_5_light.svg#gh-light-mode-only)![6ª insertion](/files/ib002/rb-trees/rules/red-root/rr_5_dark.svg#gh-dark-mode-only) | +| ![7ª insertion](/files/ib002/rb-trees/rules/red-root/br_6_light.svg#gh-light-mode-only)![7ª insertion](/files/ib002/rb-trees/rules/red-root/br_6_dark.svg#gh-dark-mode-only) | ![7ª insertion](/files/ib002/rb-trees/rules/red-root/rr_6_light.svg#gh-light-mode-only)![7ª insertion](/files/ib002/rb-trees/rules/red-root/rr_6_dark.svg#gh-dark-mode-only) | +| ![8ª insertion](/files/ib002/rb-trees/rules/red-root/br_7_light.svg#gh-light-mode-only)![8ª insertion](/files/ib002/rb-trees/rules/red-root/br_7_dark.svg#gh-dark-mode-only) | ![8ª insertion](/files/ib002/rb-trees/rules/red-root/rr_7_light.svg#gh-light-mode-only)![8ª insertion](/files/ib002/rb-trees/rules/red-root/rr_7_dark.svg#gh-dark-mode-only) | +| ![9ª insertion](/files/ib002/rb-trees/rules/red-root/br_8_light.svg#gh-light-mode-only)![9ª insertion](/files/ib002/rb-trees/rules/red-root/br_8_dark.svg#gh-dark-mode-only) | ![9ª insertion](/files/ib002/rb-trees/rules/red-root/rr_8_light.svg#gh-light-mode-only)![9ª insertion](/files/ib002/rb-trees/rules/red-root/rr_8_dark.svg#gh-dark-mode-only) | ## 3ª Every leaf (`nil`) is black. @@ -161,7 +157,8 @@ 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: - +![](/files/ib002/rb-trees/rules/rb_light.svg#gh-light-mode-only) +![](/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 @@ -234,11 +231,17 @@ import TabItem from '@theme/TabItem'; - + +![](/files/ib002/rb-trees/rules/red-node-black-children/correct_light.svg#gh-light-mode-only) +![](/files/ib002/rb-trees/rules/red-node-black-children/correct_dark.svg#gh-dark-mode-only) + - + +![](/files/ib002/rb-trees/rules/red-node-black-children/incorrect_light.svg#gh-light-mode-only) +![](/files/ib002/rb-trees/rules/red-node-black-children/incorrect_dark.svg#gh-dark-mode-only) + diff --git a/ib002/10-graphs/2022-04-30-bfs-tree.mdx b/ib002/10-graphs/2022-04-30-bfs-tree.md similarity index 76% rename from ib002/10-graphs/2022-04-30-bfs-tree.mdx rename to ib002/10-graphs/2022-04-30-bfs-tree.md index 32bb1aa..a0e292c 100644 --- a/ib002/10-graphs/2022-04-30-bfs-tree.mdx +++ b/ib002/10-graphs/2022-04-30-bfs-tree.md @@ -10,8 +10,6 @@ last_update: date: 2022-04-30 --- -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: @@ -23,11 +21,13 @@ As we have talked on the seminar, if we construct from some vertex $u$ BFS tree Consider the following graph: - +![](/files/ib002/graphs/bfs-tree/bfs_graph_light.svg#gh-light-mode-only) +![](/files/ib002/graphs/bfs-tree/bfs_graph_dark.svg#gh-dark-mode-only) We run BFS from the vertex $a$ and obtain the following BFS tree: - +![](/files/ib002/graphs/bfs-tree/bfs_tree_light.svg#gh-light-mode-only) +![](/files/ib002/graphs/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: @@ -42,7 +42,9 @@ 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! - +![](/files/ib002/graphs/bfs-tree/bfs_graph_with_additional_edge_light.svg#gh-light-mode-only) +![](/files/ib002/graphs/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. @@ -54,7 +56,8 @@ Do we need to run BFS after **every** change? ::: - +![](/files/ib002/graphs/bfs-tree/bfs_tree_with_additional_edge_light.svg#gh-light-mode-only) +![](/files/ib002/graphs/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.