forked from UNN/2026-rff_mp
84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
|
## Анализ результатов
|
|||
|
|
|
|||
|
|
### **1. Как порядок входных данных влияет на скорость вставки в BST**
|
|||
|
|
|
|||
|
|
BST работает быстро только если дерево сбалансировано.
|
|||
|
|
При случайном порядке глубина дерева ≈ `O(log n)`, поэтому вставка быстрая.
|
|||
|
|
Но при отсортированных данных дерево вырождается в цепочку.
|
|||
|
|
Вставка становится:
|
|||
|
|
|
|||
|
|
- **O(n)** на одну операцию
|
|||
|
|
- **O(n²)** на вставку всех элементов
|
|||
|
|
|
|||
|
|
Это приводит к резкому росту времени (в эксперименте: **0.02 сек → 5.23 сек**).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **2. Почему хеш‑таблица почти не чувствительна к порядку**
|
|||
|
|
|
|||
|
|
Хеш‑функция распределяет элементы по бакетам независимо от порядка входа.
|
|||
|
|
Поэтому:
|
|||
|
|
|
|||
|
|
- вставка ≈ **O(1)**
|
|||
|
|
- поиск ≈ **O(1)**
|
|||
|
|
- удаление ≈ **O(1)**
|
|||
|
|
|
|||
|
|
Даже если данные отсортированы, хеш‑таблица работает одинаково быстро.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **3. Почему связный список всегда медленный при поиске**
|
|||
|
|
|
|||
|
|
Связный список не имеет индексов.
|
|||
|
|
Поиск идёт последовательно: head → next → next → ...
|
|||
|
|
|
|||
|
|
Поэтому:
|
|||
|
|
|
|||
|
|
- поиск = **O(n)**
|
|||
|
|
- вставка в конец = **O(n)**
|
|||
|
|
- удаление = **O(n)**
|
|||
|
|
|
|||
|
|
Это делает его самой медленной структурой для телефонного справочника.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **4. Как работает удаление в каждой структуре**
|
|||
|
|
|
|||
|
|
#### Связный список
|
|||
|
|
- ищем предыдущий узел
|
|||
|
|
- перенаправляем ссылки
|
|||
|
|
- сложность: **O(n)**
|
|||
|
|
|
|||
|
|
#### Хеш‑таблица
|
|||
|
|
- вычисляем бакет
|
|||
|
|
- удаляем элемент в маленьком списке внутри бакета
|
|||
|
|
- сложность: **O(1)** в среднем
|
|||
|
|
|
|||
|
|
#### BST
|
|||
|
|
3 случая:
|
|||
|
|
1. лист
|
|||
|
|
2. один потомок
|
|||
|
|
3. два потомка (замена на inorder‑преемника)
|
|||
|
|
|
|||
|
|
Сложность:
|
|||
|
|
|
|||
|
|
- **O(log n)** в среднем
|
|||
|
|
- **O(n)** в худшем случае (несбалансированное дерево)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **5. Какую структуру выбирать в реальной жизни**
|
|||
|
|
|
|||
|
|
| Задача | Лучшая структура | Причина |
|
|||
|
|
|--------|------------------|---------|
|
|||
|
|
| Частые вставки | **HashTable** | O(1) |
|
|||
|
|
| Частый поиск | **HashTable** | O(1) |
|
|||
|
|
| Частое удаление | **HashTable** | O(1) |
|
|||
|
|
| Нужен отсортированный вывод | **BST** | in‑order обход |
|
|||
|
|
| Маленькие данные | Любая | Разницы нет |
|
|||
|
|
| Учебные цели | LinkedList | Простая структура |
|
|||
|
|
|
|||
|
|
### **Общий вывод:**
|
|||
|
|
> В реальных приложениях телефонный справочник почти всегда реализуют через **хеш‑таблицу**, так как она обеспечивает лучшую производительность для вставки, поиска и удаления.
|
|||
|
|
|