mirror of
https://github.com/mfocko/blog.git
synced 2024-11-10 00:09:07 +01:00
revert: "fix: switch graphviz to pngs as it is unusable now"
This reverts commit a5b6f8b128.
This commit is contained in:
parent
a5b6f8b128
commit
326612b3e2
GPG key ID:
7C47D46246790496
4 changed files with 30 additions and 30 deletions
|
|
@ -86,8 +86,8 @@ As we could observe in the example above, `extend` iterates over all of the elem
|
|||
|
||||
Consider constructing of this list:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Let us assume that you extend the result with the list that you get from the recursive call.
|
||||
|
||||
|
|
|
|||
|
|
@ -55,8 +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:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
|
@ -140,15 +140,15 @@ accordingly.
|
|||
|
||||
| Usual algorithm with black root | Allowing red root |
|
||||
| :-----------------------------: | :---------------: |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|
||||
## 3ª Every leaf (`nil`) is black.
|
||||
|
||||
|
|
@ -157,8 +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:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
|
@ -232,15 +232,15 @@ import TabItem from '@theme/TabItem';
|
|||
<Tabs>
|
||||
<TabItem value="enforcing" label="Enforcing this rule">
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="omitting" label="Omitting this rule">
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -21,13 +21,13 @@ As we have talked on the seminar, if we construct from some vertex $u$ BFS tree
|
|||
|
||||
Consider the following graph:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
We run BFS from the vertex $a$ and obtain the following BFS tree:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Let's consider pair of vertices $e$ and $h$. For them we can safely lay, from the BFS tree, following properties:
|
||||
|
||||
|
|
@ -42,8 +42,8 @@ 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!
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
|
@ -56,8 +56,8 @@ Do we need to run BFS after **every** change?
|
|||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Oops, we have gotten a new BFS tree, that has a height difference of 1.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,11 +3,11 @@
|
|||
FONT="'Cascadia Code PL', 'JetBrains Mono', 'Iosevka', 'Fira Code', 'Hack', monospace"
|
||||
|
||||
for pic in $(find ./static/files -name '*.dot' -print); do
|
||||
PNG_NAME=".$(echo $pic | cut -d'.' -f2)"
|
||||
SVG_NAME=".$(echo $pic | cut -d'.' -f2)"
|
||||
|
||||
# light mode
|
||||
dot $pic -Tpng -Gfontname="$FONT" -Nfontname="$FONT" -Efontname="$FONT" > ${PNG_NAME}_light.png
|
||||
dot $pic -Tsvg -Gfontname="$FONT" -Nfontname="$FONT" -Efontname="$FONT" > ${SVG_NAME}_light.svg
|
||||
|
||||
# dark mode
|
||||
dot $pic -Tpng -Gfontname="$FONT" -Nfontname="$FONT" -Efontname="$FONT" -Gbgcolor="#1b1b1d" -Gcolor="white" -Gfontcolor="white" -Nfillcolor="none" -Ncolor="white" -Nfontcolor="white" -Efillcolor="none" -Ecolor="white" -Efontcolor="white" > ${PNG_NAME}_dark.png
|
||||
dot $pic -Tsvg -Gfontname="$FONT" -Nfontname="$FONT" -Efontname="$FONT" -Gbgcolor="#1b1b1d" -Gcolor="white" -Gfontcolor="white" -Nfillcolor="none" -Ncolor="white" -Nfontcolor="white" -Efillcolor="none" -Ecolor="white" -Efontcolor="white" > ${SVG_NAME}_dark.svg
|
||||
done;
|
||||
|
|
|
|||
Loading…
Reference in a new issue