Я рекомендую Silent Hill 2 Remake. Смысла сейчас играть в оригинал 2001-го года никакого. Bloober Team сделали отличный ремейк. С автором статьи не соглашусь, с Resident Evil ничего общего. Мне RE вообще нестрашным показался, а вот SH всю игру держит в напряжении.
Более того, SH уникален тем, как пугает. В игре нет скримеров, все новые монстры вводятся в игру без этих дебильных криков и оров, присущих ужастикам и игровым и киношным. Пугает там сама атмосфера, страх того, что притаилось в темноте или за углом. А сюжет однозначно один из самых необычных.
Я с вами соглашусь, но увы, других метрик не нашлось :-( Вообще, было бы очень круто со стороны MS устроить большой опрос по использованию и удовлетворённостью фичами языка. Им бы тоже было полезно: были бы видны потенциальные векторы развития языка.
По такой логике и Go вполне кратко, ёмко и логотипно. Но вообще на ваш вопрос "зачем" ответы будут субъективные и их будет много. Ну вот мне кажется, что даже и такие вещи могут иметь значение – узнаваемый символ. Но могу ошибаться.
А я и не скрываю в статье, что вкусовщина. И шарп я люблю, и переходить на другой язык не желаю. Но всё равно внутри какое-то чувство, что что-то не так... Но повторюсь, я сам нововведения использую. А в разделе про ref подчёркиваю, что это примеры полезных (на мой взгляд) фич.
Полностью с вами согласен. В целом, C# так или иначе присутствует в пятёрке ну или как минимум десятке самых популярных языков. Но да, до уровня того же Python ему далеко. Вы подняли любопытную тему.
Мне кажется, важно ещё то, что сам .NET был очень долго привязан к Windows (хорошо хоть в MS одумались). Да, был Mono, был Xamarin. Но сторонние поделки не так сильно поднимают популярность, как действия со стороны самих разработчиков языка.
Ещё я только что осознал, что у C# нет вменяемого логотипа, там просто многоугольник с надписью C#. У Python две змейки в виде плюса, у Java чашка кофе, у Go милый зверёк, у Rust велосипедная звёздочка на пять болтов. Мелочь, конечно, но тоже может влиять.
И да, тоже ежегодно решаю задачки Advent of Code, использую его как полигон для опробования новых фич языка. Правда, в leaderboard не попадал никогда. Да и вообще, все задачи (обе части) решил только в 2020-м. Я тоже сделал себе набор полезных методов, а C# использовал сразу. В целом, олимпиадные задачки (а AoC всё же больше к ним тяготеет) мне даются непросто. В этом году, думаю, в лидерах будут сплошь LLM-ки.
Не хватает сравнения с VS Code, например (хотя намекают на него, упоминая Electron). Или даже Visual Studio, если мы говорим про C# или C++. Или семейство IDE от JetBrains.
Dropbox спустя чуть больше полугода после публикации статьи (на английском, разумеется) запустил бета-тестирование фичи Ignore Files. Не знаю, в статье дело или нет, но буду верить, что и она повлияла :-)
Ага, уже разобрался. К своему стыду я даже не знал про амортизационную сложность. И таки-да, очень разумная штука. Не зря статью написал, узнал много нового :-)
Как было сказано в статье, API позволяет менять воспроизводимые объекты на лету. Это значит, что пользователь может захотеть изменить, например, силу нажатия (velocity) какой-то ноты. А чтобы отразить это в плейбеке, нужно найти эту ноту во внутренней коллекции (в дереве) и поменять параметры (я делаю сейчас изменение просто: удаляю ноту и добавляю её с новыми данными).
Стоит признать, что вы правы. Спасибо за конструктивное замечание. Я выполнил бенчмарки интересных мне случаев:
вставка в конец коллекции;
удаление с конца, с начала и рандомно.
Да, List выигрывает у LinkedList, если операции выполнить в цикле. Нужно будет подумать, стоит ли переходить на List. Потому что массовые операции происходят только при иницализации дерева (и то, в большинстве случаев изначально дерево пустое будет), а потом уже точечные будут. Замерю на досуге.
знали ли Вы, что современные реализации сортировок используют сортировку вставками, а не квиксорт в некоторых случаях
Нет, я этого не знал. Сейчас прочитал и таки-да, разумно.
Treap-дерево попадалось на глаза, когда изучал научные работы по сбалансированным BST. Но мне запомнилось, что оно в бенчмарках заметно проигрывало AVL и красно-чёрному. Вероятно, коэффициенты при логарифме у treap-дерева больше.
И всё-таки логарифм там обеспечен с высокой вероятностью, но не гарантирован, как у AVL или красно-чёрного. У treap может и O(N) быть в маловероятном случае.
Взятие элемента по индексу за O(1) вы в дереве не сделаете. Только если рядом хранить какой-то массив и держать его в отсортированном состоянии. Но тогда и дерево не нужно.
Говоря о проблемах сравнения, я, разумеется имел в виду логику сравнения, алгоритм. Не реализацию на языке программирования. Закодить-то несложно (если есть алгоритм). Наиболее простым способом будет реализовать IComparable<> на классе-ключе, чтобы не менять код самого дерева.
Но именно логика сравнения является сложной частью головоломки. Во-первых, класс-ключ будет содержать большое число условий и проверок. Во-вторых, проблемы, описанные выше. В третьих, придётся менять и код дерева тоже. Потому что теперь мы не сможем легко и просто взять значения, у которых время равно T. Ибо ключ не равен времени, и нужно заглядывать внутрь ключа.
Как я и писал выше, в теории оно сработает, можно и так сделать. Другое дело, что композитный ключ порождает большое количество вопросов и проблем. А зачем, если можно сделать проще? Разве что в качестве интеллектуального упражнения.
Ну и статья про красно-чёрное дерево, не про SortedSet<>. Почему мне оно не подходит, я в другом комментарии отвечал.
Если вы делаете алгоритм в терминах высот поддеревьев, возможно, вам пригодится AVL-дерево. В нём в качестве balance factor используется разница высот слева и справа. И упаковка дерева плотнее выходит. В красно-чёрном используется "цвет" и не такие жёсткие ограничения на высоту, что даёт чуть более быстрое удаление за счёт меньшего количества вращений.
Я бы с удовольствием почитал статью про реализацию взятия элемента в дереве по индексу за O(1). Я в алгоритмах не особый специалист и всякие хитрые штуки изучить хотелось бы.
Я рекомендую Silent Hill 2 Remake. Смысла сейчас играть в оригинал 2001-го года никакого. Bloober Team сделали отличный ремейк. С автором статьи не соглашусь, с Resident Evil ничего общего. Мне RE вообще нестрашным показался, а вот SH всю игру держит в напряжении.
Более того, SH уникален тем, как пугает. В игре нет скримеров, все новые монстры вводятся в игру без этих дебильных криков и оров, присущих ужастикам и игровым и киношным. Пугает там сама атмосфера, страх того, что притаилось в темноте или за углом. А сюжет однозначно один из самых необычных.
Программно на C# через стандартный System.Drawing.
Я с вами соглашусь, но увы, других метрик не нашлось :-( Вообще, было бы очень круто со стороны MS устроить большой опрос по использованию и удовлетворённостью фичами языка. Им бы тоже было полезно: были бы видны потенциальные векторы развития языка.
По такой логике и Go вполне кратко, ёмко и логотипно. Но вообще на ваш вопрос "зачем" ответы будут субъективные и их будет много. Ну вот мне кажется, что даже и такие вещи могут иметь значение – узнаваемый символ. Но могу ошибаться.
Запрос на такую фичу, оказывается, существует с 2015-го года.
А я и не скрываю в статье, что вкусовщина. И шарп я люблю, и переходить на другой язык не желаю. Но всё равно внутри какое-то чувство, что что-то не так... Но повторюсь, я сам нововведения использую. А в разделе про ref подчёркиваю, что это примеры полезных (на мой взгляд) фич.
Кстати, да :-)
Полностью с вами согласен. В целом, C# так или иначе присутствует в пятёрке ну или как минимум десятке самых популярных языков. Но да, до уровня того же Python ему далеко. Вы подняли любопытную тему.
Мне кажется, важно ещё то, что сам .NET был очень долго привязан к Windows (хорошо хоть в MS одумались). Да, был Mono, был Xamarin. Но сторонние поделки не так сильно поднимают популярность, как действия со стороны самих разработчиков языка.
Ещё я только что осознал, что у C# нет вменяемого логотипа, там просто многоугольник с надписью C#. У Python две змейки в виде плюса, у Java чашка кофе, у Go милый зверёк, у Rust велосипедная звёздочка на пять болтов. Мелочь, конечно, но тоже может влиять.
И да, тоже ежегодно решаю задачки Advent of Code, использую его как полигон для опробования новых фич языка. Правда, в leaderboard не попадал никогда. Да и вообще, все задачи (обе части) решил только в 2020-м. Я тоже сделал себе набор полезных методов, а C# использовал сразу. В целом, олимпиадные задачки (а AoC всё же больше к ним тяготеет) мне даются непросто. В этом году, думаю, в лидерах будут сплошь LLM-ки.
Не хватает сравнения с VS Code, например (хотя намекают на него, упоминая Electron). Или даже Visual Studio, если мы говорим про C# или C++. Или семейство IDE от JetBrains.
Dropbox спустя чуть больше полугода после публикации статьи (на английском, разумеется) запустил бета-тестирование фичи Ignore Files. Не знаю, в статье дело или нет, но буду верить, что и она повлияла :-)
На первый взгляд кажется, что реализация у меня станет сложнее наоборот. Но подход и его плюсы я понял, нужно подумать.
Ага, уже разобрался. К своему стыду я даже не знал про амортизационную сложность. И таки-да, очень разумная штука. Не зря статью написал, узнал много нового :-)
Как было сказано в статье, API позволяет менять воспроизводимые объекты на лету. Это значит, что пользователь может захотеть изменить, например, силу нажатия (velocity) какой-то ноты. А чтобы отразить это в плейбеке, нужно найти эту ноту во внутренней коллекции (в дереве) и поменять параметры (я делаю сейчас изменение просто: удаляю ноту и добавляю её с новыми данными).
Спасибо за полезную информацию про splay-дерево.
Стоит признать, что вы правы. Спасибо за конструктивное замечание. Я выполнил бенчмарки интересных мне случаев:
вставка в конец коллекции;
удаление с конца, с начала и рандомно.
Да,
Listвыигрывает уLinkedList, если операции выполнить в цикле. Нужно будет подумать, стоит ли переходить наList. Потому что массовые операции происходят только при иницализации дерева (и то, в большинстве случаев изначально дерево пустое будет), а потом уже точечные будут. Замерю на досуге.Нет, я этого не знал. Сейчас прочитал и таки-да, разумно.
Treap-дерево попадалось на глаза, когда изучал научные работы по сбалансированным BST. Но мне запомнилось, что оно в бенчмарках заметно проигрывало AVL и красно-чёрному. Вероятно, коэффициенты при логарифме у treap-дерева больше.
И всё-таки логарифм там обеспечен с высокой вероятностью, но не гарантирован, как у AVL или красно-чёрного. У treap может и
O(N)быть в маловероятном случае.Вот я выше тоже про это написал:
Не знал про skip list, спасибо!
Говоря о проблемах сравнения, я, разумеется имел в виду логику сравнения, алгоритм. Не реализацию на языке программирования. Закодить-то несложно (если есть алгоритм). Наиболее простым способом будет реализовать
IComparable<>на классе-ключе, чтобы не менять код самого дерева.Но именно логика сравнения является сложной частью головоломки. Во-первых, класс-ключ будет содержать большое число условий и проверок. Во-вторых, проблемы, описанные выше. В третьих, придётся менять и код дерева тоже. Потому что теперь мы не сможем легко и просто взять значения, у которых время равно
T. Ибо ключ не равен времени, и нужно заглядывать внутрь ключа.Как я и писал выше, в теории оно сработает, можно и так сделать. Другое дело, что композитный ключ порождает большое количество вопросов и проблем. А зачем, если можно сделать проще? Разве что в качестве интеллектуального упражнения.
Ну и статья про красно-чёрное дерево, не про
SortedSet<>. Почему мне оно не подходит, я в другом комментарии отвечал.Если вы делаете алгоритм в терминах высот поддеревьев, возможно, вам пригодится AVL-дерево. В нём в качестве balance factor используется разница высот слева и справа. И упаковка дерева плотнее выходит. В красно-чёрном используется "цвет" и не такие жёсткие ограничения на высоту, что даёт чуть более быстрое удаление за счёт меньшего количества вращений.
Я бы с удовольствием почитал статью про реализацию взятия элемента в дереве по индексу за
O(1). Я в алгоритмах не особый специалист и всякие хитрые штуки изучить хотелось бы.Если вы про
Red-Black Tree Implementation in C#. Нет метода удаления данных. Кроме того, в коде найден баг (см. комментарии).
так ведь нужно перейти по ссылке. Там будет gist, в комментарии к которому найдёте подробное описание: