2026-rff_mp/vinichukan/docs/data/ conclusion.md

84 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## Анализ результатов
### **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** | inorder обход |
| Маленькие данные | Любая | Разницы нет |
| Учебные цели | LinkedList | Простая структура |
### **Общий вывод:**
> В реальных приложениях телефонный справочник почти всегда реализуют через **хеш‑таблицу**, так как она обеспечивает лучшую производительность для вставки, поиска и удаления.