@gsomix, смущает дублирование семантики - index это как мы знаем тоже key. @fillpackart > Операции поиска по чему угодно - не больше O(log n) (в этом вся соль). > Но за это платим долгой инициализацией/добавлением/удалением Ну вот видишь, это всё подтверждает тезис, который я выше озвучил. sortedmap, dictionary: сложность поиска не больше O(log N), но вставка/удаление - опять таки O(log n), а не O (N), как в sorted list. Если нужно оптимизировать поиск и можно забить на вставку удаление, то какие преимущества у sortedlist ты видишь перед dictionary, у которой поиск и вовсе O(1) ? > byKey и byIndex - они имеют разный смысл стесняюсь спросить, а зачем byKey, когда есть byIndex ?

это как я в dictionnary по value буду искать не за On?

это как я в dictionnary по value буду искать не за On?

спасибо, мы свяжемся с вами позже (с)

На самом деле кейс интересный

стесняюсь спросить, а зачем byKey, когда есть byIndex ? у меня есть список объектов, которые являются командами. Я хочу добавлять их в коллекцию по ключу "commandName" будут кейсы, когда мне нужна будет команда сключом "-start", и будут кейсы, когда мне нужна третья по порядку команда [2]

Надо смотреть, как внутри словаря хранятся значения

@gsomix, смущает дублирование семантики - index это как мы знаем тоже key. @fillpackart > Операции поиска по чему угодно - не больше O(log n) (в этом вся соль). > Но за это платим долгой инициализацией/добавлением/удалением Ну вот видишь, это всё подтверждает тезис, который я выше озвучил. sortedmap, dictionary: сложность поиска не больше O(log N), но вставка/удаление - опять таки O(log n), а не O (N), как в sorted list. Если нужно оптимизировать поиск и можно забить на вставку удаление, то какие преимущества у sortedlist ты видишь перед dictionary, у которой поиск и вовсе O(1) ? > byKey и byIndex - они имеют разный смысл стесняюсь спросить, а зачем byKey, когда есть byIndex ?

Меня, пожалуй, только by key немного смущает. Потому что обращение по индексу может быть полезно, например, если я захочу быстро медиану считать. :)

Надо смотреть, как внутри словаря хранятся значения

SortedList — массивы SortedDictionary — дерево

Меня, пожалуй, только by key немного смущает. Потому что обращение по индексу может быть полезно, например, если я захочу быстро медиану считать. :)

чем тогда тебе массив не нравится?

спасибо, мы свяжемся с вами позже (с)

очевидно, что мне нужно не value, а его позиция

Если массивы, то поиск по значению действительно O(n)

чем тогда тебе массив не нравится?

Тем, что он не sorted.

или я не понимаю какой-то магии

очевидно, что мне нужно не value, а его позиция

верней Key

спасибо, мы свяжемся с вами позже (с)

да, и оставь своё высокомерие для своих соискателей

да, и оставь своё высокомерие для своих соискателей

+

Тем, что он не sorted.

Думаю, чаще хочется более простую структуру, не key-value, а просто отсортированный список значений. С индексацией.

Тем, что он не sorted.

так отсортируй, или добавляй с сохраннием порядка. в чём проблема то?)

Думаю, чаще хочется более простую структуру, не key-value, а просто отсортированный список значений. С индексацией.

я именно об об этом, бинго) вопрос в том нафига фообще sortedlist

так отсортируй, или добавляй с сохраннием порядка. в чём проблема то?)

Нет проблемы. Но клево же, когда все за тебя написали? :)

я именно об об этом, бинго) вопрос в том нафига фообще sortedlist

Ага, я понял. Тем же вопросом задаюсь.

да, и оставь своё высокомерие для своих соискателей

У Павла своеобразная манера общаться. Я подозреваю, что ему просто по-другому сложно.

Возможно, это какая-то экономия на спичках для тех, кому не подходит SortedDictionary, но хочется key-value. > SortedList<TKey, TValue> uses less memory than SortedDictionary<TKey, TValue>. > If the list is populated all at once from sorted data, SortedList<TKey, TValue> is faster than SortedDictionary<TKey, TValue>.

Ну, такое.

Sorted list в гуях полезно

Возможно, это какая-то экономия на спичках для тех, кому не подходит SortedDictionary, но хочется key-value. > SortedList<TKey, TValue> uses less memory than SortedDictionary<TKey, TValue>. > If the list is populated all at once from sorted data, SortedList<TKey, TValue> is faster than SortedDictionary<TKey, TValue>.

О, это мысль!

У Павла своеобразная манера общаться. Я подозреваю, что ему просто по-другому сложно.

Да, давайте жить дружно. ?

У SortedDictionnary есть индексы?

а зачем индексы в b-tree?

Кстати да,справедливый вопрос

т.е. в sortedDictionnary как я получу предыдущий элемент?

за O(logN)

а в SortedList - за O1

Ну зависит от задачи

Если тебе индекс нужен, то лучше SortedList, наверное

т.е. в sortedDictionnary как я получу предыдущий элемент?

Приведи пример.

Приведи пример.

Пример чего?

Пример чего?

Зачем может быть нужно получать предыдущий элемент.

я приводил

стесняюсь спросить, а зачем byKey, когда есть byIndex ? у меня есть список объектов, которые являются командами. Я хочу добавлять их в коллекцию по ключу "commandName" будут кейсы, когда мне нужна будет команда сключом "-start", и будут кейсы, когда мне нужна третья по порядку команда [2]

вот тут

т.е. это типичный кейс, оплачиаем скорость лишней памятью

вот тут

Я все равно не понял кейс про третью команду. :)

Кейс с третьей командой странный, да

Ты не понял, зачем это вообще нужно - получать следующую. Нужно за тем же, зачем и по ключу - из условий задачи

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

Ок, надо просто хорошую задачу придумать.

у меня была такая

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

в каком-то тестовом задании правда, но была

стесняюсь спросить, а зачем byKey, когда есть byIndex ? у меня есть список объектов, которые являются командами. Я хочу добавлять их в коллекцию по ключу "commandName" будут кейсы, когда мне нужна будет команда сключом "-start", и будут кейсы, когда мне нужна третья по порядку команда [2]

А сколько всего команд? сотни тысяч? миллионы?

в том кейсе было около 10)

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

А что здесь сортируется?

у вопросов есть номера

по ним юзер и ходит

в том кейсе было около 10)

тогда чем не устраивает поиск перебором по массиву? это одной корткой инструкцией делается если что

тогда чем не устраивает поиск перебором по массиву? это одной корткой инструкцией делается если что

дак ясно, что это сюда не подходит.

это так, спортивный интерес. Было бы миллионов 20 - тогда да

в любом случае, не очень хорошо искать по On, когда можно O1 или OlogN

в любом случае, не очень хорошо искать по On, когда можно O1 или OlogN

нет

если N мизерный - то по фиг вообще

если N мизерный - то по фиг вообще

если он гарантировано мизерный - да

использование sortedList - не сложней, чем массив, dictionnary или лист,а профит в скорости есть. Why not?

Вообще, конечно, охеренная позиция "чуваки, я не шарю в X, объясните плиз, чтоб я мог называть всех кто не шарит тупыми"

Унизить других за счёт собеседования - бесценно.

Извините

Вы сегодня какие-то агрессивные.

просто структуры данных - очень интимная тема для нас всех

Вы сегодня какие-то агрессивные.

Понедельник

использование sortedList - не сложней, чем массив, dictionnary или лист,а профит в скорости есть. Why not?

профита в скорости нет, уже разобрались благодаря @gsomix . см. выше. есть мизерный профит по памяти в сравнении с sortedmap за счёт адской деградации вставки/удаления. Первоначальный вопрос остаётся - на хрена это всё, где оно реально полезно и зачем кому-то вообще про это знать? допускаю, всякое бывает, может и чёрт с рогами прегодиться. Но в этом случае нормальный человек скорее возьмёт массив и сделает для него индекс в виде хэша или b-tree, чем будет разбираться в каком-то мутном контейнере. Вот ты же не разобрался как вяснилось ?

Унизить других за счёт собеседования - бесценно.

я думал как бы самому не оказаться дураком, а не унизить. если контейнер очевидно нелепый - то как объяснить человеку, почему он обязан его знать?))

профита в скорости нет, уже разобрались благодаря @gsomix . см. выше. есть мизерный профит по памяти в сравнении с sortedmap за счёт адской деградации вставки/удаления. Первоначальный вопрос остаётся - на хрена это всё, где оно реально полезно и зачем кому-то вообще про это знать? допускаю, всякое бывает, может и чёрт с рогами прегодиться. Но в этом случае нормальный человек скорее возьмёт массив и сделает для него индекс в виде хэша или b-tree, чем будет разбираться в каком-то мутном контейнере. Вот ты же не разобрался как вяснилось ?

скорость чего?

System.Containers.Generic.Ridiculous

скорость чего?

вставки - относительно всего, поиска по индексу - относительно массива, поиска по ключу - относительно деревьев

ну. Так все эти коллекции являются комбинациями этих скоростей. Нужно быстро искать по ключу - dictionnary. по индексу - массив. По ключу и по индексу - SortedDictionnary. По ключу, по индексу и по value (получение ключа/индекса объекта) - sortedList. Или я чего-то не понимаю?

https://mobile.twitter.com/dsyme/status/911198651808133121?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fsergeytihon.com%2F2017%2F09%2F24%2Ff-weekly-38-be-on-the-safe-stack-today%2F

В чем тут big step?

Просто создали сайт со ссылками на существующие технологии

Или я чего-то не понял?

ну. Так все эти коллекции являются комбинациями этих скоростей. Нужно быстро искать по ключу - dictionnary. по индексу - массив. По ключу и по индексу - SortedDictionnary. По ключу, по индексу и по value (получение ключа/индекса объекта) - sortedList. Или я чего-то не понимаю?

Это потому,что ты наверное не отравился SQL как я) По ключу и по индексу - не нужно в реальных случаях. трудно придумать такой кейс на практике. Но допустим действительно нужно - "индексировать" массив - это вообще не проблема. А вот изучить контейнер и понять как он работает - это проблема. Ну и ты же понимаешь, что ни кто реально ничего изучать не будет. будут просто тупо говнокодить. А мне потом с этим разбираться))

В чем тут big step?

Коммерческая поддержка.

Это потому,что ты наверное не отравился SQL как я) По ключу и по индексу - не нужно в реальных случаях. трудно придумать такой кейс на практике. Но допустим действительно нужно - "индексировать" массив - это вообще не проблема. А вот изучить контейнер и понять как он работает - это проблема. Ну и ты же понимаешь, что ни кто реально ничего изучать не будет. будут просто тупо говнокодить. А мне потом с этим разбираться))

Не имел дело с SQL, тут ты прав. Но я частенько слышу "какого хера из коробки нет такой-то структуры данных!?!", так что разрабы тут просто перестраховались, тем более что её не долго было сделать. А насчёт того, кто и какие коллекции должен знать - я думаю, соискатель должен обладать пониманием структур данных и принципов оптимизаций, без всякой конкретики дальше dictionnary, list и array

"какого хера из коробки нет такой-то структуры данных!?!" - вот честно, за такие фразы хочется начать бить уже сейчас, а вы говорите "чего агрессивные")) Впрочем, я согласен. В ru-коллективах с вежливостью и корректностью всё ужасно. прошу прощения, если кого-то чем-то обидел

Внезапно нарисовалась интересная задачка: Есть произвольное дерево, у каждого листа есть некоторый вес. Надо разбить дерево на множество деревьев, чтоб сумма весов листьев в каждом дереве не превышала лимит. А потом собрать дерево в первоначальном виде Убрав абстракции: дерево = html-документ листья = текст в параграфах, спанах, дивах, заголовках... вес = длинна текста преобразование = перевот текста с языка на язык у меня постепенно в голове решение проявляется, но может есть какой-то типовой алгоритм?

пока получается, что есть два дерева условно

Я как-то хотел нечто подобное сделать https://github.com/ninjarobot/FSharp.Text.Docker

== разбить дерево на множество деревьев, чтоб сумма весов листьев в каждом дереве не превышала лимит сгруппировать dom-узлы по длине текста или что?

== разбить дерево на множество деревьев, чтоб сумма весов листьев в каждом дереве не превышала лимит сгруппировать dom-узлы по длине текста или что?

типа того, только так, чтоб оригинальное дерево из этих кусков можно было собрать

Коммерческая поддержка.

Прочел и заметку в блоге https://compositional-it.com/blog/2017/09-22-safe-release/index.html. Но нигде не увидел явно о коммерческой поддержке. Из чего это следует?

типа того, только так, чтоб оригинальное дерево из этих кусков можно было собрать

тогда надо обойти хтмл, а в процесе обхода пронумеровать узлы и создать - мапу [номер узла] -> [массив номеров дочерних узлов + то, что тебе надо] - мапу [ссылка на узел DOM] -> [номер узла]. С этими двумя мапами можно делать всё что вздумается, не?

Внезапно нарисовалась интересная задачка: Есть произвольное дерево, у каждого листа есть некоторый вес. Надо разбить дерево на множество деревьев, чтоб сумма весов листьев в каждом дереве не превышала лимит. А потом собрать дерево в первоначальном виде Убрав абстракции: дерево = html-документ листья = текст в параграфах, спанах, дивах, заголовках... вес = длинна текста преобразование = перевот текста с языка на язык у меня постепенно в голове решение проявляется, но может есть какой-то типовой алгоритм?

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

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

не надо этого. текс тоступен через ссылки на DOM элементы, которые доступны через номера узлов

Прочел и заметку в блоге https://compositional-it.com/blog/2017/09-22-safe-release/index.html. Но нигде не увидел явно о коммерческой поддержке. Из чего это следует?

А я них на сайте SAFE обозначены компании, в которые можно обращаться за поддержкой.

Именно. https://safe-stack.github.io/ Смотри последний пункт на сайте

По оброзу и подобию MEAN stack. Это на самом деле большой шаг вперед. Будет годный гайдлайн по созданию веб и мобильных приложений на F# с поддержкой компаний и сообщества.

Смотрю. Заголовок: "куда мне обратиться за помощью". Отмечены 2 компании : Compositional IT, Lambda Factory. Под коммерческой поддержкоя я понимаю, когда компания тратит деньги на развитие проекта, правку багов, предоставляет платную техподдержку и быстрое реагирование на запросы клиентов. Т.е. это нечто большее для меня, чем просто коммерческие компании, использующие и развивающие технологии из стека.

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

Это не какой-то продукт

да, в первую очередь маркетинг

есть вопросы - пишешь этим компаниям, все решается в индивидуальном порядке