Олег Иванов, потому что мне не хочется сохранять отдельный браузерный слой и локальный HTTP-сервер только ради отображения интерфейса… во вторых задача desktop — быть нативным Windows control plane: запускать процессы, работать через IPC, показывать большие объёмы данных, контролировать сервисы и восстанавливаться после сбоев, в третьих интеграция с Go/RUST 

ИИ вообще не вариант — потому что он больше хлама наделает, чем толковых вещей...  под ИИ нужен архитектор/разработчик с хорошим бэкграундом, которого как раз таки и ищу… нужен десктоп без багов

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

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

ARANEA — совсем другой проект и по архитектуре, и по внутренней логике. У нас собственное вычислительное и торговое ядро на Go/Rust, своя модель данных, оптимизатор, Position Management, микросервисы и контур исполнения заявок.

Я не хочу тратить время на изучение чужого frontend-кода, отделение его от чужой архитектуры, копирование компонентов и последующую адаптацию под ARANEA. Такая «бесплатная» основа может обойтись дороже самостоятельной разработки из-за несовместимых моделей, скрытых зависимостей, технического долга...

Мне проще и правильнее сразу создать собственное C# WPF-приложение под контракты ARANEA. Поэтому я ищу специалиста, который спроектирует desktop-интерфейс специально под наше Go/Rust-ядро, а не будет переделывать чужой торговый терминал.

Александр Сережкин, 

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

Если есть сильная боль, кровь, высокая температура, спутанность сознания, признаки обезвоживания или рвота долго не прекращается — нужна медицинская помощь

Михаил Шардин, как понять для чего? 

мат. расчет оценки стратегий в разных состояний рынка и разными системами управления, кривая же как итог оптимизации

го для оптимизации — раст для торговли ...

могу порекомендовать - 

1. Strategy layer
   Только генерирует намерение: открыть/закрыть/изменить позицию. Не считает брокерскую позицию и не знает деталей исполнения.

2. Execution layer
   Отправляет заявки, получает статусы, fills, ошибки, частичные исполнения. Это адаптер к брокеру/бирже.

3. Position ledger
   Главный внутренний источник правды по позициям стратегий. Строится только из fills/events, а не из текущего ответа брокера.

4. Position manager / risk
   Работает с внутренней позицией: SL/TP, trailing, лимиты, сопровождение, закрытие.

5. Broker snapshot
   Отдельный слой фактической позиции у брокера. Его задача — сверка, восстановление, контроль расхождений, но не основная бизнес-логика стратегии.

6. Reconciliation
   Сравнивает внутренний ledger с брокером и решает, что делать при расхождениях: warning, block trading, force sync, manual review.

Главная рекомендация: не смешивать strategy position и broker position. Стратегия должна жить от внутреннего ledger, брокер — только подтверждать реальность и помогать ловить рассинхрон.

Ключевое: не вести позицию “из брокера наверх”. Лучше вести ее “из событий вниз по контуру”.

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

<code>Strategy
-> Signal/Intent
-> Execution
-> Fill events
-> Internal ledger
-> PM/Risk
-> Broker reconciliation</code>

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

Пример с MFE хорошо показывает связь TSLab и ARANEA.

В TSLab это обычный кубик из TSLab.Script.Handlers.dll:

<code>TSLab.Script.Handlers.MFE
Execute(IPosition pos, int barNum) -> double</code>

По смыслу он берет MFE позиции на выбранной свече. В API TSLab это выглядит как:

<code>pos.OpenMFE(barNum)
pos.OpenMFEPct(barNum)
pos.MFE()
pos.MFEPct()</code>

То есть MFE — это максимальный возможный доход позиции от цены входа до выбранного бара / закрытия сделки.

В ARANEA логика та же, только она вынесена в расчетный контур:

<code>func MFE(isLong bool, entryPrice, maxH, minL float64) float64 {
    if isLong {
        return maxH - entryPrice
    }
    return entryPrice - minL
}</code>

Для процентов:

<code>mfePct = mfeAbs / entryPrice * 100</code>

Для long берется максимум High после входа:

<code>MFE = max(high) - entryPrice</code>

Для short наоборот:

<code>MFE = entryPrice - min(low)</code>

Поэтому перенос логики между TSLab и ARANEA не является проблемой. Я изначально делал совместимые по смыслу сущности: PM, параметры, MFE/MAE, stop/take/trailing. Разница в том, что в TSLab это кубик внутри визуального конструктора, а в ARANEA это часть бэктестера, оптимизатора и торгового движка, которую можно массово считать по миллионам профилей.

Vadim S, 
1. Основной стек ARANEA — Rust/Go. На нем написаны вычисления, оптимизация, бэктестер и торговый движок. Это не только оптимизатор, а полный контур для проверки, расчета профилей и дальнейшей работы с торговой логикой.
2. С переносом в TSLab проблем нет. Когда я создавал ARANEA, я изначально брал конфиги и логику расчетов из TSLab: названия параметров, PM, правила, структуру оптимизации. То есть ARANEA считает ту же логику, но быстрее за счет другого стека и другой архитектуры вычислений.

После оптимизации получается конкретный профиль: параметры входа, фильтры, PM и настройки. Его можно перенести обратно в TSLab вручную через кубики или переписать в кодовый модуль. Разница не в логике стратегии, а в том, где она считается и исполняется.

Открывать доступ к ARANEA как к программе я не планирую. Рассматриваю два формата: оптимизация стратегий под заказ или партнерство в разработке ПО/торгового контура.

Согласен, точнее сказать не “сигнал портится”, а “меняется качество ситуации после сигнала”. Сам факт сигнала уже произошел, но дальше каждый бар меняет контекст: цена, объем, MAE/MFE, волатильность, расстояние до уровня, скорость движения.

Я как раз описываю не модель “запрограммировал стратегию под конкретный PM и подогнал stop/take”, а другой слой: сначала измерить, что происходит после входа, и уже по изменению показателей выбирать подходящий PM.

То есть не сразу: сигнал -> stop/take -> лучшие параметры.
А сначала: сигнал -> поведение после сигнала -> оценка качества ситуации -> выбор управления позицией.

Не, не дипфейк :)

Просто тема такая, что в три абзаца не влезает. Тут не “купил/продал”, а входы, выходы, PM, отсечения, OOS, CPU/GPU и вся кухня вокруг исследований.

Если где-то накосячил в логике или цифрах — тыкай, обсудим. А что длинно, да, грешен.

Хороший пример. Но по сути вы описали не одну стратегию, а уже готовый контур отбора: 300 вариантов одной логики, 8 критериев, Excel, распределение денег, комиссия, ролловер и 7 лет OOS.

Именно это я и автоматизирую в ARANEA, только без ручного Excel-слоя и с масштабированием на большее число правил, PM, активов и таймфреймов.

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

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

Пример с результатами я буду показывать на той же банальной идее из статей: ложный пробой дневного уровня, те же общие правила, те же “краски” и тот же контур отбора. Без деталей, которые превращают это в готовую торговую инструкцию. Если бы цель была похвастаться результатами или открытиями, я бы начал серию не с “2 000 000 вычислений в секунду в TSLab”, а с “2 000 000 в месяц на TSLab”. Но это была бы уже совсем другая статья.

Я не пытаюсь показать “супер-пупер подход”. Наоборот, подход довольно логический: сначала понять, что именно считаем, потом отсечь бессмысленные ветки, потом проверить не одного чемпиона, а семейства профилей, потом смотреть out-of-sample/правую сторону. Для меня “супер-пупер подход” — это скорее когда быстро нашли лучший набор параметров по одной метрике и отправили его в бой. Вот это как раз путь на убой.

По рынкам: речь не только про акции. ARANEA строится как контур под разные рынки: крипта spot/futures, MOEX, forex, US stocks. TSLab в статьях используется как понятная визуальная точка отсчета, а не как место, куда я пытаюсь запихнуть весь мульти-рынок и переключение фьючерсов.

По тестированию: суть везде одна. Можно прогнать 200-300 стратегий вперед-назад, поработать с аналитикой, потом запустить их в бэктест или на правую часть истории. Это мало чем отличается от проверки на правой стороне графика: важно не то, где именно нажата кнопка, а выдерживает ли профиль новые данные, соседние параметры, комиссии, просадку и смену рыночного режима.

Поэтому “лопата” здесь не самоцель. Инструмент нужен не ради красивой скорости, а чтобы не путать исследование с подбором лучшей строки в таблице. Результат для меня — это не один красивый equity-график, а набор профилей, которые прошли отбор, правую сторону и не развалились при нормальной проверке.