Сообщение от moka
А я и не ставлю ===, где ты видешь подобное?
И сортированный массив ты вообще от куда вытащил?
Dictionary и Hashset и Object (js) объеденяет одно - возможность доступа к элементу по key'ю. И на этой основе я их объеденил, т.к. для решения задачи построения временного индекса - нужно именно это свойство.
|
Вот ты написал с ===:
|
Временный индекс === hashset === dict...
|
У hashseta (который в C#, ведь ссылка на so ты дал именно на вопрос про C#) нет доступа по ключу (key), ты пробалаболился в очередной раз.
Hashset в C# не хранит данные как ассоциативный массив.
Для решения задачи быстрого поиска по данным в IN не нужен ассоциативный массив, не нужен там доступ по ключу (выделю шрифтом побольше чтобы ты заметил)
Повторю еще раз - массив просто сортируется, и все.
Это не hashset.
Это не dictionary.
Это не object из js.
Это просто отсортированный массив.
Разница при этом большая - ведь объем памяти остается точно такой же как если бы массив и не сортировался бы (то есть разницы в объеме памяти между вариантом с "временным индексом (c) moka" и без него нету никакой).
В то время как ты сказал что "индексы обычно легковесные" (несколько постов назад). Тем самым ты дезинформировал всех кто прочитал твой пост, ведь объем памяти данных которые были в IN при так называемой "индексации (с) moka" не изменится (а возможно даже станет меньше, если есть повторения), что прямо противоречит тому что ты сказал про легковесные индексы.
|
Да и ты тут сморозил тоже: "по которому поиск быстрый (ведь данные то отсортированы)", ну вообще-то hashset это не отсортированные данные, а используется hash репрезентация элемента как key для прямого доступа к элементу. Читай тут: http://stackoverflow.com/questions/4...t-is-a-hashset
|
Я выше написал что такое hashset.
Нет никакого "прямого доступа".
Hashset просто хранит вместо отсортированных данных, отсортированные хэши этих данных
То есть не SORT (["apple", "google", "banana"]), а SORT ([ HASH("apple"), HASH("google"), HASH("banana) ]).
Зачем так ? Да для того чтобы быстрее искать. Если у тебя массив чисел ([1,5,3]) то hashset будет работать также быстро как и если бы ты искал по отсортированному массиву. Но вот если у тебя массив строк, то будет оптимальнее хранить хэши этих строк, ведь:
1. Меньше памяти на хранение
2. Сравнение 2 хэшей скорее всего быстрее, ведь например если хэш это число (int32) то сравнение 2 чисел это 3 процессорных инструкции (то есть быстро), а вот каждый раз строки сравнивать это медленно.
Понятно ? Или еще в каком то моменте подробнее объяснить надо ?
--------
В данной ситуации мы "общаемся" на форуме, и если ты прямо озвучил утверждение которое было ложным/не корректным, то я могу свободно указать тебе на это, приведя аргументы/доводы (что я и сделал).
Ну и наконец ты так и не ответил про Big o notation. Ты же очень умный и опыта у тебя дохера, так ответь же мне ничего не понимающему любящему поспорить человеку на 3 вопроса (для такого гуру как ты это не составит никакого труда):
Какова "сложность" алгоритма который пробегает весь объем данных 2 раза (всегда)?
Какова "сложность" алгоритма который пробегает весь объем данных 10 раз (всегда)?
Равны ли "сложности" этих алгоритмов и если нет, то какой "сложнее" ?