В контекстной рекламе никто не будет мешать несмешиваемое, поэтому тут подход имеет место быть. Например, свежую зелень будут продавать вместе со свежими овощами
А расскажите подробнее, вот я хочу обрабатывать словарь (текстовый файл размером около 2 ГБ), поможет в этом R?
Искать и находить в нем по ключам от 1 до 200.000 значений одновременно, и возвращать для каждого ключа значения.
на данных в 200 тыс строк 50 сек вместо 45), что не критично, зато поддерживает целостность данных.
это если делать немного поисков.
А если нужно одновременно в массиве из 1 млн значений найти другие 60.000 — это совершенно другая история. тут нужна сортировка и бинарный.
зависимость от структуры при желании легко обойти. помимо ВПР есть ГПР — всегда можно ссылаться не на номер столбца, а на индекс его заголовка.
В других случаях можно просто ссылаться на индекс нужного столбца через подсчет ширины массива — при добавлении столбцов будет смещаться и индекс.
Речь вообще идет о феномене бинарного поиска, а не о функциях — индекс или ВПР. И та и та функция умеют искать бинарным поиском по сортированному массиву.
ПОИСКПОЗ тоже бывает бинарный, принимает последний аргумент 1 и -1 для сортировки а-я и я-а соответствено.
Поэтому совмещение ВПР и Индекс-ПОИСКПОЗ дает убер-решение, которое такое же быстрое, но в то же время не обладает недостатками ВПР. В статье выше об этом тоже ведется речь, даже выложен пример функции. UDF тоже напишу, попозже, опубликую, если до меня кто-нибудь не опубликует :)
Статья:
http://analystcave.com/excel-vlookup-vs-index-match-vs-sql-performance/
апдейт кода выложил, но вышеописанное поведение (скриншот) — корректное при бинарном поиске, поэтому там ничего не корректировалось. И в целом если корректировать, это ухудшит производительность.
кому как)
первые два пункта — трудно представить как нечто непреодолимое.
последний в моих проектах не актуален (ключи уникальны), и непонятно, как вопрос с неопределенностью решают другие алгоритмы.
Несколько условий — целый отдельный кейс реализации.
по 1-му пункту — так и было задумано, если хотите свой вариант — вполне можете переработать код под ваши нужды. По мне это предложение уже чересчур кастомное.
по 2-му — тут интереснее, так не было задумано, буду фиксить вместе с первым параметром, который не принимает вручную добавленные или вычисляемые строки (что хотелось бы и мне в том числе). Апдейт кода выложу.
Решение выглядело бы как последовательная сортировка каждого из критериев, справа налево, затем конкатенация, затем тот же бинарный поиск с выводом значения. Это возможно, если сортировка не мешает.
Думаю, решения должны быть, если нет, можно задуматься о реализации.
продумывал этот вариант, поскольку стажа программирования практически нет, еще не разобрался, даст ли прирост в моем кейсе.
+ критичным является не оптимизация объема занимаемой памяти, а оптимизация процессорного времени.
Массивы в моих задачах большие, но не настолько большие, чтобы не хватило памяти.
аналогично при бинарном поиске, искомое может быть найдено как на 1-й, так и на 20-й итерации. На бесконечном количестве поисков среднее время поиска будет 10 итераций.
Нет, речь о чисто математическом расчете, если не учитывать никакие внешние факторы (многопоточность, обслуживание функции, запись в файл и т.д.).
Если массив 2^20 строк и все поиски разнородные, то при стремлении количества поисков к бесконечности среднее количество операций на один поиск стремится к числу, равному половине массива. Т.к. экстремумы — 1 и 2^20 (искомое может быть как в первой, так и в последней строке), среднее на большом количестве где-то посередине, т.е. 2^10, или ~500.000
Меня искренне волнует, почему нейросети Яндекса не справляются с запросом "гол задницей", "гол задницей видео", а гугл отрабатывает наура
Искать и находить в нем по ключам от 1 до 200.000 значений одновременно, и возвращать для каждого ключа значения.
это если делать немного поисков.
А если нужно одновременно в массиве из 1 млн значений найти другие 60.000 — это совершенно другая история. тут нужна сортировка и бинарный.
В других случаях можно просто ссылаться на индекс нужного столбца через подсчет ширины массива — при добавлении столбцов будет смещаться и индекс.
Речь вообще идет о феномене бинарного поиска, а не о функциях — индекс или ВПР. И та и та функция умеют искать бинарным поиском по сортированному массиву.
Поэтому совмещение ВПР и Индекс-ПОИСКПОЗ дает убер-решение, которое такое же быстрое, но в то же время не обладает недостатками ВПР. В статье выше об этом тоже ведется речь, даже выложен пример функции. UDF тоже напишу, попозже, опубликую, если до меня кто-нибудь не опубликует :)
Статья:
http://analystcave.com/excel-vlookup-vs-index-match-vs-sql-performance/
первые два пункта — трудно представить как нечто непреодолимое.
последний в моих проектах не актуален (ключи уникальны), и непонятно, как вопрос с неопределенностью решают другие алгоритмы.
Несколько условий — целый отдельный кейс реализации.
Пост о бинарном поиске в excel и ссылка на последнюю (6.0) версию файла тут
https://habrahabr.ru/post/313476/
по 2-му — тут интереснее, так не было задумано, буду фиксить вместе с первым параметром, который не принимает вручную добавленные или вычисляемые строки (что хотелось бы и мне в том числе). Апдейт кода выложу.
Думаю, решения должны быть, если нет, можно задуматься о реализации.
+ критичным является не оптимизация объема занимаемой памяти, а оптимизация процессорного времени.
Массивы в моих задачах большие, но не настолько большие, чтобы не хватило памяти.
Если массив 2^20 строк и все поиски разнородные, то при стремлении количества поисков к бесконечности среднее количество операций на один поиск стремится к числу, равному половине массива. Т.к. экстремумы — 1 и 2^20 (искомое может быть как в первой, так и в последней строке), среднее на большом количестве где-то посередине, т.е. 2^10, или ~500.000
Последняя