[1] task-1-data-structures #163

Open
ProninVV wants to merge 12 commits from ProninVV/2026-rff_mp:task-1-data-structures into develop
10 changed files with 23356 additions and 5 deletions
Showing only changes of commit 34d23ee54b - Show all commits

View File

@ -10,5 +10,4 @@
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Двоичное дерево поиска}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {3}Методика эксперимента}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {4}Результаты и анализ}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {5}Заключение}{3}{}\protected@file@percent }
\gdef \@abspage@last{4}
\gdef \@abspage@last{8}

View File

@ -53,10 +53,54 @@
\section{Результаты и анализ}
Было проведено 5 опытов.
\subsection{Связный список}
\subsection*{1. Бинарное дерево поиска (BST) и влияние порядка}
\begin{figure}[H]
\includegraphics[scale=0.7]{plots/Tree.eps}
\end{figure}
\begin{figure}[H]
\includegraphics[scale=0.7]{plots/Tre1.eps}
\end{figure}
\begin{itemize}
\item \textbf{Деградация на отсортированных данных:} При вставке отсортированных данных время увеличилось с \textbf{0.12с} (1000 эл.) до \textbf{13.24с} (10000 эл.). Рост более чем в 100 раз при увеличении данных в 10 раз указывает на сложность $O(n^2)$ для заполнения. Дерево выродилось в список.
\item \textbf{Эффективность на перемешанных данных:} На \texttt{shuffled} данных вставка 10000 элементов заняла всего \textbf{0.03с}. Это подтверждает логарифмическую сложность $O(\log n)$ для сбалансированного дерева.
\end{itemize}
\subsection*{2. Хеш-таблица: Стабильность и скорость}
\begin{figure}[h]
\includegraphics[scale=0.7]{plots/hasht.eps}
\end{figure}
\begin{itemize}
\item \textbf{Чувствительность к порядку:} Хеш-таблица показала идентичные результаты как на \texttt{shuffled}, так и на \texttt{sorted} данных (около \textbf{0.16с} для 10000 вставок). Это объясняется тем, что хеш-функция распределяет ключи по бакетам независимо от их исходного порядка.
\item \textbf{Превосходство:} На больших объемах хеш-таблица оказалась самой быстрой структурой для поиска и удаления ($\approx 0.001$с), что подтверждает среднюю сложность $O(1)$.
\item \textbf{Замечание} так как таблица содержит списки со вставкой в конец, при вставке наблюдается отклонение от линейной зависимости в сторону квадратичной
\end{itemize}
\subsection*{3. Связный список: Стабильная медлительность}
\begin{figure}[h]
\includegraphics[scale=0.7]{plots/llist.eps}
\end{figure}
\begin{itemize}
\item \textbf{Поиск и удаление:} Связный список показал худшие результаты среди всех структур на случайных данных. Время поиска при 10000 элементах (\textbf{0.03с}) на два порядка медленнее, чем у хеш-таблицы. Это подтверждает линейную сложность $O(n)$.
\item \textbf{Вставка:} Вставка в конец без указателя на хвост дает $O(n^2)$ при заполнении (\textbf{3.04с} на 10000 эл.), что сопоставимо с выродившимся деревом.
\end{itemize}
\subsection*{Вывод: выбор структуры данных}
\begin{enumerate}
\item \textbf{Хеш-таблица} — лучший выбор для реальных задач «ключ-значение». Она обеспечивает стабильное $O(1)$ и не зависит от порядка входящих данных.
\item \textbf{BST} — эффективен только при условии случайного распределения данных или использовании самобалансирующихся деревьев. В противном случае велик риск деградации до скорости списка.
\item \textbf{Связный список} — в данной реализации неэффективен для поиска и массовой вставки. Его стоит использовать только для специфических задач (стеки, очереди), где работа идет преимущественно с головой списка за $O(1)$.
\end{enumerate}
\section{Заключение}
%\section{Заключение}
% Ответ на вопрос о выборе структуры в реальной жизни
\end{document}

View File

@ -6,4 +6,3 @@
\contentsline {subsection}{\numberline {2.3}Двоичное дерево поиска}{3}{}%
\contentsline {section}{\numberline {3}Методика эксперимента}{3}{}%
\contentsline {section}{\numberline {4}Результаты и анализ}{3}{}%
\contentsline {section}{\numberline {5}Заключение}{3}{}%

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff