А, вот оно как. В любом случае, комментарий будет полезен тем, кто случайно заблуждается, что код этого дерева на гитхабе — не говно образец для подражания.
Фотматирование пляшет. Код на гитхабе невозможно читать.
Ещё ооочень много неидеоматического руби-кода. Как уже выше говорили `if node.left != nil` => `unless node.left`, `if node.left == nil` => `if node.left`. Код метода has_one_child_only? можно сократить более чем в два раза, используя xor: `has_left_children? ^ has_right_children?`.
Именования родом из жавы: `heightRight`, `heightLeft`. Также, обычно не пишут методы is_xxx?.. Принято писать xxx?..
Вместе с методом add для добавления в коллекцию новых элементов в руби почти всегда делают метод << (можно как алиас метода add).
Ещё жабьи уши видны в while-условиях со скобочками: `while(true)`.
По дизайну.
Поля root и total_nodes должны быть объявлены через attr_reader, не attr_accessor. Зачем давать пользователю библиотеки менять эти значения?
Опциональный первый параметр в конструкторе дерева не нужен. Странное решение вообще какое-то. Почему одно значение в дерево можно передавать при создании, а не два или не десять? Я не вижу причины.
Методы add и add2 — какая между ними разница? Зачем их два? Неочевидно.
Дерево не балансируется — это тоже верно замечено. Вообще говоря, такие деревья не нужны.
Ещё всякие методы-итераторы (вроде walk) сейчас делают адаптивными в зависимости от того передан ли блок в метод. Если блок передаётся — происходит просто обход дерева, если нет — возвращается Enumerator. Чтобы понятней было о чём я говорю, взгляните на Enumerable.map.
Ну и вообще, то, что walk_* методы возвращают строки — это по меньшей мере странно. На больших объёмах данных это будет вызывать ненужную нагрузку на память, GC и процессор. И потом: неочевидно, что делать, если элементы дерева строки, которые сами содержат запятые. Как потом парсить аутпут walk_* методов?
Но начинание хорошее, продолжайте. Руби несёт в мир добро.
Исправил немного кода на более идеоматичный вариант, смотрите коммиты, если кому интересно.
И, да: нету автоматических тестов совсем. Руби-код, вообще говоря, так не пишут. Можно, конечно, сабмитать решение после каждого изменения на сайт с задачами, но это назвать автоматическим тестированием нельзя никак.
Бесспорно, это так. Я лишь хотел заострить внимание на примитивности реализации квиксорта в дотнете. Когда реализацию быстрой сортировки можно «сломать» таким простым набором данных, это не говорит в пользу этой реализации. Сравните, например, с алгоритмом квиксорта в джаве. Там алгоритм выбора медианы не такой школьный, как в дотнете, и найти класс данных, на которых время сортировки будет квадратичным, горааздо сложнее.
И, кстати, MSDN опять врёт: там сказано «This method is an O(n) operation, where n is Count.»
В случае дырявого хэшсета цикл, который внутри этого метода, будет бежать по всем дыркам подряд, количество которых, вообще говоря, не зависит от n и может быть на порядки больше его.
Совершенно верно. Любое удаление элементов из хэшсета в дотнете не ведёт к сужению таблицы. Для этой цели в классе введён специальный метод TrimExcess().
руссефецировать
не говнообразец для подражания.Ещё ооочень много неидеоматического руби-кода. Как уже выше говорили `if node.left != nil` => `unless node.left`, `if node.left == nil` => `if node.left`. Код метода has_one_child_only? можно сократить более чем в два раза, используя xor: `has_left_children? ^ has_right_children?`.
Именования родом из жавы: `heightRight`, `heightLeft`. Также, обычно не пишут методы is_xxx?.. Принято писать xxx?..
Вместе с методом add для добавления в коллекцию новых элементов в руби почти всегда делают метод << (можно как алиас метода add).
Ещё жабьи уши видны в while-условиях со скобочками: `while(true)`.
По дизайну.
Поля root и total_nodes должны быть объявлены через attr_reader, не attr_accessor. Зачем давать пользователю библиотеки менять эти значения?
Опциональный первый параметр в конструкторе дерева не нужен. Странное решение вообще какое-то. Почему одно значение в дерево можно передавать при создании, а не два или не десять? Я не вижу причины.
Методы add и add2 — какая между ними разница? Зачем их два? Неочевидно.
Дерево не балансируется — это тоже верно замечено. Вообще говоря, такие деревья не нужны.
Ещё всякие методы-итераторы (вроде walk) сейчас делают адаптивными в зависимости от того передан ли блок в метод. Если блок передаётся — происходит просто обход дерева, если нет — возвращается Enumerator. Чтобы понятней было о чём я говорю, взгляните на Enumerable.map.
Ну и вообще, то, что walk_* методы возвращают строки — это по меньшей мере странно. На больших объёмах данных это будет вызывать ненужную нагрузку на память, GC и процессор. И потом: неочевидно, что делать, если элементы дерева строки, которые сами содержат запятые. Как потом парсить аутпут walk_* методов?
Но начинание хорошее, продолжайте. Руби несёт в мир добро.
И, да: нету автоматических тестов совсем. Руби-код, вообще говоря, так не пишут. Можно, конечно, сабмитать решение после каждого изменения на сайт с задачами, но это назвать автоматическим тестированием нельзя никак.
А затея хорошая, поддерживаю.
В случае дырявого хэшсета цикл, который внутри этого метода, будет бежать по всем дыркам подряд, количество которых, вообще говоря, не зависит от n и может быть на порядки больше его.