если отрезков много, то для поиска отрезка можно использовать поиск делением пополам. Ну а если у каждой вероятности целое число процентов (или даже промилле), то можно создать массив на 100 (или 1000 для промиллей) элементов, каждый элемент будет указывать на некоторый отрезок, и тогда определяем за О(1)
Yarilo-Vitaly, ну так эта тяжелая функция и не блокирует основной поток, о чем я написал. Меньше будет время на обработку других запросов - им не придется ждать, когда отработает функция. Основной поток Ноды ведь должен обрабатывать запросы от клиентов.
ну, например, если ты собираешь строку (или массив, что по сути то же) из этих 6 символов, то места различны - у них разная позиция в строке ('ABCDEF' не равно 'BACDEF'). А если тебе надобно множество из 6 символов, то пофиг в каком порядке их выбрать.
ragnar_ok, даже и не знаю, какой тут материал... По сути, довольно простая школьная математика. На каждом шаге определяем, кто более других "недополучил", тому и отдаем. i-й службе полагается доля p[i] от всех заказов, а досталось s[i]/s, вот и смотрим их разницу (либо отношение, как во второй формуле).
для справки: если у тебя полный граф с N вершин, то возможных путей из А в В будет "чуть" более чем (N-2)!
(там "!" - факториал)
думаю, очевидно, что линейный по сути DFS не сможет перечислить их все.
Можно. Главное, в контексте должен храниться постоянный объект. Легко заметить, что modalsState используется только внутри ModalProvider, и нет смысла его складывать в контекст. Если его убрать из контекста, остаются только showModal/hideModal, в которых modalsState тоже не нужен, если их написать по уму:
если отрезков много, то для поиска отрезка можно использовать поиск делением пополам. Ну а если у каждой вероятности целое число процентов (или даже промилле), то можно создать массив на 100 (или 1000 для промиллей) элементов, каждый элемент будет указывать на некоторый отрезок, и тогда определяем за О(1)