xinyin025/hello-algo
1
0
Fork 0
mirror of https://github.com/krahets/hello-algo.git synced 2026-07-12 23:36:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy

Browse Source
This commit is contained in:
krahets
2026-04-14 18:06:19 +08:00
parent 17b2a0b630
commit cf0747ba3e
131 changed files with 604 additions and 609 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ru/chapter_computational_complexity/summary/index.html
+2 -2
View File
@@ -4391,10 +4391,10 @@
<li>Java и C# - объектно-ориентированные языки программирования, в которых блоки кода (методы) обычно являются частью класса. Статические методы по поведению похожи на функции, потому что они привязаны к классу и не могут обращаться к конкретным переменным экземпляра.</li>
<li>C++ и Python поддерживают как процедурное программирование (функции), так и объектно-ориентированное программирование (методы).</li>
</ul>
<p><strong>Q</strong>: Отражает ли диаграмма "распространенных типов пространственной сложности" абсолютный размер занятой памяти?</p>
<p><strong>Q</strong>: Отражает ли диаграмма «распространенных типов пространственной сложности» абсолютный размер занятой памяти?</p>
<p>Нет, эта диаграмма показывает пространственную сложность, а значит отражает именно тенденцию роста, а не абсолютный объем занятого пространства.</p>
<p>Если взять <span class="arithmatex">\(n = 8\)</span> , можно заметить, что значения на кривых не совпадают напрямую с соответствующими функциями. Это связано с тем, что каждая кривая содержит константный член, который сжимает диапазон значений до визуально удобного масштаба.</p>
<p>На практике, поскольку мы обычно не знаем, какова "константная" сложность каждого метода, только по сложности мы, как правило, не можем выбрать оптимальное решение для случая <span class="arithmatex">\(n = 8\)</span> . Но для <span class="arithmatex">\(n = 8^5\)</span> выбор уже очевиден: в этой области доминирует именно тенденция роста.</p>
<p>На практике, поскольку мы обычно не знаем, какова «константная» сложность каждого метода, только по сложности мы, как правило, не можем выбрать оптимальное решение для случая <span class="arithmatex">\(n = 8\)</span> . Но для <span class="arithmatex">\(n = 8^5\)</span> выбор уже очевиден: в этой области доминирует именно тенденция роста.</p>
<p><strong>Q</strong>: Бывают ли случаи, когда в реальных сценариях алгоритм специально проектируют так, чтобы жертвовать временем ради пространства или пространством ради времени?</p>
<p>На практике в большинстве случаев выбирают обмен пространства на время. Например, для индексов в базах данных обычно строят B+ деревья или хеш-индексы, расходуя значительный объем памяти ради эффективных запросов уровня <span class="arithmatex">\(O(\log n)\)</span> или даже <span class="arithmatex">\(O(1)\)</span>.</p>
<p>В сценариях, где память особенно дорога, наоборот, могут жертвовать временем ради пространства. Например, в embedded-разработке память устройства очень ограничена, поэтому инженеры могут отказаться от хеш-таблиц и выбрать последовательный поиск по массиву, экономя память ценой более медленного поиска.</p>