[1] add task report

raskatovia/docs/task1report.md

@@ -0,0 +1,36 @@
+ Цель работы
+В этой работе я сделал телефонный справочник на основе трёх структур данных связного списка, хеш таблицы и двоичного дерева поиска. Для каждой структуры нужны были добавление, поиск, удаление и вывод всех записей по алфавиту. после этого я сравнил как они работают на перемешанных и отсортированных данных [сначала казалось что разница будет не такой заметной но после мы увидим что разница есть и в зависимости от задачи и ситуации].
+
+ Что было реализовано
+ Связный список
+Узел списка хранит имя, телефон и ссылку на следующий элемент. При добавлении запись создаётся или обновляется если такое имя уже есть. Использованы функции ll_insert; ll_find; ll_delete; ll_list_all. [с этой структурой было проще всего начать, потому что логика достаточно прямая]
+
+ Хеш таблица
+Хеш таблица сделана как набор ячеек для записей. Для имени вычисляется место куда его сохранить. Если в этом месте уже есть записи они хранятся вместе в связном списке. Использованы функции ht_create; ht_insert; ht_find; ht_delete; ht_list_all. [здесь пришлось отдельно разобраться что делать если несколько имён попадают в одно место. В итоге для таких записей внутри одной ячейки используется связный список]
+
+ Двоичное дерево поиска
+В каждом узле дерева хранятся имя, телефон, левый и правый потомок. Записи размещаются по имени поэтому их можно вывести в отсортированном виде. Использованы функции bst_insert; bst_find; bst_delete; bst_list_all. [с удалением в дереве пришлось посидеть дольше всего. Ну если коротко у удаления в дереве несколько случаев: удаляется лист, у узла есть один потомок, у узла есть два потомка, тогда его нужно заменить ближайшим подходящим элементом]
+
+ Проверка работы
+В файле tests.py были сделаны простые проверки для всех трёх структур. Я проверил добавление записей; изменение телефона у уже существующего имени; поиск существующей и несуществующей записи; удаление и вывод списка по алфавиту. по результатам запуска всё сработало корректно. [было важно проверить основные операции ещё до замеров]
+
+ Замеры времени
+Для сравнения был создан набор из 10000 записей. Использовались два варианта случайный порядок и отсортированный порядок. Для каждой структуры измерялось время вставки всех записей; поиска 110 имён; удаления 50 записей. Каждый замер повторялся 5 раз. Средние значения приведены ниже а полные результаты сохранены в results.csv. [здесь пришлось отдельно разбираться как нормально замерять время. Сначала было не очень понятно как сравнивать структуры честно, потом сделал несколько повторов для каждого случая и считал среднее время]
+
+ Результаты
+Связный список; случайный порядок; вставка 17.54 сек; поиск 0.145 сек; удаление 0.086 сек.
+Связный список; отсортированный порядок; вставка 15.01 сек; поиск 0.127 сек; удаление 0.074 сек.
+Хеш таблица; случайный порядок; вставка 0.896 сек; поиск 0.008 сек; удаление 0.005 сек.
+Хеш таблица; отсортированный порядок; вставка 1.253 сек; поиск 0.008 сек; удаление 0.005 сек.
+BST; случайный порядок; вставка 0.063 сек; поиск 0.0006 сек; удаление 0.0003 сек.
+BST; отсортированный порядок; вставка 23.08 сек; поиск 0.170 сек; удаление 0.097 сек.
+
+ Анализ
+По замерам видно что связный список медленно работает при вставке. Перед добавлением новой записи программа идёт по списку и проверяет нет ли уже такого имени. На 10000 записей это уже заметно. Поиск тоже идёт простым перебором. [вот тут стало понятнее почему список быстро начинает тормозить]
+
+Хеш таблица показала себя намного быстрее. Записи были и перемешанные и уже отсортированные но большой разницы во времени почти не получилось. [этот результат как раз хорошо показал зачем вообще нужна такая структура]
+
+BST на случайных данных оказался самым быстрым. А вот на отсортированных данных дерево сильно замедлилось. Оно вытягивается почти в одну линию и начинает работать похоже на список. Поэтому вставка заняла около 23 секунд вместо 0.06. [при подготовке замеров стало понятно что на отсортированных данных дерево сильно вытягивается в одну сторону, а старая рекурсивная версия могла плохо отработать на 10000 записей Поэтому часть работы с Бст пришлось переделать без рекурсии]
+
+ Вывод
+Связный список подойдёт для небольшого количества данных но для большого справочника он не очень удобен. Хеш таблица лучше подходит если важны быстрые добавление, поиск и удаление. BST удобно использовать когда нужен вывод записей по порядку но обычное дерево сильно зависит от того в каком порядке добавляются элементы. На отсортированных данных оно работает заметно хуже. в целом работа оказалась не самой простой, местами было довольно запутанно особенно с замерами и деревом на отсортированных данных но в итоге было интересно увидеть насколько по-разному ведут себя разные структуры.