Избранные комментарии трейдера _sg_

по

kvazar, если переписывать робота, то вам однозначно надо уходить от постоянного запроса тиков из базы. Это неправильно, хотя понятное решение с минимум ошибок. MS SQL Server очень прожорлив к памяти, хотя его и можно настроить.
Берете с гитхаба библиотеку луашарп — тики у вас уже есть. Дальше делаете подписку роботов на событие OnTrade ( FinSerfing может помочь). Да, это сложнее.

Все тики собираете в базу также через ODBC в SQLite/MS SQL, и при старте робота запрашиваете нужную глубину. Готово. ))

Кстати, активные запросы знатно убивают SSD диски.
avatar
  • 20 мая 2020, 09:31
  • Еще
kvazar, есть только то, что касается qsh и на С++. С# мне не нужен, но я видел на сайте кускальпа библиотеку классов C# для работы с qsh. Этого должно быть достаточно для нуждающегося.
avatar
  • 20 мая 2020, 09:22
  • Еще

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

avatar
  • 20 мая 2020, 07:05
  • Еще
kvazar, ну, хотя бы переход на SQL будет каким-то поводом встряхнуть мозгами) Я вообще СУБД никогда не пользовался, разве что когда-то немного с примерами SQLite игрался. Поэтому и спросил в чем там профит от использования СУБД, вдруг лично мне как раз этого не хватает чтобы откопать свой персональный грааль))
А так, классы C# для работы с qsh вроде ведь доступны, просто бери и используй (не то что некоторым заново на С++ все это реализовывать надо было). День торгов по РИ вместе со всем ордерлогом там вмещается в ~10Мб, а если в текст распаковать — то больше 1 Гб может получиться. Мало ли, вдруг заинтригует. В конце концов, можно тики хранить в .qsh, а сами файлы (либо ссылки на них, относительные пути) уже в БД записывать. Вполне себе функциональная вещь должна получиться))
avatar
  • 20 мая 2020, 00:12
  • Еще
Не знаю насколько рабочие, но во тут у Турбированного Паскаля есть репы: https://github.com/tp55?tab=repositories
avatar
  • 17 мая 2020, 22:56
  • Еще
Самая популярная и полезная формула дисперсии: Var[x] = E[x^2] — (E[x])^2

Про то как меряются HV и IV, новичкам может быть интересно https://smart-lab.ru/blog/549787.php
avatar
  • 17 мая 2020, 16:50
  • Еще
https://smart-lab.ru/blog/534384.php 

Не факт что в новую версию подключится и будет работать — но что поменять писали вроде. Норм старт, весь минимум есть. Поиском по смартлабу можно много чего отыскать.
avatar
  • 17 мая 2020, 13:51
  • Еще
noHurry, 
theta по определению уже дневной PnL от распада
Я придерживаюсь определения, что тэта — это частная производная стоимости опциона по времени до экспирации. Так как время я измеряю в долях года — и тэта у меня получается в годовом масштабе. Приводить ли к другому масштабу — это уже вопрос того, для чего конкретно будут использоваться греки.
причём если она выражена в годах, то на 365 уже один раз поделили
Если она выражена в годах — как раз её ещё ни разу не поделили. Это первое число на картинке — расчёт тэты как частной производной.

Второе число — приводим тэту к дневному масштабу, используя линейную аппроксимацию PnL_theta=theta*dt, dt=1/365.

Третье — приводим все параметры (время, ставку, волатильность) к дневному масштабу, и тогда тэта как частная производная стоимости опциона по времени до экспирации получится на дневном масштабе. Ставку в данном примере я не масштабировал, т.к. она всё равно равна нулю.

Единицы измерения у этих трёх чисел — $/year, $/day и $/day, соответственно. Чтобы преобразовать $/year в $/day нужно поделить на 365; для обратного преобразования — умножить.
avatar
  • 31 марта 2020, 15:31
  • Еще
noHurry, Обычно в финансовой математике время измеряют в долях года. Соответственно, продифференцировав стоимость опциона по времени до экспирации получим тэту на годовом масштабе. Вот её многие калькуляторы и делят на 365, чтобы привести к дневному масштабу, и это преобразование тэты надо обратить, чтобы формула sigma=sqrt(-2*theta/gamma)/S работала.

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

Оба варианта тэты правильные. Но про единицы изменения (currency/day или currency/year) забывать нельзя.
avatar
  • 31 марта 2020, 01:04
  • Еще
Eugene Logunov, не считаю вол из цены стрэддла напрямую. Цена стрэддла берется прям из стакана как опорный размер прогнозируемого рынком в натуральной величине (пунктах) диапазона движения цены за срок до экспирации. Если хочу целиться по размаху — подбираю такой, который на истории дает мне возможность быть в плюсе в нужном проценте ситуаций, на разных временных подлежащих окнах смотрю это. И дальше привод следит за тем, когда цена будет как мне надо. Или встает сам котировать по этой цене.
avatar
  • 30 марта 2020, 11:00
  • Еще
Волатильность из цены стрэддла как считаете?
Что-то типа 1.25*(C_ATM+P_ATM)/(S*sqrt(T))?
avatar
  • 30 марта 2020, 10:55
  • Еще
Andrew Morozov,
Спасибо за Ваш ответ. Интересно.
Теперь понятен Ваш подход. Похож на классический и правильный, но несколько несовременный на мой взгляд.
В настоящее время в результате эволюции софтверных архитектур фокусировка на конкретных языках исчезает.
В настоящее время Приложения среднего уровня и, тем более приложения уровня Enterprise, проектируются в виде множества микро-сервисов с «шиной данными» между ними.
В результате для реализации конкретного микро-сервиса разработчик выбирает наиболее подходящий для этого язык программирования и реализуют его наиболее оптимальным образом.
Взаимодействие между сервисами происходит по «шине данных».
Конкретный сервис инициализируется и подписывается на получение необходимых данных через Контроллер шины данных. То есть, сказал в коде new, а потом subscribe. И все. Данные прилетают сами. Используются Push-технологии. И никто уже не думает, что из чего вызывать и не циклится на этом.
Причем такая архитектура одинаково хорошо работает и для Intranet-сетей и для Internet, ну а для Desktop тем более.
Даже Moex, к моему большому удивлению, начала иcпользовать Push-технологии.
А дискуссии что из чего вызывать уже не актуальны.
avatar
  • 29 марта 2020, 21:13
  • Еще
Все несколько проще…  хотите купить нефть по 25$, продайте на нее Пут на 25 страйке. Фактически, это и будет отложенный ордер, это намного более рациональный вариант, чем, например, поставить лимитку во фьючерсе с риском, что цена может не дойти пару центов до 25$ и развернуться обратно, оставив без позиции.
avatar
  • 29 марта 2020, 11:34
  • Еще
Акции более рискованные. И то что они упали на 50% это может быть только начало. Риск еще больше и нервов помотает больше. Как вариант купить акции и продать дорогие коллы. При росте прибыль ограничена. При снижении же премия от дорогих коллов поможет счету
avatar
  • 21 марта 2020, 19:48
  • Еще
 продавайте колы  на то с чем готовы расстаться
avatar
  • 16 марта 2020, 13:46
  • Еще
продавайте путы на то чем готовы владеть
avatar
  • 16 марта 2020, 13:45
  • Еще
Поддержать общение на Вашем уровне мне трудновато, но что если прогнозировать не точку, а диапазон (volatility cones, vol distribution, see «Volatility Trading» by Euan Singlair, chapter 2 особенно)
avatar
  • 15 марта 2020, 11:32
  • Еще
....все тэги
UPDONW
Новый дизайн