Глубина обзора, качество сравнения, масштаб и сложность задач автора потрясают!
А если серьезно, то зависит от задачи(если это сложное исследование, а не сайтики, конечно)
У меня полно было задач где не вывозили frontier сетки и вывозили сетки попроще. И что Opus 4.8 не вывозит, а GPT 5.5 XHIGH - легко и наоборот у меня постоянно. Были задачи где ни Гопота ни Опус не смогли, а Грок смог.
Пока в моих ресерчах я не могу отдать первенства Fable против Sol максималках.
Sol быстрее сильно и оно решает. Fable долгий, но субъективно креативнее Мало еще сетки доступны, чтобы делать выводы
"Крупные HFT гиганты десятилетиями оттачивают алгоритмы в этой сфере, и раз они до сих пор не показывают 10000% прибыли, то проблема явно не решается так просто."
Вывод из неверного утверждения.
HFT никогда не было про 10000% прибыли. Оно всегда было про гарантированную прибыль на капитал и инфраструктуру относительно "ритейла", сравнимую с инсайдом относительно "монетки"(колокейшн на самой бирже, FPGA, сабнаносекундное исполнение). Это "другая лига". VPS в Дублине рядом с Polymarket это не HFT, а ритейл. И они какбэ маркетмейкеры и поставляют ликвидность за бакшиш помимо арбитража. По этому это прибыль на капитал , а не просто прибыль.
Да и важен не процент прибыли, а сколько тебе в принципе рынок способен отдать с капитала и с какими рисками. Можно 100000% получить с одного цента, а толку? Можно Ашан построить в глухой деревне. Не процентами оно меряется.
Ну и показатели в индустрии не плохие) с 16 ярдов снять 10 за квартал.
Например, Jane Street
Выручка и прибыль: Частная компания, установившая исторические рекорды. В 2025 году ее торговая выручка достигла $39.6 млрд, а скорректированная EBITDA составила около $31.2 млрд. В первом квартале 2026 года рост продолжился: доход составил $16.1 млрд, из которых чистая прибыль — $10.3 млрд.
Штат: Около 3 500 сотрудников.
З.Ы. К вопросу "сколько рынок способен отдать с контролируемым риском". HFT компаний масса и они все едят эдж друг у друга. Рынок не бесконечен и у них тоже. Если уж так прямо хочется заявлять об отсутствии доходности у них или ее наличии, то надо тогда мерять прибыль всех HFT гигантов толкающихся локтями на баржах
Так и для физической модели оно не работает. Когда с помощью оптимизации параметров "на шуме" мы пытаемся найти целевую функцию, в результате получается функция, которая является компромиссом, наилучшим образом описывающим зашумленные данные, а не фундаментальную закономерность. Я писал алгоритм цель которого по массиву данных эвристически определить коэффициенты и полином описывающий данные. Замечательно работает на не шумных данных, спокойно выковыривает закон Бернулли, Ома, любую тригонометрию и т.д. Уже при добавлении всего 1% шума половина тестов сыпется, а при 5 и более вместо простейшего закона Ома получаем "огромную формулу" которая по факту точнее описывает "предоставленные данные", но к закону Ома уже не имеет отношения(и выглядит мягко говоря не так)
Уже и как упражнение по программированию - ни о чем. Когда 15 лет назад написал свой бэктестер, даже тогда это была задача без звездочки. Сейчас бэктестер со всеми возможными "свистелками и переделками" был написан с помощью ИИ по приколу за неделю. И то он нужен был не что-то новое придумать, а как дополнение к боту. Хотелось попробовать что-бы бот мог прогонять тесты на ближайшей истории в процессе принятия решений либо гонять несколько стратегий и выбирать адекватную "на сейчас". В итоге попробовал и понял что только ухудшает понимание того, что делает бот и усложняет опиливание стратегий
Так это не стратегия, а просто еще один бэктестер отличающийся от других - чуть меньше, чем ничем. Точнее от большинства отличающийся производительностью, а от GPU бэктестеров - ничем. Ну разве что не зрелостью и сыростью(не хочу обидеть автора)
Я тоже написал свой бэктестер, тоже GPU(с ИИ сейчас это быстро), испытал воодушевление а потом вернулся к точке в которой был 20 лет назад - проблеме создать стабильно прибыльную механическую торговую систему. А первый бэктестер сделал примерно 15 лет назад без всяких ИИ и он спокойно ушел в мусорку т.к. поддерживать "свой" - трата времени на этом пути..
То что решил сейчас(для себя) автор - тестирование большого количества параметров за малое время, решалось так же и 30 лет назад(просто использовали больше компьютеров).
Никаких "фундаментальных проблем создания прибыльных ТС" удешевление инфраструктуры для бэктеста не решает. Подчеркну: удешевление инфраструктуры, а не ускорение)
Если есть фантазии про поиски корреляций и статистических закономерностей в больших данных, то большие данные - скорее минус, а не плюс. Фундаментальные закономерности просто забиваются шумом, а оптимизация - это подгонка коэффициентов под рандом.
Мое резюме: оптимизация - это самое последнее что нужно в разработке стратегий и лучше ее вообще избегать. Даже train/evaluation/run - такая себе тема)
Просто робот «один из». По механике, понятное дело, не самый лучший.
Отличается няшным внешним видом и софтом. На этом и выезжает.
Как Айфоны) Софт и дизайн
Не понимаю чем Ваши идеи более годные и чем принципиально отличаются от тех, что хочет профинансировать государство через сбер.
По распознаванию речи много сделано(Сири/Алиса) и в планах Сбера и так это есть судя по статье
чтобы быстро и шустро двигаться, не нужен ИИ и с этим проблем нет. ИИ нужен принимать решения. Не нужны человекоподобные роботы ни для палетирования, ни для сварки, ни для большинства других операций.
опять же вопрос: нахрена? Какие прикладные применения? Везде где есть применения ИИ и так используют в творчестве. И музыку он делает и рисует...
Да миллиард на одного в год это много. Я вот тоже не смогу освоить 2,8млн в день. Даже не смогу команду собрать под такой бюджет.
А если это 1000 команд о чем идёт речь, то это копейки.
Моя команда из 7 человек, это уже почти млн руб в мес, то-есть на ярд можно «потянуть» 80 таких команд.
У меня все прекрасно собирается и бенчится и на рабочих Маках и на серверах Linux.
Даже поднял один продакшн на uWS. Вроде стоит, как скала.
По производительности пустых запросов у меня uWS в 3-4 раза быстрее нативного нодовского HTTP/WS и может легко соревноваться с не нодовскими серваками.
И при этом я все таки считаю, что для сетевого транспорта JS не нужен и лучше уж взять Actix на Rust и раз уж хочется логику писать на JS, то вызывать JS микросервисы из Rust.
Ну или если нет дружбы с ржавчиной, то взять Cишный uWebSockets
Все проще.
Большинство фреймворков будут умирать при вызревании JavaScript (ECMAScript), HTML и CSS. Что они и делают сейчас.
Просто те костыли, что предоставляют фреймворки будут закрываться встроенным функционалом JS и иже с ним.
Просто тем, кто не начал активно использовать D3, кажется что это библиотека по работе с графикой, а она по работе с DOM.
Графика просто наглядно показывает что и каким количеством кода может D3.
Данные не обязательно визуализировать графикой, можно и таблицами, формами, кнопками и окнами. С этим D3 справляется точно также.
Порог входа, конечно в нее выше чем в jQuery.
Даже концепцию enter/update/exit новички не сразу вкурить могут.
Ну это вам очевидно)
По этому и программисты очень разные и качество кода разное и скорость реализации одних и тех же задач разная и проекты разные и заработки.
Не всегда то, что в тренде и есть самое лучшее.
Конечно надо знать что такое jQuery, чтобы как минимум можно было временно прицепить к проекту чужой говнокод и чтобы потом хотяб смочь сделать рефакторинг с целью вырезать эту и прочую хрень)
1000%-я замена.
Посмотрите примеры как D3 позволяет вертеть DOM или SVG и это при коротком и лаконичном коде. Посмотрите, что и каким количеством и качеством кода делаетя с графикой и представьте что и как можно делать с интерфейсом, если понимать идеологию D3.
А JQuery это — тонны мусора в коде, особенно с ростом проекта.
D3 отображает и обновляет слой данных и отделяет данные от DOM,
а JQuery мешает все в кучу — это как мазать краской холст каждый раз поверх. DOM надо создавать, а не патчить. Data Driven Documents это подход, концепция, а JQuery — не более, чем обертка для обычных ванильных яваскрит функций.
А используют эти библиотеки по сути для одного и того же.
Я когда ищу реализации чего-то или алгоритмы и вижу JQuery в зависимостях, то сразу в помойку этот скрипт и смотрю следующий т.к. в 99% случаях это означает что будет 5000 строк мусора на то, что можно было сделать за 300-500 строк порядка.
Я своим запрещаю эту хрень)) Но это личное дело каждого.
Больше похоже на список распространенных технологий/API/языков о которых необходимо иметь представление.
Учить в таком порядке — убить программиста)
И структурировано странно. Я бы, например, для фронтенда запретил вообще изучать JQuery, как самый большой источник говнокода. А вот D3, который это все делает на много лучше я бы поставил в основы. Уже только это невероятно бы повысило качество и реюзабельность. Весь список с Ангуларами, Реактами, Эмберами и пр. заменил бы на малюсенький riot.js ну т.д.
В общем в 2017-м ждем новых чудо кодеров, тащащих за собой огромные библиотеки из которых они пользуются 5%, при том что даже эти 5: можно реализовать правильно, читабельно и красиво)
Хотя, если встраиваться в команды, наверно лучше жить в этом стеке технологий, курить JQuery с Angular. Здравствуй тормозной и глючный веб)
Ну если это формальные признаки и сделайте себе «формальный» опыт работы и приходите через 3 года. Во многих небольших конторах при хорошем отношении с руководством и вашей ценности для компании, вполне возможно договориться, что-бы в трудовой была «правильная» должность.
Кто хочет, тот ищет пути!
L293d вроде и одного должно хватить.
DRV10983 — интересная букашка и не дорогая. Почему её в этом открытом проекте не использовали?
В чем плюс именно такой реализации? И думаю круглая форма платы тоже была бы предпочтительнее чтобы было удобнее сделать её частью сервы.
Очевидно, что подходит. Только где девайс взять, если сам сделать не можешь?
Ну и мне, как пока чайнику в управлении двигателями(все не соберусь никак купить себе «не серву» и поиграть) тоже интересно возможно ли управлять PMSM приводами с помощью L298 или L293d
Согласен.
Когда LLM даешь инструменты, ресерчи разворачиваются в триллер и сетки способны удивлять своими выводами
Глубина обзора, качество сравнения, масштаб и сложность задач автора потрясают!
А если серьезно, то зависит от задачи(если это сложное исследование, а не сайтики, конечно)
У меня полно было задач где не вывозили frontier сетки и вывозили сетки попроще. И что Opus 4.8 не вывозит, а GPT 5.5 XHIGH - легко и наоборот у меня постоянно.
Были задачи где ни Гопота ни Опус не смогли, а Грок смог.
Пока в моих ресерчах я не могу отдать первенства Fable против Sol максималках.
Sol быстрее сильно и оно решает. Fable долгий, но субъективно креативнее
Мало еще сетки доступны, чтобы делать выводы
З.Ы. Мне Грок говорит, что он 4.5 :)
"Крупные HFT гиганты десятилетиями оттачивают алгоритмы в этой сфере, и раз они до сих пор не показывают 10000% прибыли, то проблема явно не решается так просто."
Вывод из неверного утверждения.
HFT никогда не было про 10000% прибыли. Оно всегда было про гарантированную прибыль на капитал и инфраструктуру относительно "ритейла", сравнимую с инсайдом относительно "монетки"(колокейшн на самой бирже, FPGA, сабнаносекундное исполнение). Это "другая лига". VPS в Дублине рядом с Polymarket это не HFT, а ритейл.
И они какбэ маркетмейкеры и поставляют ликвидность за бакшиш помимо арбитража. По этому это прибыль на капитал , а не просто прибыль.
Да и важен не процент прибыли, а сколько тебе в принципе рынок способен отдать с капитала и с какими рисками. Можно 100000% получить с одного цента, а толку? Можно Ашан построить в глухой деревне. Не процентами оно меряется.
Ну и показатели в индустрии не плохие) с 16 ярдов снять 10 за квартал.
Например, Jane Street
Выручка и прибыль: Частная компания, установившая исторические рекорды. В 2025 году ее торговая выручка достигла $39.6 млрд, а скорректированная EBITDA составила около $31.2 млрд. В первом квартале 2026 года рост продолжился: доход составил $16.1 млрд, из которых чистая прибыль — $10.3 млрд.
Штат: Около 3 500 сотрудников.
З.Ы. К вопросу "сколько рынок способен отдать с контролируемым риском". HFT компаний масса и они все едят эдж друг у друга. Рынок не бесконечен и у них тоже. Если уж так прямо хочется заявлять об отсутствии доходности у них или ее наличии, то надо тогда мерять прибыль всех HFT гигантов толкающихся локтями на баржах
Так и для физической модели оно не работает.
Когда с помощью оптимизации параметров "на шуме" мы пытаемся найти целевую функцию, в результате получается функция, которая является компромиссом, наилучшим образом описывающим зашумленные данные, а не фундаментальную закономерность.
Я писал алгоритм цель которого по массиву данных эвристически определить коэффициенты и полином описывающий данные.
Замечательно работает на не шумных данных, спокойно выковыривает закон Бернулли, Ома, любую тригонометрию и т.д.
Уже при добавлении всего 1% шума половина тестов сыпется, а при 5 и более вместо простейшего закона Ома получаем "огромную формулу" которая по факту точнее описывает "предоставленные данные", но к закону Ома уже не имеет отношения(и выглядит мягко говоря не так)
Уже и как упражнение по программированию - ни о чем.
Когда 15 лет назад написал свой бэктестер, даже тогда это была задача без звездочки.
Сейчас бэктестер со всеми возможными "свистелками и переделками" был написан с помощью ИИ по приколу за неделю. И то он нужен был не что-то новое придумать, а как дополнение к боту. Хотелось попробовать что-бы бот мог прогонять тесты на ближайшей истории в процессе принятия решений либо гонять несколько стратегий и выбирать адекватную "на сейчас". В итоге попробовал и понял что только ухудшает понимание того, что делает бот и усложняет опиливание стратегий
Так это не стратегия, а просто еще один бэктестер отличающийся от других - чуть меньше, чем ничем.
Точнее от большинства отличающийся производительностью, а от GPU бэктестеров - ничем. Ну разве что не зрелостью и сыростью(не хочу обидеть автора)
Я тоже написал свой бэктестер, тоже GPU(с ИИ сейчас это быстро), испытал воодушевление а потом вернулся к точке в которой был 20 лет назад - проблеме создать стабильно прибыльную механическую торговую систему. А первый бэктестер сделал примерно 15 лет назад без всяких ИИ и он спокойно ушел в мусорку т.к. поддерживать "свой" - трата времени на этом пути..
То что решил сейчас(для себя) автор - тестирование большого количества параметров за малое время, решалось так же и 30 лет назад(просто использовали больше компьютеров).
Никаких "фундаментальных проблем создания прибыльных ТС" удешевление инфраструктуры для бэктеста не решает. Подчеркну: удешевление инфраструктуры, а не ускорение)
Если есть фантазии про поиски корреляций и статистических закономерностей в больших данных, то большие данные - скорее минус, а не плюс. Фундаментальные закономерности просто забиваются шумом, а оптимизация - это подгонка коэффициентов под рандом.
Мое резюме: оптимизация - это самое последнее что нужно в разработке стратегий и лучше ее вообще избегать. Даже train/evaluation/run - такая себе тема)
Отличается няшным внешним видом и софтом. На этом и выезжает.
Как Айфоны) Софт и дизайн
Еще интересно стало что же значит тогда любительская контейнеризация)
Не понимаю чем Ваши идеи более годные и чем принципиально отличаются от тех, что хочет профинансировать государство через сбер.
Да миллиард на одного в год это много. Я вот тоже не смогу освоить 2,8млн в день. Даже не смогу команду собрать под такой бюджет.
А если это 1000 команд о чем идёт речь, то это копейки.
Моя команда из 7 человек, это уже почти млн руб в мес, то-есть на ярд можно «потянуть» 80 таких команд.
Может я где ошибаюсь?
Даже поднял один продакшн на uWS. Вроде стоит, как скала.
По производительности пустых запросов у меня uWS в 3-4 раза быстрее нативного нодовского HTTP/WS и может легко соревноваться с не нодовскими серваками.
И при этом я все таки считаю, что для сетевого транспорта JS не нужен и лучше уж взять Actix на Rust и раз уж хочется логику писать на JS, то вызывать JS микросервисы из Rust.
Ну или если нет дружбы с ржавчиной, то взять Cишный uWebSockets
Большинство фреймворков будут умирать при вызревании JavaScript (ECMAScript), HTML и CSS. Что они и делают сейчас.
Просто те костыли, что предоставляют фреймворки будут закрываться встроенным функционалом JS и иже с ним.
Графика просто наглядно показывает что и каким количеством кода может D3.
Данные не обязательно визуализировать графикой, можно и таблицами, формами, кнопками и окнами. С этим D3 справляется точно также.
Порог входа, конечно в нее выше чем в jQuery.
Даже концепцию enter/update/exit новички не сразу вкурить могут.
По этому и программисты очень разные и качество кода разное и скорость реализации одних и тех же задач разная и проекты разные и заработки.
Не всегда то, что в тренде и есть самое лучшее.
Конечно надо знать что такое jQuery, чтобы как минимум можно было временно прицепить к проекту чужой говнокод и чтобы потом хотяб смочь сделать рефакторинг с целью вырезать эту и прочую хрень)
Посмотрите примеры как D3 позволяет вертеть DOM или SVG и это при коротком и лаконичном коде. Посмотрите, что и каким количеством и качеством кода делаетя с графикой и представьте что и как можно делать с интерфейсом, если понимать идеологию D3.
А JQuery это — тонны мусора в коде, особенно с ростом проекта.
D3 отображает и обновляет слой данных и отделяет данные от DOM,
а JQuery мешает все в кучу — это как мазать краской холст каждый раз поверх. DOM надо создавать, а не патчить. Data Driven Documents это подход, концепция, а JQuery — не более, чем обертка для обычных ванильных яваскрит функций.
А используют эти библиотеки по сути для одного и того же.
Я когда ищу реализации чего-то или алгоритмы и вижу JQuery в зависимостях, то сразу в помойку этот скрипт и смотрю следующий т.к. в 99% случаях это означает что будет 5000 строк мусора на то, что можно было сделать за 300-500 строк порядка.
Я своим запрещаю эту хрень)) Но это личное дело каждого.
Больше похоже на список распространенных технологий/API/языков о которых необходимо иметь представление.
Учить в таком порядке — убить программиста)
И структурировано странно. Я бы, например, для фронтенда запретил вообще изучать JQuery, как самый большой источник говнокода. А вот D3, который это все делает на много лучше я бы поставил в основы. Уже только это невероятно бы повысило качество и реюзабельность. Весь список с Ангуларами, Реактами, Эмберами и пр. заменил бы на малюсенький riot.js ну т.д.
В общем в 2017-м ждем новых чудо кодеров, тащащих за собой огромные библиотеки из которых они пользуются 5%, при том что даже эти 5: можно реализовать правильно, читабельно и красиво)
Хотя, если встраиваться в команды, наверно лучше жить в этом стеке технологий, курить JQuery с Angular. Здравствуй тормозной и глючный веб)
Кто хочет, тот ищет пути!
DRV10983 — интересная букашка и не дорогая. Почему её в этом открытом проекте не использовали?
В чем плюс именно такой реализации? И думаю круглая форма платы тоже была бы предпочтительнее чтобы было удобнее сделать её частью сервы.
P.S. Отличный проект. Ждем продолжения)
Ну и мне, как пока чайнику в управлении двигателями(все не соберусь никак купить себе «не серву» и поиграть) тоже интересно возможно ли управлять PMSM приводами с помощью L298 или L293d