41 lines
5.9 KiB
Markdown
41 lines
5.9 KiB
Markdown
# Предложенные вопросы:
|
||
## Сравните:
|
||
1) Как порядок входных данных влияет на скорость вставки в BST(деградация до O(n) на отсортированных данных).
|
||
2) Почему хеш-таблица почти не чувствительна к порядку.
|
||
3) Почему связный список всегда медленен при поиске.
|
||
4) Как удаление работает в каждой структуре.
|
||
5) Вывод должен содержать ответ на вопрос: какую структуру и для каких задач (частые вставки, частый поиск, необходимость получать данные в порядке) стоит выбирать в реальной жизни.*
|
||
# Анализ результатов:
|
||
![[analysis.png]]
|
||
>График созданный для на основе замеров времени работы разных типов данных
|
||
>P.s. Данные на графиках не точные, а приблизительные, из-за во многом случайных замеров значений
|
||
## Выводы:
|
||
### 1) **Как порядок входных данных влияет на скорость вставки в BST?**
|
||
Порядок отличается очень сильно, если в обычном случае сложность равна $O(log(n))$, а в худшем случае(как раз в случае отсортированных данных) равна $O(n)$.
|
||
>В моём случае время работы мало отличимо так как, во время замеров, я заметил, что данные записываются крайне долго за счёт особенностей реализации(бинарное дерево вырождалось в связный список) и пришлось добавить ещё одну функцию, которая будет искусственно разбивать отсортированный массив на 2 ветки, а не записывать все ветви подряд
|
||
### 2) **Почему хеш-таблица почти не чувствительна к порядку?**
|
||
Из-за особенностей записи данных в память. Хеш-таблица вычисляет, номер строки при помощи формулы т.е мы можем найти любой сколь угодный элемент за $O(1)$
|
||
### 3) **Почему связный список всегда медленен при поиске?**
|
||
Из-за способа записи. Так-как мы можем добраться до следующего элемента только путём перебора равного номеру поисковой строки, при сложности $O(n)$
|
||
### 4) Как удаление работает в каждой структуре?
|
||
- **Связный список**
|
||
Рассматривается 3 случая:
|
||
1) Если список пустой, **возращаем пустой список**
|
||
2) Если удаляем голову, то **возвращаем, как голову следующий элемент списка**
|
||
3) Если мы удаляем промежуточный элемент, ищем нужный элемент а потом **подменяем элементу стоящем перед элементом, который мы ищем ссылку элемента идущему после удаления**
|
||
- **Хеш-таблица**
|
||
Реализация считает при помощи Хеш-ключа, номер элемента
|
||
> P.s. В моей реализации Хеш-таблица и связный список схожи по реализации, потому что Хеш-таблица использует функцию связного списка)
|
||
- **Бинарное дерево**
|
||
Рассмотрим так же 4 случая(немного схожа со связным списком с поправкой на то, что потомок может быть не один):
|
||
1) Если список пустой, **возращаем пустой список**
|
||
2) Если элемент слева, то **спускаемся в левую ветвь**
|
||
3) Если элемент справа, то **спускаемся в правую ветвь**
|
||
4) Если ветки 2, то **как-то оцениваем обе вершины и двигаемся к нужному результату**
|
||
При нахождении элемента элементу слева от найденного передаём ссылку на правый от найденного элемента и наоборот левому элементу ссылку на правый
|
||
###
|
||
5) Какую структуру и для каких задач (частые вставки, частый поиск, необходимость получать данные в порядке) стоит выбирать в реальной жизни?
|
||
- Для частых вставок и поиска элементов следует использовать Хеш-таблицы, из-за особенностей добавления (определение номера в таблицы при помощи математической формулы, а не порядковым номером)
|
||
- В случае, если нам надо использовать упорядоченные данные, то следует использовать бинарное дерево(из-за особенностей хранения)
|
||
>P.s. Вывод 0) Как же долго работает функция print()...
|