В этой статье я покажу, как протестировать стратегию по реальным историческим данным, сохранить сигналы, симулировать сделки, рассчитать метрики — и понять, стоит ли стратегия того, чтобы торговать ей на бирже.
Все примеры — на Python. В предыдущей статье я показывал написание бота и бектест кода, который просто выдаёт сухие сделки и реализованную прибыль в %. Однако существует много разных параметров и переменных стратегии, без которых ее использование обычно убыточно.
Недавноя наткнулся на интересную задачку, которая, по слухам, используется на собеседованиях в Google. На первый взгляд — простая угадайка: нужно отгадать комбинацию из нескольких элементов, получая после каждой попытки лишь подсказку о числе совпадений. Но стоило мне углубиться, как стало ясно: эта задача отлично тренирует стратегическое мышление, анализ вероятностей и применение эвристик. Изначально я придумал решение, а затем трижды его улучшил, добившись стопроцентного результата и снизив среднее число попыток. В этой статье я подробно расскажу, как размышлял, какие гипотезы проверял, и как шаг за шагом превратил «угадайку» в чётко работающий алгоритм.
Привет, Хабр! Сегодня я расскажу про реализацию матричного умножения и особенности разработки для GPU. Познакомлю вас с устройством GPU, объясню, чем отличается программирование от привычного для CPU, какие нюансы нужно учитывать для эффективной реализации операций GEMM. А затем сравним производительность разных подходов к реализации.
Образовательные программы компьютерных наук и информатики обязательно включают курс алгоритмов, это элегантные решения сложных проблем. Например, одна из самых интересных проблем комбинаторной оптимизации — задача коммивояжёра (TSP, travelling salesman problem). Суть в поиске самого выгодного маршрута, проходящего через указанные точки ровно по одному разу. Сложность задачи при точном решении брутфорсом составляет O(n!). И для неё тоже придумано несколько элегантных алгоритмов. Хотя поиск самого эффективного продолжается до сих пор.
В реальности уже нет коммивояжёров, путешествующих по городам, профессия ушла в прошлое. Но есть курьеры, таксисты, логисты, грузоперевозчики и просто туристы, которые хотят посетить максимальное количество достопримечательностей. То есть задача по-прежнему актуальна. Как же максимально эффективно настоящие бизнесы решают TSP в реальной жизни?
Привет! При решении контестов я нашёл интересную задачу по теме динамического программирования.
Постановка задачи: Необходимо найти наибольшую общую возрастающую подпоследовательность двух массивов.
В этой статье я разобрал несколько способов решения этой задачи с разными асимптотиками по времени.
Полный разбор создания алгоритмического трейдинг-бота с использованием индикатора Bollinger Bands, кластерных сигналов и API Bybit. 1700% прибыли за год использования.
Вопрос точности прогнозирования осадков — один из ключевых вызовов в метеорологии. Мы все сталкиваемся с ситуациями, когда дождь буквально появляется «из ниоткуда», несмотря на оптимистичный прогноз. Особенно остро эта проблема проявляется летом, когда проливные кратковременные дожди сложно поймать заблаговременно. Об этой проблеме знает и наша команда Яндекс Погоды и ищет способы решить её.
Если бы меня попросили назвать слово, которое лучше всего подходит для прогноза осадков, я бы с уверенностью выбрал «сложность». В осадках она подстерегает нас всюду: от способов прогнозирования до оценки качества полученного прогноза. Потому в научных статьях про нейросетевой прогноз погоды (GraphCast, Pangu Weather, Aurora и т. д.) осадки или совсем не участвуют, или прогнозируются раз в 6 часов без упоминания о метриках. Либо же создаётся локальная модель под регион (например, MetNet для США).
В Яндекс Погоде мы используем множество ML‑моделей в рамках наших технологий прогноза Метеум и OmniCast, постоянно их улучшаем и постепенно заменяем на более продвинутые, повышая качество прогноза для наших пользователей. Недавно мы научились прогнозировать грозы, а до этого — улучшили прогноз температуры за счёт использования пользовательских метеостанций.
Меня зовут Стефеев Дмитрий, я разработчик группы ML и качества прогноза в Яндекс Погоде. Сегодня я и моя команда хотим представить новые модели для прогноза осадков и рассказать, почему мы на них перешли и как этот переход повлиял на качество.
С развитием всемирной паутины особую популярность набирают децентрализованные системы, основанные на одноранговых (P2P, пиринговых — эти термины являются синонимичными) сетях. В отличие от традиционных централизованных клиент-серверных моделей, где центральным звеном выступает сервер, обслуживающий клиентов, в одноранговых (децентрализованных) сетях все участники равноправны — здесь отсутствует иерархия и выделенный сервер. Любой участник сети может обмениваться информацией с любым другим, при условии соблюдения правил, или протоколов, используемых в таких сетях.
Стержнем, объединяющим разнородных участников в единую сеть, является возможность обмена информацией между ними. В клиент-серверных системах сетевое взаимодействие организовано достаточно тривиально: все компоненты подключены к центральному узлу — серверу, через который осуществляется передача данных от источников к получателям. В децентрализованных системах ситуация принципиально иная: отсутствует единый коммуникационный центр, и все участники взаимодействуют напрямую друг с другом. Именно поэтому организация сетевого взаимодействия в таких системах представляет собой гораздо более сложную и нетривиальную задачу.
В основе любой ИНС — инерциальный измерительный модуль (IMU). Типичный IMU включает три взаимно перпендикулярных акселерометра и три гироскопа, иногда ещё три магнитометра (dewesoft.com). Акселерометры измеряют специфическую силу — разницу между истинным ускорением и ускорением свободного падения. Гироскопы измеряют угловую скорость. Магнитометры оценивают вектор магнитного поля Земли и позволяют корректировать курс. Такой 9‑осевой датчик иногда называют «AHRS» — системой ориентации и направления (attitude and heading reference system). В нашем проекте используется MEMS‑IMU с 6 степенями свободы и встроенным термодатчиком.
Условия задачи
Сценарий:
У нас есть e-commerce платформа, состоящая из:
• веб-приложения,
• брокера сообщений,
• бэкенда.
Клиенты могут заказывать товары, а складская система проверяет наличие товаров на складе.
Каждый раз, когда клиент делает заказ, система отправляет запрос через брокер для проверки доступности товара на складе и блокирует его на время обработки заказа.
Проблема:
Клиенты могут:
• добавлять несколько товаров в корзину одновременно,
• отправлять несколько заказов.
Это приводит к тому, что резервируется больше товара, чем есть на складе.
Из-за этого возможны ситуации, когда товар отображается как доступный, но при попытке завершить заказ оказывается, что он уже заблокирован другим клиентом.
Необходимо:
• Выявить процессы, которые происходят,
• На основе этих процессов отобразить схему (sequence diagram) взаимодействия,
• Предложить 2 способа оптимизации, чтобы избавиться от текущих проблем.
Переходим к решению ⬇️
В последние годы большие языковые модели кардинально изменили ландшафт искусственного интеллекта, открывая невероятные возможности для автоматизации текстовых задач. Однако, несмотря на впечатляющие успехи, одна из ключевых проблем остаётся нерешённой — модели часто допускают логические ошибки, создают неясные или избыточные формулировки, а также генерируют тексты с низкой степенью доверия к собственным ответам.
В своей практике я столкнулся с необходимостью повышения качества генерации без постоянного ручного контроля и затратных этапов дообучения. Это подтолкнуло меня к идее нового подхода — Semantic Error Correction Loop (SECL), представляющего собой само исправляющийся итеративный пайплайн с внутренней оценкой качества и семантической уверенности.
Для изучения этой статьи вам потребуется базовое понимание методов обнаружения столкновений в узкой фазе, а также знание смежных с данной проблемой геометрических концепций, в частности суммы Минковского.
Несколько лет назад я посмотрел отличную презентацию от Дирка. В ней он описывал теорему о разделяющей оси, пролегающей между выпуклыми многогранниками (видео, слайды). Примерно на 18 минуте (слайд 29) он заводит речь о наложении гауссовых отображений выпуклых многогранников — как они помогают найти грани разности Минковского для этих многогранников.
В статье описывается старинная головоломка, русский вариант которой известен под названием «меледá». Решение этой головоломки тесно связано с информатикой. Здесь и первое в истории практическое использование двоичной системы счисления, рекурсивные алгоритмы, рекуррентные соотношения и др.
Головоломка, в России называемая старинным словом «меледá», состоит из замкнутой проволочной «вилки» («челнока»), имеющей вид длинной шпильки для волос и воткнутой обоими свободными концами в рукоятку, и нескольких колец, связанных между собой довольно сложным образом (см. рис. 1). Задача состоит в том, чтобы снять всю систему колец с вилки или надеть её обратно.
Файловая система во встраиваемых решениях — критическое звено. От её выбора зависят надёжность, детерминированность и задержки всей системы.
В типичном устройстве она обслуживает запись сигналов, ресурсы для дисплеев и аудиовоспроизведения, логи, файлы веб‑интерфейса, образы прошивок и многое другое.
На практике всплывают одни и те же проблемы: дефрагментация, высокое потребление RAM, плохая детерминированность (плавающие задержки), неустойчивость к сбоям записи/питания и низкая скорость. Нередко корнем оказываются драйверы из SDK производителей чипов: они не оптимизированы для многозадачной среды и часто недоработаны под OSPI.
Я протестировал четыре файловые системы на платформе MC80 с внешней OSPI NOR Flash и разработал специализированный драйвер вместо стандартного из FSP — с полноценной поддержкой OSPI и RTOS.
Многие Java-разработчики боятся алгоритмических задач (и я один из тех, кто включается в каждую дискуссиую на тему надобности алго-собесов для бигтеха). Они кажутся чем-то из параллельной реальности: где-то там, в университетах, на LeetCode, в собеседованиях в FAANG и контестах.
Но реальность такова: если вы хотите расти — алгоритмы знать нужно или хотя бы желательно. И не только ради собесов. Они в действительности помогают мыслить как инженер: структурировать задачи, оценивать сложность, писать оптимальный код, ну и шаблонно мыслить :)
Я расскажу, как можно подойти к этому процессу системно и без боли — на основе личного опыта Java-разработчика и преподавателя.
Недавно я прочёл книгу «Кому нужна математика?» Нелли Литвак и Андрея Райгородского — и она меня по-настоящему зацепила. Это короткие, живые рассказы о том, как математика помогает решать важные и неожиданные задачи: от составления расписаний до защиты интернет-трафика. В этом посте я перескажу три истории из книги, которые особенно меня удивили
Библиотека функций к Script-fu
Введение.
Прежде чем приступить к описанию реализации обобщённых функций, надо рассказать о основном алгоритме использующемся при выборе наиболее подходящего метода, при вызове обобщённой функции.
Наша система реализует множественное наследование, поэтому при вызове обобщённой функции надо реализовать какой то способ определяющий какой метод надо построить иерархию родителей, от которых наследуются классы объектов используемых в качестве аргументов обобщённой функции и на основе этих иерархий выбрать метод наилучшим образом подходящий для данного набора аргументов.
Процессная аналитика (Process Mining) — это методология сбора и анализа информации о бизнес‑процессах. Она помогает составить реальную схему процессов, разобраться в их работе и найти узкие места, требующие вашего внимания. Также процессная аналитика помогает выявлять «нетипичные» пути прохождения и прогнозировать работу бизнес‑процессов.
Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео‑Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.
Удивительно, но факт: несколько изменений в изображении могут полностью поменять вывод нейросети, что ломает заложенную разработчиком логику. В данной статье мы не просто подсветим факт существования One Pixel атаки, но и комплексно разберём архитектурные факторы, которые влияют на устойчивость CV-систем к данному семейству атак.
Весной 2024 года я — курсант летной школы по классу PPL (частный пилот) с несколькими десятками часов налёта, осознал то, чего старается избегать каждый лётчик: потеряться в пространстве без визуальных ориентиров, например оказался под плотной облачностью без привычного GPS‑сопровождения. Спутниковые сигналы в России с 2022г заблокированы по известным причинам. До этого момента я воспринимал навигатор в телефоне как «дополнительный инструмент». Но когда на панели вдруг погас зелёный индикатор спутников, по спине пробежал холодок: как отработать возврат в аэродромную зону в «белом» небе без визуальных ориентиров?
Известно, что инерциальные навигационные системы (ИНС) могут определять местоположение, ориентацию и скорость объекта без внешних источников. Внутри них наработки десятилетий — набор ускорителей и гироскопов, расположенных ортогонально, и вычислитель, который интегрирует измеренные ускорения и угловые скорости. ИНС — это, говоря простыми словами, «супер‑мертвый пеленг»: она интегрирует собственные ускорения и вращения, чтобы определить, куда и на сколько мы сместились. Достоинство такой системы — полная автономность, независимость от спутников и наземных радиомаяков. Именно это и нужно в эпоху блокировок сигналов, когда GPS может исчезнуть в самый неподходящий момент. К стати — не только в воздухе, но в любой среде — будь‑то тоща воды или космическое пространство.
Однако у классического «мертвого счёта» есть серьёзный недостаток: ошибки интегрирования накапливаются во времени. Даже самые точные акселерометры с погрешностью порядка 10 микрон могут дать ошибку в 100 метров всего за 5 минут полета, если её не корректировать. Таким образом за полетный час рискуем «улететь» на пару километров в сторону и потерять визуальные ориентиры при ВП. Поэтому в авиации инерциальные системы обычно работают в связке с внешними источниками (радиомаяками, GPS и т. п.), которые регулярно сбрасывают накопившийся дрейф. В моем проекте основная задача — обеспечить не менее часа автономной работы с минимальным дрейфом. Предполагается возможность корректировать корректировать свою позицию либо по сигналам VOR DME, либо по триангуляции на вышках СС, либо визуально (подтверждение пилотом прохождения крупных объектов‑маркеров).
