rPman

Для каждого следующего числа проверять, не меньше ли оно предыдущего, и если меньше, то повторять попытку получения случайного числа

Случайные числа на интервале на javascript получают с помощью Math.Random()*(максимальное число-минимальное) плюс минимальное. По ссылке пример с math.floor, округляющий число до целого, но осторожно, в этом случае максимальное число никогда не будет получено... возможно лучше тут использовать math.round

Так и не увидел в вопросах уточнений по алгоритму, поэтому потелепатствую, возможно уточнение возникнет тут:

Пишем функцию, которая заданный выпуклый многоугольник рассекается заданной одной прямой, на выходе новый многоугольник (на самом деле два, выбор какой из них возвращать и есть вопрос-уточнение, например тот что имеет больше граней) либо тот же самый, если линия не попадает (или попадает на грань). Делать ее легко, перебираем грани многоугольника, проверяем пересечение с заданной линией, их будет две если не будет попаданий на грань), соединяем полученные две точки линией - это новая грань, теперь нужно отбросить те грани, которые с одной стороны от заданной грани (чтобы это определить, хранить грани отсортированными по часовой стрелки и перебирать по порядку, сторона будет определяться тем, следующая ли это грань или предыдущая).

Затем для каждого отрезка вызываем эту функцию, последовательно отсекая от многоугольника, в конце получим искомый.

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

Для начала я говорю про ядро биржи, которое с высокой вероятностью напрямую недоступно, и клиенты работают с ним через некую прослойку с дополнительным интерфейсом.

Есть 2 основных метода, зависит от того как именно будет вестись исполнение сделок.

Первый, децентрализованный - вы не обслуживаете стакан (только как информационный сервис) и предлагаете участникам исполнение выбранных ордеров участников на нужный объем, выступая гарантом escrow и возможно местом хранения балансов (т.е. клиенты выбирают встречный ордер, называют свой объем и биржа на этот объем исполняет ордер), и не важно что там ордера пересекаются по цене (т.е. 'стакан' в виде буквы X) и скорее всего у вас будет свой аффинированный с биржей маркетмейкер, который на привилегированных условиях иметь приоритетное право блокировать ордера и брать их на исполнение. Т.е. это будет некий бот, который запускает на исполнение встречные заявки по пересекающимся ценам а разницу в суммах берет себе, грубый пример у вас есть ордера продажи 1 по $5.1 и покупки 1 по $5.0, очевидно что если оба этих ордера исполнятся то возникает избыток на балансе (грубо говоря вы сначала продаете 1 биткоин получив $5.1 а затем покупаете по $5.0, в остатке $0.1).

Почему это имеет смысл, все участники биржи не могут знать оперативно о том что происходит у всех, все происходит с некоторым лагом, если в выше описанном примере вы как обычный клиент начнете такую сделку, после первой половины, вторая может обломиться, если ордер исчезает из списка (например его отменяют или меняют цену, если есть такой функционал).

Биржа может сделать гадость, и дать специально выделенному участнику привилегированные права, например атомарно блокировать чужие ордера (запрет на отмену и исполнение другими на время исполнения), так кормят своего маркетмейкера (у такого еще и комиссии меньше или нулевые) в этом случае все пересекающиеся ордера будут моментально исполняться а без рисковый доход с них будет забирать этот 'трейдер'.

Второй способ, централизованный - биржа сама обслуживает сделки, сама их исполняет, поэтому в момент размещения ордера она сама же проверяет наличие пересечений и забирает бонусную разницу с ордеров себе сразу, таким образом стакан похож на стакан V.

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

Второй способ, очень просто в реализации. Пишется за несколько дней, я для прикола, изучая websocket ReactPHP, делал ядро биржи, которая на симуляциях доходила до 10к сделок в секунду, там зависело от количества лимитных ордеров, которые затрагивают сделки и почти линейно замедляло, полагаю на C++ можно было бы сделать на пару порядков быстрее. Но такой прямой способ обслуживания балансов в оперативной памяти очень опасен для продакшен, например нужно помнить о единичных сбоях в памяти.

В течение дня с помощью 3 курьеров нужно развести 20 коробок по 20 адресам из 4 точек. Например в рамках Питера.

Для начала тебе нужно построить граф путей, где вершины - это 20 целевых адресов и 4 исходные точки, а вектора - это оценка (в худшем) времени пути между ними, причем как от складов до адресов так и между адресами. Это тут самая сложная задача, так как исходные данные только карты, где непонятно сколько времени ехать, есть ли зависимость от времени суток и нагруженности курьера.

Если ты курьерская компания уже не первый год на рынке, ты можешь себе позволить собрать статистику по тысячи курьеров (у тебя есть отметки где какой курьер куда приезжал) и составить такие графы для временных периодов 'не должно быть проблемой'.

Ну а дальше комбинаторика, самый тупой метод поиска в глубину решит условно любую задачу, причем найдет оптимальное решение, но максимально неэффективным (с точки зрения затрат на решение) способом, у тебя всего 3 курьера и всего 20 точек, это ниочем.

Есть конечно еще момент, оценка времени перемещения курьера в виде одного числа (например максимум) не является идеальным прогнозом, так как чем больше будет курьеров, тем больше будет простоев из-за того что реальное время перемещения быстрее чем оценка, правильно брать среднее и придерживать какой то процент курьеров про запас, чтобы не увеличивать время ожидания, когда все курьеры 'опаздывают' согласно средней оценки.

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

Язык программирования выбирают под наличие инструментов, написанных для этого языка, для решения поставленной задачи.

Только в этой последовательности и не наоборот.

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

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

Почему си? потому что когда начнешь ковыряться с отладчиком в дампах памяти (программ на любых языках программирования), именно эти знания тебе понадобятся, а не наслоения синтаксического сахара и абстракций высокоуровневых языков.

Если же тебе это не нужно (а бывает не нужно), то и не заморачивайся

Лабиринт в форме - ячейка это либо стена либо проход (0/1)?

Заводим класс - 'Вершина графа', ребра которого - его параметры ссылок на Смежные вершины, для каждой стороны вверх, вниз, налево и направо. Если нужно выявление замкнутых подмножеств, то добавляем параметр - номер подмножества (значение 0 - неизвестно)

Создаем временную матрицу для хранения вершин (можно добавить параметр в объект ячейки матрицы, если такой есть) с пустыми/нулевыми значениями
Пробегаем по матрице лабиринта, на каждую пустую ячейку (проход) создаем вершину графа, пусть перебираем матрицу сверху вниз и слева направо, то для каждой такой ячейки смотрим наличие прохода слева и сверху, если есть, добавляем соответственно ссылки на слева и сверху, а для их вершин ссылку на текущую созданную соответственно справа и снизу.

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

В результате когда пройдем по всем ячейкам матрицы, у нас будет готовый список графов, ячейки которого пронумерованы (ну не по порядку, будут пропуски номеров), понадобится еще проход, чтобы записать в список эти группы, и можно удалять временную матрицу вершин

Сортируешь числа в списке предметов по возрастанию
Алгоритм добавления количества Z следующий:
* по очереди берешь равные по значению числа (пусть будет X, количество N) и следующий за ними не равный по значению (пусть будет Y), если такого нет то считаем это значение - бесконечным
* вычисляешь разницу Y-X, вычисляем, сколько можно дололжить к ним от Z - считаем если (Y-X)*N меньше или равно Z значит заменяем N первых чисел на Y, а из Z вычитаем (Y-X)*N, если (Y-X)*N больше Z (в т.ч. если Y - бесконечность) значит к этим первым N числам из списка прибавляем Z/N (если не делится на цело, значит берем целую часть от Z а затем остаток по 1 докидываем вторым проходом, Z обнуляем, завершаем работу алгоритма
* если Z не ноль, повторяем весь алгоритм

Объем seed для генерации универсальных данных будет больше или равен в среднем их размеру

Отличный пример - внутри числа pi есть все последовательности данных которые в принципе могут существовать и даже есть формула которая выдает позицию, начиная с которых она есть - πfs.

p.s. есть алгоритмы с потерей, например сжатие изображения и звука, вот тут поле не пахано да
ну и вишенка на торте - нейронная сеть размером несколько килобайт на видеокадр позволяет сгенерировать весь видеоряд (не смог найти, на хабре была статья, понятно там качество ужасное, нейросеть не справлялась с лицами но сама идея шикарная)

Ответ на этот вопрос можно получить либо экспериментально либо изучив серверную реализацию (в конечном счете тоже экспериментально).

У тебя 2 основных узких 'горла' - скорость подготовки ответа сервером (процессор и диск) и скорость сетевого соединения до него... ну а медленный клиент можно распараллелить несколькими машинами (и соответственно провайдерами если проблема в сети на стороне клиента).

Если узким горлом является сетевое подключение (ширина канала), то достаточно посчитать средний размер запроса и ответа по отдельности, включая служебные пакеты, и поделить на эти числа ширину канала до сервера соответственно туда и обратно (лимиты и возможности на них обычно разные и слабо друг от друга зависят), т.е. может так получиться что канал забьется не ответами сервера а трафиком на запросы.

В дополнении к скорости сетевого подключения есть скорость ответа (пинг), но при множественных подключениях клиента к серверу, его влияние на результат почти исчезает.

Ну и вишенка на торте, транспортный уровень может внести корректировки, полистай статью

Если говорить про сервер и его возможность в принципе отвечать с какой то скоростью (самый частая причина лимита скорости обработки запросов) то тут все зависит от того, как подготавливается ответ, какие ресурсы на это тратятся и т.п. например тормоза могут вытекать из медленной скорости чтения диска...

С диском совсем грустно, например hdd может нелинейно уменьшать скорость ответа в зависимости от его нагрузки и еще сложнее - в зависимости от размещения данных на нем, т.е. если клиенты (или алгоритмы балансировщика на сервере) подгадают порядок считываемых данных на последовательный, то скорость чтения может быть сотни мегабайт в секунду, а если запросы будут случайными, то считанные мегабайты. Т.е. в следствии чего возможна ситуация когда один клиент, последовательно запрашивающий данные в определенном порядке будет отрабатывать запросы значительно быстрее (на порядок или два) чем несколько параллельных и наоборот, если сервер будет специально притормаживать 'плохие' запросы, организовывая правильно доступ к диску то много параллельных клиентов лучше одного (в этой схеме лучше сделать один клиент который сразу делает все возможные запросы, паралельно, и ждет ответы).

Ну и нагрузка на процессор, если реализация однопоточная (асинхронная реализация сильно усложнит подсчет) то скорость ответа будет линейно зависеть от времени обработки одного и нагрузки на процессор (проще замерить сколько клиентов дадут 100% нагрузку). Но вот многопоточные реализации могут давать неожиданные ухудшения характеристики, т.е. 10 потоков могут не дать 10-кратное увеличение скорости, и с величением потоков будет много ресурсов уходить на поддержание этой работы (кажется теория вообще говорит о квадратном корне из количества потоков), и это еще про кеш процессора речи не идет, так как в зависимости от того, влезает ли алгоритм обработки (нужная ему память) в него или нет тоже можно получить кучу странностей, например 1-2 потока будут давать быструю скорость, но добавив третий, даже не нагрузив весь процессор, можно получить значительное понижение производительности, так как данные трех потоков не влезают в кеш. Кстати оперативная память хоть и называется Random Access memory но может давать разную производительность в зависимости от характера нагрузки (особенно это видно по вычислениям на GPU) что тоже не лучшим образом влияет на многопоточный результат.

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

В общем случае гуглить - многомерная оптимизация (у тебя всего 4 показателя да еще и значения на известных границах - лафа, это визуализировать проще)

Если собираемые показания с шумом, то с ними бороться можно только повышением количества сбора показаний (вычислений)

Процесс творческий.

К сожалению не существует универсального алгоритма, выше автор дал скрин (срез по 3 показателям, мог бы цветом четвертый визуализировать) очень неудачная функция, большое плато искать на нем минимум - грустно, и все способы крутятся вокруг поиска дополнительной информации о функции.

Как вариант можно попробовать поискать способ упрощения (ускорения вычислений), но это зависит от них самих, например если итоговое значение функции - сумма большого количества внутренних непоследовательных шагов, которые можно пропускать или менять порядок, то можно в качестве промежуточных результатов использовать приблизительное решение, использующее меньшее количество этих шагов, выбранных случайно, а точнее таким способом, чтобы среднее отличие этой упрощенной оценки не отличалось от настоящей.

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

Один из простых методов многомерной оптимизации состоит в построении матрицы якобиана, вычисления производной по изменению каждого критерия на минимальный шаг, так вот такую же матрицу можно строить и по этим внутренним шагам, они покажут какой именно критерий в каком случае имеет большее значение а значит его изменение будет иметь большее значение чем пытаться полностью пересчитывать для функцию для каждого критерия

p.s. можно к функции добавить усложнение, которое ведет себя более ярко выраженно в исследуемых точках, грубо говоря 1/(f(x)-a) будет сильнее меняться для значений первоначальной функции рядом с точкой a (осторожно с делением на 0, в этой точке такой подход даст неопределенный результат и для него может понадобиться пересчет), т.е. там где сама функция похоже на плато, возведением в отрицательную степень максимизирует незначительные движения и может помочь найти разницу

upd. посмотри weka, фреймворк написан на java, есть gui, как для выбора алгоритмов так и по визуализации (слабоват), как отправная точка для поиска алгоритмов чтобы и и посмотреть что есть и попробовать, что не понятно, вбиваешь название алгоритма в гугл и ищешь подробности

Задача может быть решена аппаратно, 3d камеры от того же intel в примерах в sdk предлагают софт именно для этого, дают облако точек, но пользоваться этим невозможно

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

Вектор угла направления взгляда/положения лица будет прыгать как сумашедший от кадра к кадру, я еще про эмоции не сказал, каждая эмоция тоже параметризована, все это не позволит дать точное соответствие одной и той же точки на лице на соседних кадрах, т.е. построив к примеру поверхности по этим точкам они просто не сойдутся на следующем кадре, в результате будет сильный шум, затрудняющий хоть какую то адекватное применение (игрался я с 3d камерами от intel, сильный шум результата делает все бессмысленным)

Если матрица разряженная (много нулей) то хранить лучше в сжатом виде, выбор алгоритма зависит от степени разряженности

способ хранения, отличным от просто массива байт, фактически определяется индексами, которые будешь строить для ускорения и хранения сжатых данных

например можно хранить вектор в виде трех списков key-value словарей, один - список байт со смешанными значениями бит, список с только нули либо список с только единицы (достаточно хранить только один из этих двух, отсутствие значений в первом и втором списках покажут что элемент в третьем)

матрицу можно хранить как построчно так и квадратами (например 8х8 бит подматрицы), выбор способа разделения матрицы на блоки определит характер распределения элементов (в приведенном примере это имеет смысл если биты имеют свойство 'липнуть друг к другу', т.е. вероятность что бит будет установлен рядом с другим установленным выше чем среди пустых бит)

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

алгоритм, умеющий торговать? да нет проблем, берешь ccxt (если криптовалюты), читаешь историю сделок с биржи, считаешь медиану (любой готовый индикатор), значение выше порогового - продавать, ниже - покупать, работы на часа два, больше времени будешь разбираться как настроить установить добавить запустить, кода строк на двадцать наверное.

алгоритм, умеющий приносить прибыль? извини, это святой грааль всех трейдеров, на коротком промежутке времени (даже год другой) у кого то получается, но рано или поздно этот алгоритм ломается (мир меняется), сливая депозит так что вовремя это нужно обнаружить, и нужно искать новый

Бесконечный цикл все равно будет, либо ты его напишешь либо его организует библиотека (какой-нибудь асинхронный фреймворк типа react, если что твой ответ можно найти в нем).

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

С часами все просто - нужно не раз в секунду проверять время, а взять самый короткий интервал и вычислить, сколько до него ждать (время действия минус текущее время) и просто одной командой выставить sleep.