Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Воспоминания про универ

11 комментариев

Я не фанат высшего образования. Я вообще не фанат организованного образования, т.к. в упор не понимаю, почему это вообще нужно организовывать в какую-то систему. В этом посте я постараюсь описать мой опыт в универе и прочих местах. Но в основном в универе.

Когда я пошел в универ, я уже умел программировать. На первом курсе, куча людей пришли вообще без опыта, и только осваивали Java. Я знал больше чем большинство, но меньше чем те, которые не только знали но еще и имели опыт. А такие тоже конечно были.

В то время, я считал что если ты уже не кодер когда тебе 18, то тебе поздно. Сейчас, смотря на современных детей, я понимаю что планка съехала вниз… дети сейчас программируют с начальных классов, и годам к 10 «написать программу» это для них нормальное явление, хотя конечно они еще не вкуривают программы так же системно, как мы. Но всякие Lego MindStorms и прочие плотно захавали из мозг, а С/С++ и Arduino на курсах робототехники тоже практически стали нормой.

Так вот, к 18 годам я попал в один из «топовых» универов Англии который, впрочем, специализируется в основном на электронике а не на comp sci. И я не сказать чтобы впечатлился тем, что я увидел, хотя свою университетскую программу на то время (2000-2003 год) я запомнил описательно.

В плане программирования у нас была Java и С++. Часть преподавалась как теория, часть как практика в лабораториях (которыми руководили всякие postgrads), а для особо продвинутых студентов (таких как я) были доролнительные занятия под названием Space Cadets где можно было написать что-то более сложное.

Если честно, меня не впечатлило ничего. Было очевидно, что преподавателям было глубоко пофиг на эту джаву, они витали в облаках своих абстрактрых hypermedia и язык знали ровно на том уровне, который им позволял что-то преподавать. При этом, те темы которыми занимались преподы были унылы, академичны и к реальной жизни не относились от слова совсем. Например, все пели песню про semantic web, двунаправленные гиперссылки и кучу всяких других абстракций которые индустрия никогда бы не вредила. Пожалуй это первый раз в жизни когда я почувствовал пропасть между академией и реальной индустрией которая делала что-то полезное.

Практически сразу же у нас начались такие бессмысленные предметы как «формальные методы» — это когда используешь языки формального описания программ которые позволяют, например, доказать их корректрость. Хорошо в теории, но если ты не разработчик NASA или Boeing, тебе такие навыки нафиг не нужны. Особенно при том что сами преподы не могли банально объяснить, как язык Z или B ложился на реальный код. Все это было выкинутым временем и можно было сжать до одной 45-минутной лекции. Хотя исследований на эту тему в академии тоже было уух. В этом предмете я впервые увидел препода, который заваливает тебя десятками статей. Это правда было факультативно, а то бы я повесился.

На первом курсе у нас также был семестр электроники, где мы с осциллоскопом и макетными платами делали что-то с простыми схемами. Этот предмет тоже меня не особо зацепил, просто потому что меня в то время не интересовалал электроника и я не знал как все это применить. В те времена еще не существовало литий-ионных батарей и вся тема с созданием портативной электроники только начиналась. О 18650 я в те времена не слышал.

Еще один предмет что у нас был это data structures and algorithms, который почему-то поместили в один семестр. Там были, в принципе, годные идеи о сложности и том какие структуры и когда использовать, но в то время меня интересовало только одно: как получить результат малой кровью. Напомню, что в то время Java была в зачаточном состоянии, структуры были нетипизированные (они и сейчас по факту нетипизированные, несмотря на дженерики) и все это выглядело немного адово.

У нас была дискретная математика и обычная математика (на достаточно базовом уровне — не «вышка» как в универах в РФ). Это как раз то что у меня получалось лучше всего, как ни странно.

У нас было 2 предмета связанных так или иначе с «логическим» программированием. В одном мы изучали Scheme (этакий LISP), в другом — Prolog. Оба эти языка мы прошли очень поверхностно, и я помню что преподам было очень неприятно когда я приставал к ним со всякими распросами. Мне кажется им самим было глубоко параллельно на все это.

В плане собственно software engineering у нас было несколько предметов. Был предмет Professional Issues который обсуждал всякие soft skills и всякую хрень которая происходит в индустрии, как нужно делать презентации, копирайт и прочие этические вопросы. Мимо меня это прошло все чуть более чем полностью.

Кстати, часть всей этой кухни была игра под названием software management game — достаточно безумное времяпрепровождение для студентов, этакий fantasy league, где нужно выбирать на что твоя компания потратит деньги каждую неделю чтобы завершить проект. Пользы от такого симулятора — почти нуль, но хоть был какой-то контекст чтобы пообсуждать как это все менеджится. Победителям, если я правильно помню, выдали кнут (!) в рамочке.

Групповой проект… эхх, это было немного жестоко конечно. На 3 курсе нам впятером нужно было сделать именно групповой проект, который подразумевал переиспользования уже готового куска чьего-то легаси кода для управления взлетно-посадочной полосой. Не суть важно что там было, я ринулся в код, в то время как другие участники этого процесса решили отдохнуть… ровно до того момента как руководство сказало что баллы за проект будут распределяться поэтапно путем голосования каждого из участников. Тут-то я подумал что все баллы должны быть мне, а коллегам минимум.

Все конечно встрепенулись и начали вкладывать хоть какую-то лепту в общий проект. При этом, пока все работали в notepad, у меня был JBuilder и эффективность моя была все-таки повыше. Также, в этом проекте у меня создался первый в моей жизни профессиональный конфликт. Интересно? Ок, рассказываю.

Из 5 человек в нашем проекте была одна девушка. Она занималась тем, что на каком-то сайтике своем рисовала каких-то смешных анимированных персонажей. Вот собственно и все. Были ли у нее скиллы собственно программирования или нет, никто не узнает, т.к. ее вклад непосредственно в сорцы был минимален.

Но вкладывать что-то ей все-таки хотелось, еще бы, перспектива остаться без баллов мало кого порадует. Так вот, она в какой-то момент решилась делать иконки для нашего приложения. Сделала она иконки и получилось у нее… плохо. Не то чтобы ад, но совсем плохо, так что я вместо этого просто взял готовые у меня где-то иконки а ля Word, всавил эти иконки, и собственно все.

Девушка эта очень обидилась. Она посчитала что я как бы нивелировал ее вклад в проект. Я спросил коллег по проекту, кто прав, но они политкорректно пожали плечами и посоветовали мне чтобы я «не парился».

Ну, как-то вся эта история замялась, но потом эта девушка напечатала отчет, который на самом деле должен был делать тот кто «вел» нашу группу (очередной graduate student), но она его написала для него и послала всем нам чтобы проверить. И я написал ей «честный» фидбэк про то где у нее какие ляпы, приправив мои комментарии изрядной долей D&D-юмора про unholy destruction upon us all и все в этом духе.

Вот тут девушка на меня обиделась уже не на шутку. Нужно понимать, в то время еще не было никаких oppression olympics, поэтому девушка по имени Донна просто написала мне грозное письмо с недовольствами и перестала являться на групповые втречи. Было очевидно, что критика ее сильно задела и она восприняла ее как нападение на ее личность. Вообщем, она рано или поздно вернулась в реальность, но все это было очень неловко, а я, как и мои друзья, не мог понять что это она с цепи сорвалась. Забегая вперед, скажу что все мои попытки работать с женщинами над совместными проектами провалились именно из-за излишней эмоциональности оных. Хочется больше профессионализма!

Отдельно хочется упомянуть мой индивидуальный проект. С 3го курса, как я уже говорил, я попал к психологам — атмосфера на психологии мне понравилась намного больше чем на comp sci, поэтому мой дипломный проект я сделал там, написав систему для проведения онлайн исследований в области психологии (система кстати проработала лет этак 10!).

Так вот, мой основной фейл был такой: в то время, вместо java applets, я использовал плагины Macromedia Authorware, ныне умершей технологии. И не подумал про то, что этот плагин не будет работать в стенах моего собственного факультета. Вообще нигде. Часть людей использовали Linux (а плагин был Windows-only), а на студенческих компах банально не было прав чтобы его запускать в браузере! Так что когда я пошел «защищаться», все пошло не очень хорошо. Я не помню какая у меня была оценка, но невысокая.

Конечно, за 3 года было много «элективов» разной степени булшитистости. Был французский язык (нужно было иметь хоть 1 гуманитарный предмет), странные предметы вроде Artificial Intelligence (прогулял все лекции, готовился за ночь, получил >50%), а также предметы которые я просто забыл.

Какой вывод — да простой вывод из всей этой истории. Универ — это какой-то потрясный способ сжечь 3 года жизни и денег и при этом получить минимом скиллов. Программировать меня не научили… я даже Java забросил на 3 курсе т.к. вышел C# а я всегда хотел работать только на Windows поэтому мне было пофиг на всю эту кроссплатформенность и иже с ним. А на С++ в универе никто не умел программировать тогда и не умеет сейчас. Единственное исключение — это русские! Поэтому они сейчас и рулят там HPC делами.

Будь я сейчас студентом, я бы пошел на математику. Это и сложнее, и более фундаментально, и не устревает, применимо много где. А программирование — это не наука. Это навык. Чтобы программы писать. Ведь ключевым вещам вроде отдадки или юнит-тестирования нас в универе не научили от слова вообще… да и сейчас студентов таким вещам не учат.

Универ офигенен для социалочки. Девушки, пьянки, свободная жизнь в общежитии. Все вот это. Я на 3 курсе посетил дай сотона 50% лекций, а то и того меньше. Были дни когда мы по 4 часа в день играли в теннис. Смотрели фильмы (DVD, тогда еще), играли в игры, я прочитал тонну кних R A Salvatore на своем выигранном PDA (мы заняли 2 место на конкурсе программирования Barclays Capital Programming Challenge), ну и всякие MtG/D&D в больших количествах.

Для социалочки хорошо, а для развития все это какой-то фарс. Да и в исследованиях там сплошной фарс, обман и бессмыслица. Так то. ■

P.S.: тем временем…

Реклама

Written by Dmitri

28 марта 2019 at 1:11

Опубликовано в Education

Кластер для финансового анализа

12 комментариев

В предыдущем посте (посту?) я показал свой комп, но проблема конечно этим не решается. Даже если учесть что у меня сейчас 16×3=48 ядер, этого хватает для того чтобы что-то считать, гонять TeamCity (видите какой я лояльный?) и еще кое-какую сервисную муть. Но этого мало, поэтому касательно вычислительной мощи у меня припасен другой козырь, про который я вам и расскажу.

Когда я ушел из аспирантуры в 2006 году, я не то чтобы уволился. Ну вот не уволился и все тут. Остался на позиции Visiting Researcher (или просто Visitor, чтоб без пафоса) в универе. Зачем? Ну, для начала плюшки простые: я получил от универа кучу софта, доступ в библиотеки (попробуйте поищите статьи в журналах не имея подписки), и другие мелкие плюшки вроде возможности получать академический софт и покупать железки от Altera со скидкой.

Но главное не это. Как я уже говорил, когда я начал заниматься алготрейдингом, я был нищий и вычислительных мощностей у меня практически не было — я гонял нейросети на компе который был HTPC билдом с Пентиум М (ноутбучный!) на борту. Ну, чем богаты тем и рады.

Так вот, тут внезапно оказалось, что мой универ входит в некий консорциум, которому принадлежит второй по размеру кластер в Англии! Хотите глянуть на спеку кластера? Окей. На текущий момент она выглядит как-то вот так:

  • 750 нодов, каждый из которых оборудован двумя ксеонами по 8 ядер (E5-2670) и 64гб оперативки
  • Четыре “толстозадые” ноды с E5-4640 (т.е. 32 ядра) и 256Gb оперативки
  • 12 GPU нодов в каждом из которых по две теслы — сейчас это K20. Одна такая игрушка стоит $5k, что сейчас кажется копейками, но когда-то это было огого!
  • Порядка 10 Xeon Phi 5110P нод которые, как вы понимаете, уже морально устарели.

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

Когда я сунулся во все это я, вообщем-то, тоже был тот еще раздолбай: у меня не было навыков ни в численных дисциплинах ни в программировании. Но я-то знаю как замотивировать себя изучить новый предмет: написать видеокурс по нему! Что я и сделал, записав для Pluralsight курс по High-Performance Computing.

После попадания на кластер, я столкнулся с очевидными ограничениями в работе системы: все данные синхронизованы по GPFS (ухх, InfiniBand, мне б такое!), а поскольку у нод нет своих дисков, это накладывает некоторые ограничения на то, сколько можно всего обсчитать.

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

Кластер сам по себе управляется с помощью MPI. Межпроцессорное взаимодействие я реализую с помощью OpenMP — достаточно бесячего, но работающего кое-как стандарта. Помимо этого, я порой использую SIMD — либо явно (это конечно не особо желательно), либо путем использования оптимизаций компилятора и подстаивания своих циклов так, чтобы это можно было делать проще через #pragma simd и иже с ними.

Что касается собственно того что я запускаю там, в основном это рассчеты на С++ или MATLAB (там лицензия MDCS) которые, как правило, тестируют ту или иную рыночную теорию. Поскольку вычислительных ресурсов чуть более чем дофига, а платить за них не надо (в отличии от, например, Azure), я гоняю очень много спекулятивной или вычислительно-неэффективной фигни которая, вместо того чтобы использовать механизмы machine learning-а (всякий annealing там), пытается по сути брут-форсить анализ путем рассмотрения избыточных комбинаций данных. Это моя визитная карточка — вместо того чтобы делать все умно (и сложно), я делаю де факто Монте-Карло.

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

Спеки нового кластера меня порадовали еще больше — 464 ноды по 40 ядер и 192гб оперативки, особо мощные ноды (которых мало и для них нужно просить допуск — для меня не вариант), а также няшные GPU ноды — 10 нод по 4 GTX1080 и 10 нод по 2 Volta V100. Я пожалуй единственный, у кого есть и навыки программирования CUDA (да-да, по этой технологии я тоже курс сделал, по тем же причинам) а также подходящие задачи чтобы все это амортизировать.

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

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

Written by Dmitri

5 февраля 2019 at 19:21

Опубликовано в Computation

Tagged with , , , , , ,

Пост про мой исследовательский компьютер

2 комментария

Меня неоднократно просили сделать видео компа, который используется для работы поэтому вот, пожалуйста, видосик который можно посмотреть:

А если кому нужна детальная спека, то вот она:

Общая инфа:

  • Thermaltake Premium Core W200 — корпус на 2 (!) компьютера
  • Система водяного охлаждения. Состоит из 100+ частей, так что детально описывать не буду
  • Tina x Maxkey SA Dolch, Kailh Box Jade
  • Logitech MX Master 2S :)

Правая сторона (клиент):

  • Corsair HX1200i
  • ASUS WS X299 SAGE/10G
  • Intel Core i9-7960X
  • Intel Optane SSD 905P 480Gb
  • G.SKILL TridentZ Series 64GB F4-3200C15Q-64GTZSW
  • 2× Nvidia GeForce RTX 2080 Founders Edition, NVIDIA NVLINK 4-slot

Левая сторона (сервер):

  • Corsair HX1200i
  • ASUS WS C621E Sage
  • 2× Intel Xeon Scalable Gold 6130
  • Samsung M393A4K40BB2-CTD 64Gb
  • Intel Optane SSD 905P 480Gb
  • 4× 10-терабайтников Western Digital Gold (WD101KRYZ)
  • LSI 9300 MegaRAID SAS 9361-8i (LSI00417)

…и куча всякой дополнительной минорной утвари (USB контроллеры и т.п.). В процессе сборки умер один PSU (вероятно брак), все остальное успешно работает.

Что осталось сделать:

  • Найти 6 мониторов с разрешением 4К и диагональю 24″ или менее… сложная задача! (кронштейн Ergotech Hex 3 over 3)
  • Перебазировать жетские диски со старого компьютера
  • Перенастроить базы и роботов на новой системе
  • Смастерить для этих компьютеров самодельные бесперебойники из 18650? Возможно!
  • Перенастроить всю кухню связанную с FPGA на новом сервере. Может заодно купить какой-нть новый девайс :)

Мой предыдущий компьютер проработал 10 лет, проработал прекрасно, драйвил до 6 экранов на 1080р, проц на пассивном (!) охлаждении, вообщем о нем только хорошие воспоминания. Что он будет делать теперь — еще не знаю.

Компьютер выше собрал мне мой коллега. Сборка заняла более полугода — титанический труд, за который я премного благодарен! ■

Written by Dmitri

29 января 2019 at 2:01

Опубликовано в Technology

Tagged with , , , , , ,

Хранение и анализ биржевых данных

17 комментариев

Я должен признаться, что когда только начал общаться с коллегами на тему алготрейдинга, инфраструктуры у меня было где-то ровно нуль. Если мне не изменяет память, у меня было меньше 3-х мониторов (сейчас это немыслимо), да и комп был достаточно сомнительный. Поэтому, когда коллега отгрузил мне full order log Московской Биржи за несколько лет, мне пришлось пойти в магазин и купить пару «терабайтников» чтобы все это где-то хранить.

Полный ордер лог оказался просто огромным набором баз SQLite. На каждый день есть две основные базы — ордера и сделки. Естественно что формат этих баз «в лучших традициях». Вот например, допустим вам нужно записать в базу цену актива. Какой вы тип выберете? Правильный ответ тут — конечно же int, целое число, ведь цена имеет фиксированную точность далее которой не имеет смысла копать. Брать float/double нельзя т.к. там сразу теряется представление данных (зато в финмате у нас очень много где именно FP). Что же выбрала биржа?

Не, ну че, нормально так. Это даже не строка, это bcd_char(16,5), хотя я ввиду ограниченности драйвера который я использую вычитываю эту штуку именно как строку и потом просто конвертирую ее в соответствующий тип. Бонусные очки даются если угадаете в какой тип (намек: мы не можем полностью гарантировать сколько цифр будет после запятой, а FP теряет точность…).

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

static uint64_t netEpochOffset = 441481536000000000LL;
static ptime netEpoch(date(1400, 1, 1), time_duration(0, 0, 0));
static int64_t TimeToTicks(ptime time)
{
  time_duration td = time - netEpoch;
  uint64_t nano = td.total_microseconds() * 10LL;
  return nano + netEpochOffset;
}

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

Итак, естественный вопрос, а что же мы собственно хотели от всей этой кухни? На самом деле, обработка данных с биржи — это поэтапная процедура.

Шаг первый — это объединение разрозненных файлов в одну базу. Просто потому что с этим проще работать. Тут уже начинаются проблемы с консистентностью того, что дает биржа. Плюс к этому, начинаются различные вопросы оптимизации, т.к. база на несколько терабайт по определению не может работать быстро если вам нужно выборочно из нее что-то выдергивать. Но именно тут появляются две очень полезные возможности:

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

  • На базе можно производить индексирование и реорганизацию структуры.

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

Следующий этап после того как вы собственно получили базу данных (ордеров, допустим) — это попытка выудить цену актива. Цены, как вы понимаете, формируется из бидов и асков, но у вас их нет! У вас есть только заявки в стакане, и соотственно чтобы получить эту заветную цену, нужно для каждого нужного вам инструмента сформировать стакан и «дотянуть» этот стакан до того момента, когда вам нужна цена.

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

Самый банальный пример анализа по этому делу: это когда ты строишь портфель на основе собственных рассчетов волатильности «я ж умнее всех» и потом хочешь дотянуть этот портфель до экспирации. В этом случае можно сделать ставку на то что рынок достаточно-ликвиден (тут все зависит от гранулярности, конечно, надо перепроверять) чтобы в любой момент можно было делать хэджирование с теми объемами которые нужно. Тут мы либо берем среднюю по больнице цену на краях стакана, либо строим стаканы ограниченной глубины. И конечно это не тиковые данные.

Раз нам нужны не тиковые данные, мы делаем дискретизацию или «квантизацию»: один раз все же строим полный стакан в памяти, но сэмплим этот стакан, например, раз в секунду, минуту, час и так далее. Если вам хочется держать руку на пульсе и следить за перепадами цен, которые могут цепануть ваши роботы, можно вместо краев или среднего (bid+ask)/2 брать high/low/open/close, опять же, все зависит от ваших допущений относительно волатильности.

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

Резюмируя, обработка данных подразумевает как наличие хороших мощностей для хранения и вычислений, т.к. и проработанной инфраструктуры для того чтобы быстро и эффективно получить те или иные данные. Поэтому серьезные конторы вроде GS делают свои SecDB/Slang, а нам простым смертным остается только на коленке писать какие-то небольшие скрипты чтобы хоть что-то посчитать. Но к счастью, порой, и этого хватает. ■

Written by Dmitri

16 января 2019 at 14:51

Опубликовано в Data

Tagged with , , , ,

Мой подход к инженерии

6 комментариев

Вы может заметили что у меня в блоге нет ничего связанно с «хорошими практиками», DDD, «чистым» кодом и всем вот этим. И я если честно не особо фанат обсуждать все эти темы потому что считаю их природно-нерелевантными. Каждый раз когда мне кто-то в социалочке начинает заливать что «твой подход некомильфо», у меня мысль одна — если вы, ребята-айтишники, все такие умные и все знаете, почему вы такие бедные?!

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

Кодогенерация

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

Знаете есть такая шутка — «пиши код как будто следующий мейнтейнер будет агрессивным психопатом который знает где ты живешь». Так у меня есть свой вариант — «пиши код так будто тебе завтра нужно будет его оборачивать в SoC решение». В моем случае, SoC это когда у тебя есть, например, PCI плата с ethernet портом, а на плане как FPGA так и какой-нибудь ARM, и хочется чтобы все это работало быстро и в гармонии.

Две вещи которые я точно генерю почти всегда — это перечисления и сущности.

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

Суть тут в следующем: иногда, тебе нужно чтобы перечисление было тупо числом. Например ты посылаешь код на CUDA, туда что-то иное нельзя пихать. А иногда нужно чтобы к перечислению было приписано куча всяких метаданных вроде например правильной формы описания этого enum-а при выводе. Вот например:

enum class Rarity
{
  Common,
  Uncommon,
  Rare,
  MythicRare,
};
std::ostream& operator<<(std::ostream& os, const Rarity value)
{
  string result;
  switch (value)
  {
    case Rarity::Common: result = "Common"; break;
    case Rarity::Uncommon: result = "Uncommon"; break;
    case Rarity::Rare: result = "Rare"; break;
    case Rarity::MythicRare: result = "Mythic Rare"; break;
  }
  return os << result;
}

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

Сущности, то есть простые классы в стиле POCO (plain old C/C#/C++ object) можно было бы тоже писать руками, но на самом деле нет. И суть вовсе не в штучках вроде паттерна наблюдатель (INotifyPropertyChanged и иже с ним, если мы про дотнет), а в том что очень часто степерь ахтунга обычной структуры идет over 9000, у меня кончается терпение чтобы сделать все через ООП, а делать АОП я не хочу потому что это черный ящик который плохо дебажится.

Хотите посмотреть на лютый ппц из сферы M:tG? Окей. Вот так примерно может выглядеть сущность под названием Mana:

struct Mana
{
  int32_t red{0}, green{0}, black{0}, white{0}, blue{0};
  int32_t  two_red{0}, two_green{0}, two_black{0}, two_white{0}, two_blue{0};
  int32_t colorless{0};
  bool is_red() const { return red > 0 || two_red > 0 || blue_red > 0 || black_red > 0 || red_green > 0 || red_white > 0;
  bool is_green() const { return green > 0 || two_green > 0 || black_green > 0 || red_green > 0 || green_white > 0 || green_blue > 0;
  bool is_black() const { return black > 0 || two_black > 0 || white_black > 0 || blue_black > 0 || black_red > 0 || black_green > 0;
  bool is_white() const { return white > 0 || two_white > 0 || white_blue > 0 || white_black > 0 || red_white > 0 || green_white > 0;
  bool is_blue() const { return blue > 0 || two_blue > 0 || white_blue > 0 || blue_black > 0 || blue_red > 0 || green_blue > 0;
  int32_t cmc() const { return colorless + 
    red + two_red + 
    green + two_green + 
    black + two_black + 
    white + two_white + 
    blue + two_blue; 
  }
  std::string str() const
  {
    string result;
    for (int i = 0; i < red; ++i) result += "R"; 
    for (int i = 0; i < green; ++i) result += "G"; 
    for (int i = 0; i < black; ++i) result += "B"; 
    for (int i = 0; i < white; ++i) result += "W"; 
    for (int i = 0; i < blue; ++i) result += "U"; 
    for (int i = 0; i < white_blue; ++i) { result += "{WU}"; }
    for (int i = 0; i < white_black; ++i) { result += "{WB}"; }
  // и еще дофига такого же ада⋮

Вообще, все что можно кодогенерировать я генерирую. Это упрощает задачу потом переводить это на новые парадигмы. Хоть какой-то контоль за процессом, т.к. в обычной ООП разработке контроля никакого нет, ой, мы сломали все тесты, бежим переписывать.

Да, еще много кодогенерации у меня делается из формул (MathSharp) и из Excel (X2C). Там тоже все очень няшно: помимо математических оптимизаций, можно еще делать хитрые численные перестановки, например выбирать между float и double, делать обработку ошибок и диапазонов. Кстати! Формочки для ввода данных тоже создаются автоматом.

Короче, что я хочу сказать? Что у меня код местами забросан вот всем этим адом, при этом поскольку это сгенерированный ад, я еще могу на него всякие интересные тесты генерить, плюс автогенерация — это бесплатные оптимизации в стиле «давайте засунем несколько байт в один int» (например, на GPU иногда приходится так делать).

Кодогенерация — это не nuclear option, это вообще норма.

Dropbox для всего и вся

У нас очень модно использовать всякие системы вроде Git/GitHub, но я не фанат. Вообще все, что у меня есть, лежит в Dropbox, который просто синхронизируется везде и всегда.

Какой в этом смысл? Ну, я всегда знаю где что лежит. На разных системах одна и та же программа будет писать в один и тот же путь, который засинхронизируется на всех компах. Например, если у вас один из компов настроен гнать юнит-тесты из определенной директории, он всегда будет получить обновленные файлы оттуда и гнать их. Это круче чем сигналы, которые сорсконтрол якобы посылает ТимСити и подобным.

Когда мне нужно синхронизировать системы по Dropbox, я использую… токен-файлы! Прямо как Microsoft Office. Просто создаю например файл в котором написан таймстэмп, другой комп на него смотрит и принимает решения. Брутально но работает.

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

Да, кстати насчет этого. Как я уже говорил, у меня исследовательская позиция, которая «активна» года этак с 2002… ухх, много воды утекло. Зачем мне она? Ну потому что там есть нереально мощный кластер. Иногда мне кажется что я единственный во всем универе кто реально умеет этим кластером пользоваться: на самом деле есть студенты которые че-то шарят в HPC, но они в основном делают курсовые. Вообщем много моего анализа происходит там, но там другая среда: там Linux, InfiniBand, конечно синхронизация файлов между нодами, а для оркестрации используется MPI. Ну, тоже, как вы понимаете, в основном плюсы. И Dropbox конечно там не применим — я просто перекидываю туда свои «долгие» задачи. Это отдельный рассказ, там много тонкостей и не думаю что они кому-нибудь интересны.

Центральный текстовый репо

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

У меня другой подход. У меня есть директория, в которой находится более менее организованная свалка всякого добра которое нужно в разных проектах. Когда приходит время, я просто физически линкую нужный мне файл в проект, тем самым импортируя его не как бинарную либу или .h/.lib а как текст!

Вообще, шаринг кода и либ это нерешенная проблема. Мне уже если честно надоело пересобирать по ночам Boost или QuantLib — конечно, это делает мой CI, но постоянно возникают какие-то косяки, новые флаги компиляции, новые блин компиляторы которые ломают код.

Intel C++ Compiler

Ёжики кололись но продолжали есть кактус. Что не удивительно, т.к. интелевский компилятор, обладающий просто чудовищной поддержкой фич современного С++, при этом дает различные очень хитрые механизмы оптимизации. Помимо этого, у него интересный тулсет профиляции. Не могу сказать что он прям интуитивен, но юзать можно.

Отдельно стоит упомянуть «игрушки» под названием Xeon Phi, которые Intel сначала выпустил как PCI карточки, а сейчас делает их как просто процессоры (делает ли?). Для них, несмотря на x86 совместимость, нужна перекомпиляция интелевским компилятором. Phi — это полумертвая технология, но мне она все равно нравится потому что засунуть комп в комп это всегда круто. Пусть себе работает, 60 ядер, никаких проблем с branch divergence в отличии от CUDA.

CUDA Toolkit

CUDA позволяет считать некоторые data-parallel вещи на GPU. На ней лучше всего считать то, что вы считаете постоянно и регулярно, т.к. разработка сама по себе более затратна и проблемы тут тоже бывают. Естественно, что задачи где много conditional logic лучше тут не гонять, хотя как знать, если правильно дробить, можно все равно получить хороший прирост.

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

Что меня больше всего удивляет в куде так это NSight, система удаленной отдадки. Это гениально т.к. твой GPU не должен находиться локально.

Плохой код

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

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

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

Я тут подчеркну, что я не считаю все эти шаги и действия «скиллами программирования»… это common sense. Ты хочешь сделать все чуть более упорядоченным, снизить энтропию. Мне, к счастью, не нужно например чтобы код кем-то читался. Я использую сокращения которые остаются у меня в голове, я использую нестандартные фичи языка когда это удобно. По крайней мере, в отличии от F#, я могу спокойно вернуться в свой код через пару месяцев и все более менее понятно.

Вот такая вот «инженерная культура». Или ее отстутвие. ■

Written by Dmitri

19 декабря 2018 at 23:13

Опубликовано в Engineering

Обучение математике для quant finance

20 комментариев

Есть такая хорошая фраза — quit while you’re ahead. Уйти из игры до того, как ты стал немощный и уже не можещь даже номинально отрабатывать те деньги, которые тебе платят. Меня эта фраза всегда и драйвила, потому что я прекрасно понимал, что ничто не вечно. Собственно поэтому я всегда искал себе последнюю сферу деятельности, то есть что-то что может раз и навсегда закрыть хотя бы финансовый вопрос.

Поймите меня правильно — у меня на самом деле очень много хобби и много всяких интересных проектов (например, постройка дома) которые ведутся в параллель. Но количество именно профессиональных занятий, кмк, весьма ограничено ввиду того, что чем старее мы становимся, тем сложнее постигать какие-то новые области. А мне, честно говоря, чертовски надоело что знания в ИТ устаревают, поэтому я хотел пойти в сферу, где хотя бы фундаментальная база знаний в каком-то смысле «закреплена» и является вечной, даже если детали реализации придется периодически подкручивать.

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

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

Во главе всего стоит, конечно, статистика — предмет, который я всегда ненавидел и начал хоть как-то понимать только когда пошел в аспирантуру. И то, начал понимать только когда начал косячить в экспериментах, а мой научный руководитель начал показывать мне ошибки в моем анализе (и это в SPSS, где все за тебя машина делает).

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

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

Ключевым с точки зрения финмата является не только знание того что такое стандартное отклонение (я кстати, как и Талеб, не фанат всего этого) или то или иное распределение, а оценка. Оценка, то что называется estimation, позволяет нам оценивать параметры распределения случайной переменной на основе некоторых тестов. Зачем это надо? На самом деле все просто: в финмате очень много времени посвящено анализу процесса цены и подгонки его под тот или иной процесс. Естественно, что идеально оно ложится не всегда, но нужно же хоть как-то понять, какая модель лучше всего подходит к тому или иному активу. Это называется calibration.

С базовыми знаниями статистики уже можно начать разбираться в анализе временных данных. Опять же, есть хорошая книга (Analysis of Financial Time Series, Tsay) которая с примерами на R расскажет вам про такие вещи как стационарность, GARCH, и все вот это. Параллельно с этим я бы советовал взять почитать какую-нибудь книгу по истории статистического арбитража, т.к. там очень хорошо рассказывается про то, с каких стратегий люди начинали арбитражить. Естественно, что мир сейчас намного сложнее, но все равно, это очень интересное чтиво.

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

Есть хорошая книжка Brownian Motion Calculus (Wiersema), которая немного открыла мои глаза на всю эту кухню. Например, я раньше не мог думать в терминах «матожидание матожидания» (E[E[X]]) потому что мой мозг не был настроен на подобные вещи. Эта книжка оказалась хорошей переходной литературой от «бытовой» статистики до чего-то применимого.

Если говорить про процессы цены, то для этого есть целый отдельный раздел математики под названием Стохастика (stochastic calculus). К сожалению, порог входа в эту область достаточно высок, и подразумевает что вы знаете как классический анализ (а это минимум год вашей жизни) так и теорию меры — один из, вероятно, самых неприятных предметов в математике который существует. Но к сожалению, все книги, в т.ч. и основная книга которая у нас используется (Stochastic Differential Equations, Ocksendal) используют measure-theoretic язык чтобы донести свои идеи. К этому привыкаешь, но привыкаешь очень медленно. Кстати, анализ и теория меры приводят к серьезной «профдеформации» в голове со всякими там эпсилон-окрестностями и другим шумом. Плюс, конечно же, все это подразумевает что вы знаете дифф.ур.-ы на нормальном уровне, но с этим не должно быть каких-то серьезных проблем.

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

Да, пока не забыл, для всей этой кухни есть, конечно, свои языки программирования. Если говорить чисто про анализ, то тут используется все что душе угодно: R, Python, MATLAB, новые языки вроде Julia (SPSS не вариант, сорян). Когда у вас небольшие объемы данных, все нормально. Вот когда вы уже начинаете строить свою собственную инфру (RAID-ы всякие) для данных и анализа, тогда вам возможно придется перейти на что-то потяжелее. Основной язык финансовой инженерии — С++. Так что плюсы, которые используются на стороне исполнения, знать нужно. Они используются на классическом железе, но также С или С++ (зависит от ситуации) используются на аппаратных ускорителях. Так что С++ нужно знать и понимать без вариантов. У Mark Joshi есть книжка которая индикативна тому что реально пишут… for better or for worse.

Раз уж мы заговорили про программирование, у вас конечно должны быть навыки численных методов. Например, как интерполировать улыбку волатильности чтобы найти искривление, которое рынок почему-то не учел? Ну, надо использовать метод координатного спуска (кажется это Levenberg-Marquardt по-буржуйски), а это численная процедура. Тот же подсчет функций плотности по нормальному распределению делается численными методами (Abramowitz-Stegun, до сих пор где-то книжка лежит) которые тоже нужно знать и понимать. Еще было бы вообще здорово разжиться интуицией касательно того, когда нужно делать single/double floating point а когда вообще fixed-point (!). По секрету скажу, что у меня, особенно когда нет чего-то мерзко-итеративного, вычисления все single-point; сейчас single/double на CPU работают более-менее одинаково, а вот на GPU… это другая история.

Все что я описал выше займет годы изучения. Нет никаких коротких путей, и не нужно забывать, что помимо всего того что я перечислил выше (а также то, что я забыл), еще нужно разбираться в финансовой стороне дел (даже банальный money/risk management), плюс нужно кодить все это. Поскольку большинству людей это нафиг не надо, проще на 2-недельные курсы в местный форекс сходить и слить все, имеем то, что имеем. Интересно, что даже в профессиональных трейдерских сообществах (например смартлаб) мало кто знает эту кухню, ведь большинство людей занимаются тем что мы именуем systematic trading. Настоящих квантов мало, и в основном они сидят в банках и фондах, а не у себя дома. ■

Written by Dmitri

15 декабря 2018 at 11:44

Опубликовано в Mathematics

Tagged with ,

Заметка про ботов

15 комментариев

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

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

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

К чему я это пишу? А к тому что всей это идиллии, в долгосрочной перспективе, придет конец. У нас уже есть пример прихода индустриальной революции, но там люди достаточно легко отделались — те, кто делали иголки вручную, стали операторами оборудования по производству иголок. Теперь же операторов попросту не будет. Вот скажите, куда пойдут работать миллион водителей, когда автомобили будут сами ездить? Водить самолеты? Танкеры? Может водить машинки в компьютерных играх?

На самом деле нет. Единственный их шанс — это идти делать роботов. Чем собственно я и занимаюсь, ведь я пишу софтверных ботов, которые автономно делают некоторые действия сами по себе, на основе некоторых правил.

Приведу пример бота которого я написал сегодня. Как вы знаете, в РФ можно ввозить беспошлинно до EUR1000 на одного человека. Если вам нужно ввезти товаров на большую сумму, посылки нужно разбить и послать на несколько человек. На стороне отправщика (freight forwarder) есть услуга по консолидации, когда несколько небольших посылок тебе складывают в одну большую коробку. Очень удобно.

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

Этот бот — это конечно очень небольшой, тривиальный бот. Я бы сам мог попробовать покомутировать посылки просто на листке бумаги. Но с посылками все не очень просто: например, есть посылки с зимними вещами (шипованные покрышки, например), которые не имеет смысл откладывать на потом. С другой стороны, есть посылки которые не к спеху, хотя боту следует помнить, что срок бесплатного хранения посылки на складе не бесконечен и ее все равно рано или поздно придется послать.

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

Естественно, что владельцы некоторых сайтов пытаются детектировать ботов. Делаеться это всяким javascript-ом который, например, хочет чтобы мыши прямо прошлась по кнопке сабмита а, в ином случае, выдает вам на ружу капчу в стиле «выберете все картинки где автобус». Это не очень приятно и порой с этими выскочками очень сложно бороться.

В конечном счете, мне захотелось стричь с ботов бабло. Я бота написал, пущай он идет в «эти ваши интернеты» и приносит лавэ, пока я греюсь на солнышке на Канарах. Сначала я хотел сунуться в покер, но к тому времени как я затеял всю эту канитель, в покере уже было over 9000 ботоводов — настолько, что по текущим оценкам, где-то 50% всех учатников покер-румов это боты. Опять же, владельцы покер-румов как-то пытаются с этим бороться, но не особо успешно т.к. по сути дела любое их действие тут же отыгрывается умными ботописателями.

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

Я написал достаточно много всяких ботов, не связанных с алготрейдингом. Например есть боты которые мониторят банковские счета, есть боты которые транслирут медленные сайты так, чтобы я мог комфортно с ними работать (это я про любые тормозные сайты, начиная со всяких форумов Microsoft и заканчивая, простите, YouTrack-ом). Автоматизация некоторых процессов в соцсетях тоже работает «на ура» — например, я хочу дать человеку ссылку на книгу, но ссылки под рукой нет — я пишу название и автора книги, как помню, а бот потом переписывает мой комментарий уже с правильной ссылкой на Amazon. Конечно, все это в основном мелочи, но они делают жизнь чуть более интересной. Вот вам еще пример: как-то я нашел издательство, которое выдавало постранично свои книги в открытый доступ. Естественно, я написал бота который из этих страниц делал полноценные PDFы.

Вообще, с ботами у меня очень много примеров. Касательно инфраструктуры, единственная проблема с теми ботами что работают в интернете — это взаимодействие с браузером. Не все так просто, и запуск вагона разных потоков на вкладки браузера быстро приводит вас к тому, что ничего толком не работает, не хватает памяти, и так далее. Тут у меня подход прост: я агрегирую всех ботов в один сервис, который просто запускает их по очереди. Ведь по сути механизм работы ботов это polling, поэтому нет проблем чтобы этот поллинг для разных сайтов делать в разное время.

По сути, вся алготрейдинговая кухня — это тоже боты, только боты более опасные, т.к. с плохо запрограммированным ботом можно попасть на маржин колл. Рыночный бот также намного больше проверяет/валидирует т.к. биржа это одна большая подстава и если вдруг польются неправильные данные, никто в этом не виноват, лося перекинут на трейдеров. Смысл бота заключается в том чтобы держать какую-то позицию, постепенно перестраивая ее, мониторя рынок, и возможно даже взаимодействуя с другими ботами — ведь высока вероятность, что у этого бота с другими могут быть или пересечения по инструментам или один общий кошелек. Также, биржи очень не любят когда например один бот бьет в заявку другого бота, если оба аккаунта зарегистрированы на вас конечно же. Все это называется красочным словом «перелив» и наказывается оно штрафами.

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

Written by Dmitri

12 декабря 2018 at 18:55

Опубликовано в Programming

Tagged with