Feedback by github-classroom[bot] · Pull Request #1 · spbu-coding-2023/trees-5

github-classroom · 2024-03-18T06:42:52Z

👋! GitHub Classroom created this pull request as a place for your teacher to leave feedback on your work. It will update automatically. Don’t close or merge this pull request, unless you’re instructed to do so by your teacher.
In this pull request, your teacher can leave comments and feedback on your code. Click the Subscribe button to be notified if that happens.
Click the Files changed or Commits tab to see all of the changes pushed to main since the assignment started. Your teacher can see this too.

Notes for teachers

Use this PR to leave feedback. Here are some tips:

Click the Files changed tab to see all of the changes pushed to main since the assignment started. To leave comments on specific lines of code, put your cursor over a line of code and click the blue + (plus sign). To learn more about comments, read “Commenting on a pull request”.
Click the Commits tab to see the commits pushed to main. Click a commit to see specific changes.
If you turned on autograding, then click the Checks tab to see the results.
This page is an overview. It shows commits, line comments, and general comments. You can leave a general comment below.
For more information about this pull request, read “Leaving assignment feedback in GitHub”.

Subscribed: @p1onerka @sofyak0zyreva @shvorobsofia

Initialize project

Implement abstractions

Implement balanced tree class

…lement private methods for balancing

Implement BST and traverse method; Refactor abstractNode

Implement 1 balance method instead of 2

…ling and get grandParent

…d instead of private

Implement red-black node class and red-black tree class

Apply fixes in AVLTree and abstractTree

Implement tests for a reb-black tree

…t coverage analysis

Implement pack of tests for BST and do refactoring (add exception for null parent of non-root node)

sgrishkova

Понравилось, как у вас хорошо все организовано (например, переиспользование кода для поворотов, продуманная архитектура, понятные названия методов) и выполнено в едином стиле.

sgrishkova · 2024-04-03T16:51:02Z

lib/src/main/kotlin/nodes/abstractNode.kt

@@ -0,0 +1,6 @@
+package nodes
+
+abstract class abstractNode<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>(val key:K, var value: V) {


Согласно котлиновскому Coding conventions названия для классов лучше начинать с заглавной буквы.

Suggested change

abstract class abstractNode<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>(val key:K, var value: V) {

abstract class AbstractNode<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>(val key:K, var value: V) {

sgrishkova · 2024-04-03T16:55:26Z

lib/src/main/kotlin/trees/abstractTree.kt

+
+import nodes.abstractNode
+
+abstract class abstractTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>> {


Тоже названия классов.

Suggested change

abstract class abstractTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>> {

abstract class AbstractTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>> {

sgrishkova · 2024-04-03T17:27:33Z

lib/src/main/kotlin/nodes/abstractNode.kt

+    var leftChild: someNode? = null
+    var rightChild: someNode? = null


Хорошо ли, когда ссылки на детей узла public?
Вижу, что ни один из public методов не возвращает пользователю узел, т. е. трюк в духе
node1.leftChild = node2 пользователю провернуть будет не так просто, однако можно подумать над использованием модификатора internal.

Действительно, безопасность данных мы в первую очередь обеспечивали через устойчивость методов, так как именно за счет них происходит взаимодействие пользователя с библиотекой. Поэтому проблемы с таким решением маловероятны, но замечание на будущее хорошее, спасибо

sgrishkova · 2024-04-03T17:39:52Z

lib/src/main/kotlin/nodes/AVLNode.kt

+package nodes
+
+class AVLNode<K : Comparable<K>, V>(key: K, value: V): abstractNode<K, V, AVLNode<K, V>>(key, value) {
+    var height = 1


Стоит ли оставлять высоту узла public? Если кто-то вдруг получит доступ к узлу, то можно будет сделать что-нибудь в духе node.height = 42, а тогда и балансировка AVL поломается.

Возможно, тут тот же случай, что и выше. Хотя если пользователь добился доступа к ноде, ему ничего не помешает обходными путями сделать то же самое и здесь :)

sgrishkova · 2024-04-03T17:42:45Z

lib/src/main/kotlin/trees/balancedTree.kt

+
+import nodes.abstractNode
+
+abstract class balancedTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>: abstractTree<K, V, someNode>() {


Та же история про название класса.

Suggested change

abstract class balancedTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>: abstractTree<K, V, someNode>() {

abstract class BalancedTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>: abstractTree<K, V, someNode>() {

sgrishkova · 2024-04-03T20:42:58Z

lib/src/main/kotlin/trees/abstractTree.kt

+    }
+
+    protected fun traverse(curNode: someNode?, listOfNodes: MutableList<someNode>) {
+        if(curNode != null) {


Пробел.

Suggested change

if(curNode != null) {

if (curNode != null) {

sgrishkova · 2024-04-03T20:53:59Z

lib/src/test/kotlin/treesTests/AVLTreeTest.kt

+import org.junit.jupiter.api.Assertions.assertEquals
+import kotlin.test.Test
+
+


Почему не используете @BeforeEach и @Nested? Кажется будто некоторые тесты для удобства можно сгруппировать и автоматически создавать для них одно и то же дерево.

С этим согласна, учтем на будущее.

sgrishkova · 2024-04-03T20:57:31Z

lib/src/test/kotlin/treesTests/AVLTreeTest.kt

+        val actualValue = tree.find(2)
+        assertEquals(expectedValue, actualValue)
+    }
+


Еще можно отдельными тестами проверить:

insert на пустом дереве

при вставке нод с меньшим ключём уходит влево

при вставке нод с большим ключём уходит вправо

У нас есть тесты, проверяющие insert и любой случай (вправо/влево/перезапись). Иначе бы и соответствующего покрытия не было. Выносить еще какие-то тесты было бы излишним.

Я вижу, что у вас это проверяется, но если судить тесты только по названию, то insert node and perform left-right rotation будто проверяет только то, что узел куда-то вставляется, а потом совершается поворот.

То есть, если что-то пойдет не так, и тест завершится с ошибкой, первая мысль будет проверять повороты, хотя проблема может крыться в другом.

Если вы еще раз посмотрите на реализацию, то увидите, что повороты вызываются исключительно внутри balance(). Так что я не вижу проблему.

sgrishkova · 2024-04-03T21:08:05Z

lib/src/test/kotlin/treesTests/AVLTreeTest.kt

+        val actualKeysAndHeights = tree.preorderTraverse()
+        assertEquals(expectedKeysAndHeights, actualKeysAndHeights)
+    }
+}


Много тестов на повороты, но кажется будто стоит отдельно проверить, получилось ли дерево в итоге (после вставки / удаления) сбалансированным. Правильно выполненный поворот еще не гарантирует сбалансированность (вдруг что-то было пропущено и дерево осталось несбалансированным).

Метод preorderTraverse() организован таким образом, что по возвращенному из него списку можно однозначно восстановить расположение узлов в дереве, а следовательно и его полную структуру. В наших тестах мы в качестве expectedKeysAndHeights подаем список вершин и их высот, который вернулся бы из preorderTraverse() в случае корректной работы - сбалансированного дерева как результат (то есть, когда все дети в правильных местах, а в случае АВЛ и РБ еще и соблюдены правила балансировки). Поэтому сравнить фактический список, пришедший из метода, с составленным вручную, достаточно, чтобы утверждать корректность не только узлов дерева, но и его структуры. Тестов на повороты не много, они покрывают каждый из 4 кейсов в методе balance.

"Много" имела в виду в хорошем смысле, что рассмотрены не отдельные кейсы, а все.

Насчет сбланасированности согласна, придирка скорее к описанию тестов.
insert node and perform left-right rotation будто проверяет только поворот, а не баланс в целом. Да, по полученному списку можно проверить и сбалансированность, но будто это что-то косвенное. То есть если тест зафейлится, не будет сразу понятно, что пошло не так: поворот не сработал, или балансируется дерево не полностью.

Кажется будто это может отнять лишнее время при дебаге (особенно если человек потеинцально не знаком с кодом).

Опять-таки, это не что-то косвенное, так как повороты нужны только в балансировке. А если тест упадет, то найти ошибку поможет как раз actualKeysAndHeights. Конечно, мы напрямую не узнаем, в каком именно она методе, так как мы их не можем вызвать напрямую (они же не public). Но наш вывод служит хорошей подсказкой.

Справедливо.

sgrishkova · 2024-04-04T06:24:14Z

lib/src/main/kotlin/trees/abstractTree.kt

+    fun find(key: K): V? {
+        return findNodeByKey(key)?.value
+    }


Кажется будто название этого метода можно уточнить. По принимаемым аргументам и по ридми понятно, что осуществляется поиск по ключу, но в теории искать можно и по value.

Вся функциональность метода описана в ридми, и мы предполагаем, что пользователь прочитает его перед использованием библиотеки. Вообще, поиск узла по значению -- немного странное действие, учитывая, что в нашем дереве мы работаем исключительно по ключам, а значения там появляются только в контексте ввода/вывода. Реализация поиска по значению напоминала бы простой обход, что в принципе ломает концепцию дерева как эффективной структуры хранения/взаимодействия с упорядоченными данными. Как дополнительную фичу такой поиск, конечно, можно было бы реализовать, но точно не как основной метод

D31IRIUM

Круто (итератор не оч)

D31IRIUM · 2024-04-04T08:56:29Z

lib/src/main/kotlin/trees/RBTree.kt

+    private fun getGrandparent(node: RBNode<K, V>): RBNode<K, V>? {
+        val parent = findParent(node) ?: return null
+        val grandparent = findParent(parent)
+        return grandparent
+    }
+
+    private fun getSibling(node: RBNode<K, V>): RBNode<K, V>? {
+        val parent = findParent(node) ?: return null
+        return if (node == parent.leftChild) {
+            parent.rightChild
+        } else {
+            parent.leftChild
+        }
+    }
+
+    private fun getUncle(node: RBNode<K, V>): RBNode<K, V>? {
+        val parent = findParent(node) ?: return null
+        val grandparent = findParent(parent)
+        return if (parent == grandparent?.leftChild) {
+            grandparent.rightChild
+        } else {
+            grandparent?.leftChild
+        }
+    }


Каждый раз идти от корня дерева в поиске родителя нода?
В балансировке после ставки это повышает асимптотику до O(log n * log n), в теории и в балансировке после удаления тоже.

Зачем по два раза искать родителя в getGrandparent и getUncle? Переиспользование методов это прикольно, но тут ноды совсем уж рядом расположены.

Использовать или не использовать ссылку на родителя было опциональным решением. В нашем случае, выбранная стратегия позволила повысить переиспользуемость кода (например, поворотов) и уменьшить вероятность ошибок, связанных с кривой привязкой родителя.

D31IRIUM · 2024-04-04T09:14:44Z

lib/src/main/kotlin/trees/RBTree.kt

+    fun preorderTraverse(): List<Pair<K, Color>> {
+        val listOfNodes = mutableListOf<RBNode<K, V>>()
+        traverse(root, listOfNodes)
+        val listOfKeysAndColors = mutableListOf<Pair<K, Color>>()
+        listOfNodes.forEach { listOfKeysAndColors.add(Pair(it.key, it.color)) }
+        return listOfKeysAndColors
+    }
+}


Кому нужен такой итератор, тестерам? А ой, действительно нужен...(´･ᴗ･`)
Если серьёзно, то возникает куча вопросов: почему возвращает не значение нодов, но цвет(что пользователю делать с ним?), почему итератор сделан так, а не с помощью интерфейса Iterator, например, почему preorder, а не сортированный по возрастанию ключей inorder, или вообще 3 разных метода под все order'ы?
Это даже итератором можно назвать с натяжкой, потому что массив пар - не итератор(впрочем, уже по этому массиву действительно можно итерироваться).

Начнем с того, что слова "итератор" ни в коде, ни в презентации нашей архитектуры, ни в требованиях к реализации библиотеки не было. Цитата из условия задания: "Также необходимо поддержать возможность итерирования по ключам и значениям, хранящимся в дереве, например, в порядке обхода в ширину или глубину (или как-то ещё иначе)". Мы были вольны выбрать любой вариант, писать свой метод или реализовывать итератор. Наш вариант реализует (упомянутый в условии) обход в глубину и описан в README довольно понятно, да и примеры приведены. Идея такого вывода пришла мне, поэтому поясню: так как библиотекой пользуются программисты, показалось, что им могут быть полезны такие сведения о структуре дерева, в том числе и цвет (в АВЛ с той же целью присутствует высота, для простого и понятного представления дерева); мы не преследовали цель как-то упростить себе тестирование, но впоследствии оказалось и правда удобно использовать обход. Выбор именно preorder и отсутствие вывода значений я уже прокомментировала вашей сокоманднице.

Я правильно понимаю, что чтобы пройти все узлы дерева(и достать значения), нужно доставать каждый ключ из preorderTraversal, затем с помощью find находить соответствующий value?

Если вопрос в том, как доставать соответствующие ключам значения, то мы уже выяснили, что наша реализация не поддерживает этого в методе preorderTraverse, просто из-за излишней нагроможденности. Пользователь может вывести конкретное значение с помощью find, и мы посчитали это достаточным. Прикрепляю скрин, почему нам не очень импонирует идея выводить значения.

D31IRIUM · 2024-04-04T09:22:53Z

lib/src/main/kotlin/trees/RBTree.kt

+    private fun deleteCase1(node: RBNode<K, V>) {
+        val parent = findParent(node)
+        if(parent != null) deleteCase2(node)
+    }
+


Да, я тоже респектую автору страницы про rb на вики, но ссылочку можно было и оставить в readme, раз код скопирован чуть менее чем полностью.
Это же относиться к балансировке после вставки.

Насколько я знаю, технология не является запатентованной или лицензированной, и указания авторства не требует. Более того, RB-дерево -- довольно популярная и много раз написанная-переписанная идея. А страница на вики есть и, например, у сортировки пузырьком :))

Вообще, случаи, когда-куда-что вставлять, поворачивать и перекрашивать -- это вопрос не конкретной реализации, а устройства красно-черного дерева. Вопрос, как конкретно -- это уже реализация. Код все равно получается разный, и если вы руководствовались другой статьей, поясняющей работу КЧ, то это ваш выбор. delete() разделен на кейсы, возможно, из-за сильной громоздкости, хотя у меня есть свои причины против этого подхода.

При чём тут технологии? Речь про код.
delete() разделён на кейсы не из-за сильной громоздкости, а потому что код в википедии разделён на кейсы.

все еще не понимаю суть проблемы. красно-черное дерево написано задолго до нас, изобретать велосипед не было смысла изначально (и вряд ли бы получилось. учитывая количество реализаций, не знаю, как надо было извернуться, чтобы не быть ни на кого похожим. а главное, зачем). по поводу ссылки все было сказано выше. BTW чекните ссылки в about the project ридми, которые были там изначально ;))
жду появления в репо второй домашки первого сема ссылки на используемую сортировку, кстати :)

Ладно, закрываю тред с позором. ╥﹏╥
Просто мне казалось(и, если честно, до сих пор кажется), что если можно копировать реализацию методов с сайтов, то это ничем не отличается от "списывания" у других людей. Whatever
А вот касательно ссылок - тут я знатно опростоволосился и не заметил их(хотя и похоже на то, что вдохновение принесла как раз русская страничка в википедии, а не англицкая). Всё, пойду проветривать помещение

на лекции как-то раз объясняли, что, на наше же благо, патентованием алгоритмов занимаются только в очень сложных случаях, когда речь идет о, зачастую, огромной коммерческой выгоде и/или сложности патентуемого алгоритма. когда речь идет о предмете вроде красно-черного дерева, это все равно, что попытаться присвоить себе слово "окно" и заявлять, что никто больше не имеет права им пользоваться. пойду, кстати, тоже открою

D31IRIUM · 2024-04-04T09:30:10Z

lib/src/main/kotlin/trees/RBTree.kt

+        /* case 1: insertedNode is root */
+        if (root == insertedNode) {
+            insertedNode.color = Color.BLACK
+            return
+        }


Почему для удаления выделены отдельные методы(removeCase1,2,3,...), а в балансировке после добавления тут всё в одном методе?

В удалении кейсы решили вынести в отдельные методы просто для читаемости, потому что там код намного массивнее, чем во вставке. С заботой о ваших глазках :3

D31IRIUM · 2024-04-04T09:36:38Z

lib/src/main/kotlin/trees/RBTree.kt

+        val uncle = getUncle(insertedNode)
+        val grandparent = getGrandparent(insertedNode) ?: throw IllegalArgumentException("Every node by that point should have grandparent")


grandparent же буквально указывает на uncle, его найти - вопрос одного if else(´。＿。｀)
Но выглядит доходчиво и понятно, этого не отнять.

D31IRIUM · 2024-04-04T09:40:14Z

lib/src/main/kotlin/trees/RBTree.kt

+import nodes.Color
+import nodes.RBNode
+
+class RBTree<K : Comparable<K>, V>: balancedTree<K, V, RBNode<K, V>>() {


Форматирование хромает, какие-то методы отделены друг от друга, какие-то - нет, также внутри методов тоже есть мелочи аля разное написание if else.

D31IRIUM · 2024-04-04T10:14:25Z

lib/src/main/kotlin/trees/RBTree.kt

+    private fun deleteLeaf(node: RBNode<K, V>) {
+        if (node.color != Color.RED) deleteCase1(node)
+    }


Используется один раз + название deleteLeaf... стоит ли говорить, что листовые узлы здесь, тащемта, null.
Да, докопался, а кому сейчас легко?

D31IRIUM · 2024-04-04T10:24:20Z

lib/src/test/kotlin/treesTests/RBTreeTest.kt

+import kotlin.test.Test
+
+
+class RBTreeTest {


Jacoco показывает покрытие 72% веток.
Это следствие распыления балансировки после удаления на много разных методов, но всё равно неприятно. Впрочем, если отмести все ветки с exceptions, нарушающие инварианты rb, то покрытие уже неплохое.

У меня 76%, так что мы в эпсилон-окрестности крутого покрытия

Неполное покрытие некоторых веток в основном связано с большим количеством исключений в реализации КЧ-дерева, их тестами не получится покрыть, а также с проверкой вершин на null (проверяем, является ли вершина null, и если нет, то она по умолчанию имеет чёрный цвет), но ведь в КЧ-дереве null вершины (leaf) и так являютя чёрными... упс! Этого можно было бы избежать, сделав отдельный класс для leaf-вершин, чтобы он всегда был чёрный, но мы решили этого не делать. ну типа KISS и все такое, покрытие в любом случае вышло приемлемое. Спасибо за вклад, Дамир!

D31IRIUM · 2024-04-04T10:26:36Z

lib/src/test/kotlin/treesTests/RBTreeTest.kt

+    /* case 4: uncle is black, parent is red; grandparent, parent and node form a "triangle"
+    *    G                        G
+    *   /                          \
+    *  P    - left triangle         P   - right triangle
+    *   \                          /
+    *    N                        N
+    *
+    */


Схемы прикольные, я когда их увидел здесь, быстренько себе парочку подобных нарисовал :)

homka122 · 2024-04-04T21:19:43Z

не увидел нигде никакой духоты

отсутствие хоть какого-либо интереса к решению и беззубый ответ был бы намного оскорбительнее и удручающее, чем то, что я увидел

я увидел интерес человека узнать больше про ваше решение, задать интересующие вопросы и высказать мысли о том, что ему показалось чем-то необычным

не без заблуждений или ошибок — но мы все учимся

я всегда был бы только рад увидеть подобный интерес к своей работе и получение такого фидбека (миша, твой фидбек мне очень нравится)

@DronShock кто у нас душит кого?

n03d3n · 2024-04-04T21:42:44Z

Тут была паста, которую попросили убрать

homka122 · 2024-04-04T21:48:18Z

@DronShock андрей...

D31IRIUM · 2024-04-05T09:50:19Z

В интернете опять кто-то неправ :O
Есть такая особенность, что моё дерево фидбека вышло очень несбалансированным - критики много, а из хорошего почти ничего освещено не было. Это действительно оч неприятно, когда стараешься над какой-то мелочью, а её принимают как нечто само собой разумеющееся, замечая только негативные аспекты, тем самым принижая твои заслуги.
Ну так вотб, мне действительно очень понравились тесты! Я примерно за день до ревью мельком посмотрел на ваши тесты и ужаснулся - насколько же громозко, непонятно и куце выглядели(а некоторые отдельные и до сих пор выглядят) мои. Мало того, что взамен моих миллионов ассёртов на каждый тест вы очень элегантно обходите дерево с помощью preorderTraverse, так ещё и проверяете все инварианты - ключ и, в случае RB, цвет узла. Поэтому-то про тесты я ничего плохого не написал, больно уж классные они :)
Соня вообще молодец, что взялась за красно-чёрные деревья(я вот больше их трогать не хочу), поэтому надеюсь, что моё ревью ни она, ни пятая команда в целом не восприняли слишком близко к сердцу. PEACE(๑ت๑)ﾉ

Apply final fixes in AVL

… too many stack frames (bad practice)

Beautify RBTree's and RBTest's code

Perform a post-review refactoring that contains optimization of BSTree tests by using BeforeEach and refactoring of abstractions (abstract tree, balanced tree, abstract node) to fit them into Kotlin coding conventions

Update .gitignore

Delete unnecessary for user files

Some of comments and exceptions messages were changed same as one variable name (rightSubtree). Unnecessary "when" constructions were replaced by "if" conditions

Remove table of contents, add general info about installing lib

…on of test code achieved through designing the test part of the lib similar to the main one

Full post-review change of tests architecture. Optimization of test code achieved through designing the test part of the lib similar to the main one

github-classroom bot and others added 30 commits March 18, 2024 06:42

Setting up GitHub Classroom Feedback

a2660e0

Create LICENSE

90aca06

feat: create project with gradle

7acaadf

Merge pull request #2 from spbu-coding-2023/dev-Ksenia

7ec4502

Initialize project

feat: implement abstract node and abstract tree

d3a9c1a

Merge pull request #3 from spbu-coding-2023/dev-Ksenia

0e6b28d

Implement abstractions

feat: implement AVL node

2b324f6

feat: implement balanced tree class with rotation methods

c62e07f

Merge pull request #4 from spbu-coding-2023/dev-Ksenia

494610a

Implement balanced tree class

Merge remote-tracking branch 'origin/main' into dev-SoniaK

1065532

feat: implement AVL tree and override methods(insert and delete); imp…

27060f4

…lement private methods for balancing

feat(AVL): implement balancing methods for the tree

137c15b

feat(BST): implement binary search tree and its node

e7f81ec

fix(abstractNode): change key from var to val

373f581

feat(abstractTree): add traverse method into abstractTree class

9279abe

Merge pull request #5 from spbu-coding-2023/dev-Ksenia

3f48c93

Implement BST and traverse method; Refactor abstractNode

fix(AVL&balancedTree): implement 1 balance method instead of 2

e8080f2

Merge pull request #6 from spbu-coding-2023/dev-SoniaK

fcb8027

Implement 1 balance method instead of 2

feat(RBT): implement node of red_black tree

f58d47c

feat(RBT): : implementred-black tree and his methods getUncle, getSib…

9038eed

…ling and get grandParent

fix(abstractTree): make findMinNodeInRight and findNodeByKey protecte…

afc796d

…d instead of private

fix(AVL): refactor delete method for different cases (no/1/2 children)

4d16b45

Merge pull request #7 from spbu-coding-2023/dev-SoniaS

5eb8779

Implement red-black node class and red-black tree class

fix(abstractTree): change return values in deleteNode

12bd2ea

feat(AVL): implement preorderTraverse

a0b03cd

Merge pull request #8 from spbu-coding-2023/dev-SoniaK

b379eec

Apply fixes in AVLTree and abstractTree

feat(CI): add first version of CI via GitHub actions

d8cd6f8

feat(CI): add build check to CI

844b7cf

feat(CI): add autotests run to CI

9212f82

feat(CI): add jacoco plugin for test coverage control

12323d3

shvorobsofia and others added 4 commits March 31, 2024 11:02

Merge pull request #17 from spbu-coding-2023/dev-SoniaS

31b3784

Implement tests for a reb-black tree

fix(BST): change packages configuration in BSTreeTest for uniformity

34428f2

fix(BST): add exception, the need for which was identified during tes…

7531012

…t coverage analysis

Implement BSTree tests

f00a0ea

Implement pack of tests for BST and do refactoring (add exception for null parent of non-root node)

sgrishkova reviewed Apr 4, 2024

View reviewed changes

D31IRIUM reviewed Apr 4, 2024

View reviewed changes

sofyak0zyreva and others added 20 commits April 7, 2024 10:38

fix(AVLTest): beautify the code, add @beforeeach

0366900

fix(AVL): reformat the code

79eacc0

Merge pull request #18 from spbu-coding-2023/dev-SoniaK

3b91509

Apply final fixes in AVL

fix(RBT): remove separate cases for balanceAfterDelete as they create…

8ecfeff

… too many stack frames (bad practice)

fix(RBT): fix code formatting

97a20de

fix(RBTreeTest): beautify the code, add @beforeeach

ed22015

Merge pull request #19 from spbu-coding-2023/dev-SoniaS

cdd6a72

Beautify RBTree's and RBTest's code

fix(Abstractions): refactor code to fit it in kotlin coding conventions

5aeb6e6

fix(BSTreeTest): optimize test code by using BeforeEach

002bed3

Perform a post-review refactoring

ff95940

Perform a post-review refactoring that contains optimization of BSTree tests by using BeforeEach and refactoring of abstractions (abstract tree, balanced tree, abstract node) to fit them into Kotlin coding conventions

fix: add files to .gitignore

0320520

Merge pull request #21 from spbu-coding-2023/dev-SoniaK

8e1a5f7

Update .gitignore

fix(configuration): delete .idea files from project

6a57f50

Delete .idea files

659a2ab

Delete unnecessary for user files

fix(AbstractTree): change unnecessary "when"-s to "if"-s

786e7a9

fix(AbstractTree): small change of comments and exceptions messages

f4eb2a9

Beautify AbstractTree class

7266f7b

Some of comments and exceptions messages were changed same as one variable name (rightSubtree). Unnecessary "when" constructions were replaced by "if" conditions

Update README.md

3be9606

Remove table of contents, add general info about installing lib

fix(tests): full post-review change of tests architecture. Optimizati…

96510da

…on of test code achieved through designing the test part of the lib similar to the main one

Change the tests arch

91d7ef3

Full post-review change of tests architecture. Optimization of test code achieved through designing the test part of the lib similar to the main one

		@@ -0,0 +1,6 @@
		package nodes

		abstract class abstractNode<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>(val key:K, var value: V) {


		import nodes.abstractNode

		abstract class abstractTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>> {

		var leftChild: someNode? = null
		var rightChild: someNode? = null


		import nodes.abstractNode

		abstract class balancedTree<K: Comparable<K>, V, someNode: abstractNode<K, V, someNode>>: abstractTree<K, V, someNode>() {

		import org.junit.jupiter.api.Assertions.assertEquals
		import kotlin.test.Test

		val uncle = getUncle(insertedNode)
		val grandparent = getGrandparent(insertedNode) ?: throw IllegalArgumentException("Every node by that point should have grandparent")

Conversation

github-classroom bot commented Mar 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sgrishkova left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrishkova Apr 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrishkova Apr 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrishkova Apr 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrishkova Apr 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

D31IRIUM left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shvorobsofia Apr 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

github-classroom bot commented Mar 18, 2024 •

edited

Loading

sgrishkova Apr 3, 2024 •

edited

Loading

sgrishkova Apr 3, 2024 •

edited

Loading

sgrishkova Apr 3, 2024 •

edited

Loading

sgrishkova Apr 4, 2024 •

edited

Loading

D31IRIUM left a comment •

edited

Loading

shvorobsofia Apr 4, 2024 •

edited

Loading

shvorobsofia Apr 4, 2024 •

edited

Loading