Fix bold rendering across language editions (#2007)

mkdocs.yml

@@ -125,7 +125,7 @@ markdown_extensions:
   pymdownx.arithmatex:
     generic: true
   pymdownx.betterem:
-    smart_enable: all
+    smart_enable: underscore
   pymdownx.caret: {}
   pymdownx.details: {}
   # pymdownx.emoji:

ru/docs/chapter_computational_complexity/iteration_and_recursion.md

@@ -32,7 +32,7 @@
 [file]{iteration}-[class]{}-[func]{while_loop}
 ```
 
-**Цикл `while` обладает большей степенью свободы по сравнению с циклом `for` **. В цикле `while` можно свободно управлять инициализацией и обновлением условной переменной.
+**Цикл `while` обладает большей степенью свободы по сравнению с циклом `for`**. В цикле `while` можно свободно управлять инициализацией и обновлением условной переменной.
 
 Например, в следующем коде условная переменная $i$ обновляется дважды на каждой итерации, что затруднительно сделать с использованием цикла `for` :
 

ru/docs/chapter_computational_complexity/time_complexity.md

@@ -972,7 +972,7 @@ $$
 
 ### Шаг 2: определение асимптотической верхней границы
 
-**Временная сложность определяется старшим по степени членом в $T(n)$ **. Это связано с тем, что при стремлении $n$ к бесконечности именно старший член начинает доминировать, а влиянием остальных членов можно пренебречь.
+**Временная сложность определяется старшим по степени членом в $T(n)$**. Это связано с тем, что при стремлении $n$ к бесконечности именно старший член начинает доминировать, а влиянием остальных членов можно пренебречь.
 
 В таблице ниже приведены несколько примеров. Некоторые значения специально сделаны преувеличенными, чтобы подчеркнуть вывод: коэффициент не способен изменить порядок. Когда $n$ стремится к бесконечности, эти константы становятся несущественными.
 

ru/docs/chapter_data_structure/number_encoding.md

@@ -42,7 +42,7 @@ $$
 \end{aligned}
 $$
 
-С другой стороны, **в прямом коде у нуля есть два представления: $+0$ и $-0$ **. Это означает, что числу ноль соответствуют два разных двоичных кода, что может приводить к неоднозначности. Например, если в условном выражении не различать положительный и отрицательный ноль, можно получить ошибочный результат. А если специально обрабатывать такую неоднозначность, придется вводить дополнительные проверки, что может снизить вычислительную эффективность компьютера.
+С другой стороны, **в прямом коде у нуля есть два представления: $+0$ и $-0$**. Это означает, что числу ноль соответствуют два разных двоичных кода, что может приводить к неоднозначности. Например, если в условном выражении не различать положительный и отрицательный ноль, можно получить ошибочный результат. А если специально обрабатывать такую неоднозначность, придется вводить дополнительные проверки, что может снизить вычислительную эффективность компьютера.
 
 $$
 \begin{aligned}

ru/docs/chapter_data_structure/summary.md

@@ -43,7 +43,7 @@ $$
 0010 \rightarrow 1101 \rightarrow 1110
 $$
 
-Мы видим, что сумма прямого и дополнительного кодов равна $0010 + 1110 = 10000$ , то есть дополнительный код $1110$ является «дополнением» прямого кода $0010$ до $10000$ . **Это означает, что описанная выше операция «сначала инвертировать, затем прибавить 1» на самом деле вычисляет дополнение до $10000$ **.
+Мы видим, что сумма прямого и дополнительного кодов равна $0010 + 1110 = 10000$ , то есть дополнительный код $1110$ является «дополнением» прямого кода $0010$ до $10000$ . **Это означает, что описанная выше операция «сначала инвертировать, затем прибавить 1» на самом деле вычисляет дополнение до $10000$**.
 
 Тогда чему равно «дополнение» дополнительного кода $1110$ до $10000$ ? Мы снова можем получить его правилом «сначала инвертировать, затем прибавить 1»:
 

ru/docs/chapter_hashing/hash_algorithm.md

@@ -12,7 +12,7 @@
 index = hash(key) % capacity
 ```
 
-Из этой формулы видно: при фиксированной емкости хеш-таблицы `capacity` **выходное значение определяет именно хеш-алгоритм `hash()` **, а значит, именно он определяет распределение пар ключ-значение в хеш-таблице.
+Из этой формулы видно: при фиксированной емкости хеш-таблицы `capacity` **выходное значение определяет именно хеш-алгоритм `hash()`**, а значит, именно он определяет распределение пар ключ-значение в хеш-таблице.
 
 Это означает, что для уменьшения вероятности хеш-коллизий нам следует сосредоточиться на проектировании хеш-алгоритма `hash()` .
 

ru/docs/chapter_hashing/hash_collision.md

@@ -60,7 +60,7 @@
 
 ![Проблема поиска после удаления элемента в открытой адресации](hash_collision.assets/hash_table_open_addressing_deletion.png)
 
-Чтобы решить эту проблему, можно использовать механизм <u>ленивого удаления (lazy deletion)</u>: он не удаляет элемент из хеш-таблицы напрямую, **а помечает этот бакет специальной константой `TOMBSTONE` **. В этом механизме и `None` , и `TOMBSTONE` означают пустой бакет, и оба могут быть использованы для размещения пары ключ-значение. Но есть важное различие: при линейном пробировании, встретив `TOMBSTONE` , нужно продолжать обход, потому что ниже него все еще могут существовать пары ключ-значение.
+Чтобы решить эту проблему, можно использовать механизм <u>ленивого удаления (lazy deletion)</u>: он не удаляет элемент из хеш-таблицы напрямую, **а помечает этот бакет специальной константой `TOMBSTONE`**. В этом механизме и `None` , и `TOMBSTONE` означают пустой бакет, и оба могут быть использованы для размещения пары ключ-значение. Но есть важное различие: при линейном пробировании, встретив `TOMBSTONE` , нужно продолжать обход, потому что ниже него все еще могут существовать пары ключ-значение.
 
 Однако **ленивое удаление может ускорять деградацию производительности хеш-таблицы**. Это связано с тем, что каждая операция удаления создает новую метку удаления. По мере роста числа `TOMBSTONE` время поиска тоже увеличивается, потому что линейное пробирование может быть вынуждено перескакивать через множество `TOMBSTONE` , прежде чем найдет целевой элемент.