diff --git a/mkdocs.yml b/mkdocs.yml index 46ce8dc35..eecb39cb4 100644 --- a/mkdocs.yml +++ b/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: diff --git a/ru/docs/chapter_computational_complexity/iteration_and_recursion.md b/ru/docs/chapter_computational_complexity/iteration_and_recursion.md index 7377c0f4a..eff385e9f 100644 --- a/ru/docs/chapter_computational_complexity/iteration_and_recursion.md +++ b/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` : diff --git a/ru/docs/chapter_computational_complexity/time_complexity.md b/ru/docs/chapter_computational_complexity/time_complexity.md index 1070314dc..a732941ec 100644 --- a/ru/docs/chapter_computational_complexity/time_complexity.md +++ b/ru/docs/chapter_computational_complexity/time_complexity.md @@ -972,7 +972,7 @@ $$ ### Шаг 2: определение асимптотической верхней границы -**Временная сложность определяется старшим по степени членом в $T(n)$ **. Это связано с тем, что при стремлении $n$ к бесконечности именно старший член начинает доминировать, а влиянием остальных членов можно пренебречь. +**Временная сложность определяется старшим по степени членом в $T(n)$**. Это связано с тем, что при стремлении $n$ к бесконечности именно старший член начинает доминировать, а влиянием остальных членов можно пренебречь. В таблице ниже приведены несколько примеров. Некоторые значения специально сделаны преувеличенными, чтобы подчеркнуть вывод: коэффициент не способен изменить порядок. Когда $n$ стремится к бесконечности, эти константы становятся несущественными. diff --git a/ru/docs/chapter_data_structure/number_encoding.md b/ru/docs/chapter_data_structure/number_encoding.md index f4fbfc12b..de33a8927 100644 --- a/ru/docs/chapter_data_structure/number_encoding.md +++ b/ru/docs/chapter_data_structure/number_encoding.md @@ -42,7 +42,7 @@ $$ \end{aligned} $$ -С другой стороны, **в прямом коде у нуля есть два представления: $+0$ и $-0$ **. Это означает, что числу ноль соответствуют два разных двоичных кода, что может приводить к неоднозначности. Например, если в условном выражении не различать положительный и отрицательный ноль, можно получить ошибочный результат. А если специально обрабатывать такую неоднозначность, придется вводить дополнительные проверки, что может снизить вычислительную эффективность компьютера. +С другой стороны, **в прямом коде у нуля есть два представления: $+0$ и $-0$**. Это означает, что числу ноль соответствуют два разных двоичных кода, что может приводить к неоднозначности. Например, если в условном выражении не различать положительный и отрицательный ноль, можно получить ошибочный результат. А если специально обрабатывать такую неоднозначность, придется вводить дополнительные проверки, что может снизить вычислительную эффективность компьютера. $$ \begin{aligned} diff --git a/ru/docs/chapter_data_structure/summary.md b/ru/docs/chapter_data_structure/summary.md index bd5839dcd..def9a579a 100644 --- a/ru/docs/chapter_data_structure/summary.md +++ b/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»: diff --git a/ru/docs/chapter_hashing/hash_algorithm.md b/ru/docs/chapter_hashing/hash_algorithm.md index 4495e21dd..a6d2ecb67 100644 --- a/ru/docs/chapter_hashing/hash_algorithm.md +++ b/ru/docs/chapter_hashing/hash_algorithm.md @@ -12,7 +12,7 @@ index = hash(key) % capacity ``` -Из этой формулы видно: при фиксированной емкости хеш-таблицы `capacity` **выходное значение определяет именно хеш-алгоритм `hash()` **, а значит, именно он определяет распределение пар ключ-значение в хеш-таблице. +Из этой формулы видно: при фиксированной емкости хеш-таблицы `capacity` **выходное значение определяет именно хеш-алгоритм `hash()`**, а значит, именно он определяет распределение пар ключ-значение в хеш-таблице. Это означает, что для уменьшения вероятности хеш-коллизий нам следует сосредоточиться на проектировании хеш-алгоритма `hash()` . diff --git a/ru/docs/chapter_hashing/hash_collision.md b/ru/docs/chapter_hashing/hash_collision.md index ef9a0a6b5..bd3707cf4 100644 --- a/ru/docs/chapter_hashing/hash_collision.md +++ b/ru/docs/chapter_hashing/hash_collision.md @@ -60,7 +60,7 @@ ![Проблема поиска после удаления элемента в открытой адресации](hash_collision.assets/hash_table_open_addressing_deletion.png) -Чтобы решить эту проблему, можно использовать механизм ленивого удаления (lazy deletion): он не удаляет элемент из хеш-таблицы напрямую, **а помечает этот бакет специальной константой `TOMBSTONE` **. В этом механизме и `None` , и `TOMBSTONE` означают пустой бакет, и оба могут быть использованы для размещения пары ключ-значение. Но есть важное различие: при линейном пробировании, встретив `TOMBSTONE` , нужно продолжать обход, потому что ниже него все еще могут существовать пары ключ-значение. +Чтобы решить эту проблему, можно использовать механизм ленивого удаления (lazy deletion): он не удаляет элемент из хеш-таблицы напрямую, **а помечает этот бакет специальной константой `TOMBSTONE`**. В этом механизме и `None` , и `TOMBSTONE` означают пустой бакет, и оба могут быть использованы для размещения пары ключ-значение. Но есть важное различие: при линейном пробировании, встретив `TOMBSTONE` , нужно продолжать обход, потому что ниже него все еще могут существовать пары ключ-значение. Однако **ленивое удаление может ускорять деградацию производительности хеш-таблицы**. Это связано с тем, что каждая операция удаления создает новую метку удаления. По мере роста числа `TOMBSTONE` время поиска тоже увеличивается, потому что линейное пробирование может быть вынуждено перескакивать через множество `TOMBSTONE` , прежде чем найдет целевой элемент.