Переходите от сделок к эквити по дням. 70 эквити — 70 столбцов. Расчет портфеля на VBA займет секунды. Программа оптимизации — минуты. Не лень будет — напишете обработчик на питоне, который берет данные из того же экселя. Просто и компактно.
SergeyJu,
по дням меня категорически не устраивает. У меня половина систем быстрые, у них сделки длятся минуты. Делать одно решение для быстрых, другое для медленных, не мой путь.
Ну и даже если делать.
200 торговых дней*50 систем*6 лет=60 тыс строк, такая же ерунда с количеством.
Дмитрий Овчинников, «200 торговых дней*50 систем*6 лет=60 тыс строк»
200*6=1200 строк. VBA за секунды будет считать и намного больший объем если не построчно работать а обращаться к range.
На уровне портфеля подневная еквити по моему вполне достаточна.
Есть классическое решение konkop, там вообще списки трейдов грузятся и собирается портфель.
Сделали 70 бектестов, получили 70 еквитей. Они не меняются. Загрузили все 70 в столбцы. Посчитали портфельную еквити (vba или формула). Покрутили коэфициенты (вручную или оптимизатором), опять посчитали.
В последочных опять таки загрузили 70 списков трейдов. Отсортировали если надо (прямо в vba, не в таблице). Дальше этот список не меняется. Крутим коэфициенты, считаем.
quant_trader,
потратил все выходные на эксель: VBA, PowerQuiery, динамические таблицы и пр.
Нифига не помогает, 70 тыс строк расчета нарастающего итога по промежуточным значениям убивают процессор в любом раскладе.
Похоже вы с SergeyJu правы, надо делать подневный тест и записывать данные систем в столбцы.
Вопросы с использованием капитала это конечно не закроет, зато можно будет добавить все быстрые системы, посмотреть на соотношение разных портфелей, правильное ли оно. Да и в медленных можно внутренние системы повытаскивать наружу, то есть анализировать не 50 систем, а фактические, которых там несколько сотен внутри.
Дмитрий Овчинников, это просто классическое решение для портфелей и Логунов ниже то же самое предложил.
«Вопросы с использованием капитала это конечно не закроет,»
Возможно и это решаемо. Если вместо столбцов еквити взять столбцы подневных % приращений еквити по каждой стратегии то там можно будет например не просто усреднять с весами а например и суммировать приращения по пересекающимся стратегиям. Насколько я понимаю проблема в этом?
quant_trader,
Спасибо, я и так все суммирую конечно. А с капиталом на дневных нарезках конечно ничего не сделать, но это не беда, с капиталом я в старом файлео легко справлюсь, если удалю там расчёт итоговой эквити и просадка, ведь именно он тормозит.
Добавлю к тому, что написали уважаемые коллеги: логичным кажется уходить в другие решения, но что бы продолжать еще какое-то время жить с текущим подходом, нужна агрегация. Если не подходит агрегация по дням, то можно агрегировать с меньшим ТФ, втч _отдельно_ (как и пишет SergeyJu) считать аллокацию капитала, вероятно используя времена в позиции (и, сооответственно, считать их пересечения, а не тащить все сделки). Можно это сделать в несколько итераций, написав рассчет/аггрегацию для 10 элементов, и выстроить иерархию — агрегируете данные для 10 систем, потом для 10 портфолио по 10 систем итд. (Написав это, я бы еще раз сказал: надо уходить в другие решения)
Дмитрий Овчинников, Вы же на месяцы портф собираете, не на полчаса. Поэтому подневная эквити — достаточно информативно для построения портфеля систем.
В экселе штатный размер листа миллион. Я обычно беру 12 лет, как минимум. Примерно 3000 — 3500 длина столбца. Если число столбцов несколько сот — вообще не напряжно для расчетов.
SergeyJu,
Я собираю портфель систем. Системы есть разные, но, практически у всех сделки внутри дня. У многих несколько сделок в разные стороны внутри дня. Портфельная тема инвестров в акции меня не устраивает. По меньшей мере потому, что общая сумма денег в системах существенно выше капитала и это тоже хочется считать.
quant_trader, если быстрые системы торгуются с большими плечами, понятно, что возникают опасения, что совместные входы в одном направлении могут перегрузить ГО.
Но я лично думаю, что мухи — отдельно, а котлеты должны быть отдельно. То есть контроль лимитов, грубый, можно сделать независимо от решения портфельной задачи.
ves2010,
Так у меня и так на три портфеля все разбито. Причём самая большая проблема с быстрыми. Там всего за год количество строк перерастает в проблему.
Можно еще сделки по каждому алгоритму перевести в простое эквити (только не по дням, а минутки) и потом работать с ними как с «виртуальными тикерами». А тут уже поле для оптимизации богатое. Тот же мультичартс.
Основной мой пойнт — переносить учёт трейдов и расчеты на sql-базу, а в экселе только анализ.
хочется как-то попытаться в автоматическом режиме пооптимизировать итоговые результаты, двигая параметры всех систем.
Это ведь классический curve fitting будет.
Поделюсь своим опытом, ТС он не подойдет, но может какую-то идею дать.
У меня (на данный момент) всего 8 ТС (было штук 15 максимум), торговля внутри дня. В натуре я могу переносить позиции на сл. день, но учитываю для анализа, что они закрыты.
Трейды вбиваю в БД исключительно «теоретические», т.е. результаты без проскальзываний (как положительных, так и отрицательных).
Каждая ТС имеет свой вес, в день могут быть открыты трейды по максимум 3 ТС — с наивысшим приоритетом.
Анализ веду в экселе. Не реже раза в неделю смотрю теоретический иквити, рез-ты (теоретические) по каждой ТС и меняю приоритеты и %риска на ТС.
Какие-то ТС периодически выпиливаются из эксплуатации, добавляются новые.
Важно: эксель фактически использую как толстый клиент, т.е. на VBA там наговнякано изрядно.
В общем то все, чем мы занимаемся это curve fitting. Мы берем curve инструмента и вырезаем из него самые жирные куски. Чем плоха идея повырезать жирные куски из curve портфеля?
Конечно я не буду это делать бездумно, но немного оптимизации подключить хочется.
smooth_operator20,
по самые не могу я даже отдельные системы не оптимизирую.
Простой пример: сейчас весь январь трендовые системы пилит. У многих трейдеров январь в минусе. У меня трендовые системы составляют часть общего портфеля, я в плюсе. Но вопрос, а не мало/много ли у меня трендовых систем в портфеле, решен на уровне здравого смысла. Здравый смысл в таких решениях всегда выдает не самое оптимальное решение. Я хочу по меньшей мере посмотреть весь диапазон возможных вариантов и результатов.
Дмитрий Овчинников, ок, тогда просто посмотри в сторону решения, когда факты хранятся в sql-базе, а анализ или прогон можно, наверное, и в пандасе делать, раз уж это стильно и молодежно))
Данные в экселе хранить, конечно, не вариант.
Ты и сам понимаешь.
С какими-нибудь знакомыми айтишниками в области обработки данных проконсультируйся.
PS Мне кажется, у тебя в таблице фактов полей мало.
Смотрел книжку «Статистика для трейдеров»? Там оч хорошая глава была, как трейды фиксить.
Дмитрий Овчинников, данные можно обогащать — это нормально))
Посмотри главу 13 книжки Булашев. Статистика для трейдера.
Особенно 13.8. Отчет о сделках. И 13.9 потом.
Соглашусь со стеком Python + pandas. То что векторизуется будет очень быстрым + с пандасом работать очень приятно, это как эксель на стероидах)). Ну а что не векторизуется — на голом питоне — даже в этом случае оно конечно мощнее, быстрее, чем эксель. Если питон с пандасом — сразу можно заценить Jupyter.
Replikant_mih, Вы про эксель или про VBA?
Как-то мы пытались применить рэндом форест к ценовым рядам. Писал очень сильный парень, аспирант ВМК. Пока не применили оптимизацию вычислений и не переписали ядерные функции на Си, было ну очень тоскливо. Долго. До суток доходило.
SergeyJu, Эмм, чёт я запутался). Про эксель — я про эксель без VBA. VBA, конечно, расширяет сильно возможности, но хз, мне кажется питон с пандасом и юпитером покруче будет).
Про си, рэндом форест и крутого аспиранта вообще не понял) — это аргумент в пользу того, что питон плох? Или эксель? Если питон… — зачем там писать рэндом форест, в том числе на си) — там же все написано давно). Не пойму короч). Если есть готовые с си под капотом либы на питоне — надо их юзать — удобно и быстро, если нет — уже по ситуации. На готовых либах рэндом форест — ну зависит от гипер-параметров и объема данных, если я много данных заряжу — будет долго, сутки — столько ни разу не заряжал)).
Replikant_mih, слов нет, питон круче. И библиотеки намного обширнее и современнее. Проблема в том, что «любой идиот» может присобачить библиотечку к импорту данных. А каменный-то цветок и не выходит. Отсюда возникают косые-кривые постановки задач, которые не ложатся на стандартные методы. И все, пиши сам на чем хошь.
Насчет Си в Питоне. Стандартный технический прием по ускорению счета тяжелых задач — переписать ядерные функции на более быстром языке. Чтобы те 5% кода, которые забирают 90% вычислений считались раз в 30 быстрее.
Ну, не знаю зачем что-то самому писать, в смысле из каких-то стандартных вещей — тот же случайный лес из примера. Его можно найти в нескольких реализациях сейчас — и sklearn и пайторчи-тензорфлоу тоже его реализовали, вроде, да и ещё наверняка много где — вроде даже есть реализации, задействующие возможности GPU)). Мы только на учебе в учебных целей для лучшего понимания писали на питоне реализации чего-то такого)).
Питон, конечно, очень медленный для таких вещей, но так никто его и не использует — именно из-за производительности. И да, C в помощь если надо что-то тяжелое замутить. Пробовал импортировать простенькие вычисления на C в питон, но для боевых задач не приходилось использовать этот подход пока.
Va Chen, испокон веков на нашей условно русской земле лились реки крови, что характерно братской крови в междоусобных войнах и конфликтах. И большой вопрос, существует ли страна, власть которой уни...
РКК похоже коллекционирует исполнительные производства, уже 44 штуки насобирал. В основном исполнительный сбор по 10 000, в общей сложности где-то 1.5 млн приставы от них ждут.
А в арбитраже завтра ...
Владимир Омск ***, Этот вход у меня был в конце пятницы по 2883.48
Дальше на 2946 посмотрим как оно будет… а так, к примеру, давно шпилек не было, где-нить до 3000...
Купил я значит хату в it-ипотеку, а ее чуть не отобрали Если вы не покупаете квартиры для того чтобы использовать их как хралилице наличных денег, как известный теперь всем полковник Захарченко, велик...
Medved700
StaticUnsafe Фекалии стекают по поверхности унитаза туда, где им и положено быть, а сверху их обдаёт мощный поток, направленный на лица стра...
SP65, кстати а как ваша хромая лошадка пож...
G-7 обдумывают ужесточение потолка цен на российскую нефть
Эта мера подтолкнет Москву к переговорам о «значимом» миреПроект является ранним предложением и все еще может значительно измениться
Про...
это платное ПО?
но за наводку спасибо!
скачал бесплатную, мне нравится, про 50 трейдов это сравнение с реальностью? Т
Ресерчить тоже можно не в Excel ;)
спасибо.
С рисечем у меня проблем пока нет :)
в мультичат надо будет переписать туда все свои системы, чтобы воспользоваться его оптимизацией?
MT4 у меня нет :)
Спасибо, гляну внимательно на QuantAnalyzer
под MT5 тоже есть и после танцев с бубном даже работает!
по дням меня категорически не устраивает. У меня половина систем быстрые, у них сделки длятся минуты. Делать одно решение для быстрых, другое для медленных, не мой путь.
Ну и даже если делать.
200 торговых дней*50 систем*6 лет=60 тыс строк, такая же ерунда с количеством.
200*6=1200 строк. VBA за секунды будет считать и намного больший объем если не построчно работать а обращаться к range.
На уровне портфеля подневная еквити по моему вполне достаточна.
Есть классическое решение konkop, там вообще списки трейдов грузятся и собирается портфель.
А 70 систем куда делись? В столбцы? Так можно и дни в столбцы засунуть. Будет 6 строк.
Если брать подневные еквити то таблица будет 1200 дней * 70 столбцов (или строк) еквитей. Это смешной объем для VBA (при правильном подходе).
PS кажется понимаю — Вы собираете таблицу потом сортируете, это не выглядит оптимально.
Еще можно вообще при бектесте писать текстовую подневную еквити/или сделки в файл, потом в vba работать. Ексель мощная штука.
Эта таблица все время меняется. Она не стационарная у меня.
Сделали 70 бектестов, получили 70 еквитей. Они не меняются. Загрузили все 70 в столбцы. Посчитали портфельную еквити (vba или формула). Покрутили коэфициенты (вручную или оптимизатором), опять посчитали.
В последочных опять таки загрузили 70 списков трейдов. Отсортировали если надо (прямо в vba, не в таблице). Дальше этот список не меняется. Крутим коэфициенты, считаем.
Сортирую я на отдельном листе, потом вставляю уже готовое в файл, иначе полдня пропало🤪
потратил все выходные на эксель: VBA, PowerQuiery, динамические таблицы и пр.
Нифига не помогает, 70 тыс строк расчета нарастающего итога по промежуточным значениям убивают процессор в любом раскладе.
Похоже вы с SergeyJu правы, надо делать подневный тест и записывать данные систем в столбцы.
Вопросы с использованием капитала это конечно не закроет, зато можно будет добавить все быстрые системы, посмотреть на соотношение разных портфелей, правильное ли оно. Да и в медленных можно внутренние системы повытаскивать наружу, то есть анализировать не 50 систем, а фактические, которых там несколько сотен внутри.
«Вопросы с использованием капитала это конечно не закроет,»
Возможно и это решаемо. Если вместо столбцов еквити взять столбцы подневных % приращений еквити по каждой стратегии то там можно будет например не просто усреднять с весами а например и суммировать приращения по пересекающимся стратегиям. Насколько я понимаю проблема в этом?
Спасибо, я и так все суммирую конечно. А с капиталом на дневных нарезках конечно ничего не сделать, но это не беда, с капиталом я в старом файлео легко справлюсь, если удалю там расчёт итоговой эквити и просадка, ведь именно он тормозит.
я кстати делал подобное, когда изучал корреляцию между отдельными системами.
В экселе штатный размер листа миллион. Я обычно беру 12 лет, как минимум. Примерно 3000 — 3500 длина столбца. Если число столбцов несколько сот — вообще не напряжно для расчетов.
Я собираю портфель систем. Системы есть разные, но, практически у всех сделки внутри дня. У многих несколько сделок в разные стороны внутри дня. Портфельная тема инвестров в акции меня не устраивает. По меньшей мере потому, что общая сумма денег в системах существенно выше капитала и это тоже хочется считать.
Но я лично думаю, что мухи — отдельно, а котлеты должны быть отдельно. То есть контроль лимитов, грубый, можно сделать независимо от решения портфельной задачи.
сейчас и делается отдельно, но хочется это делать в одном и том же месте.
имхо можно обойти проблему
просто разбив все на несколько групп
Если коротко, то нет. Длинно, не готов здесь и сейчас обсуждать
итак типа работает
Так у меня и так на три портфеля все разбито. Причём самая большая проблема с быстрыми. Там всего за год количество строк перерастает в проблему.
Пока хромаем с самодельным решением в самодельном тестере. Систем меньше чем у вас, и они все медленнее (Десятки тысяч сделок в бэктесте портфеля).
Не могу порекомендовать этот путь, но с ним можно почти все :)
Это ведь классический curve fitting будет.
Поделюсь своим опытом, ТС он не подойдет, но может какую-то идею дать.
У меня (на данный момент) всего 8 ТС (было штук 15 максимум), торговля внутри дня. В натуре я могу переносить позиции на сл. день, но учитываю для анализа, что они закрыты.
Трейды вбиваю в БД исключительно «теоретические», т.е. результаты без проскальзываний (как положительных, так и отрицательных).
Каждая ТС имеет свой вес, в день могут быть открыты трейды по максимум 3 ТС — с наивысшим приоритетом.
Анализ веду в экселе. Не реже раза в неделю смотрю теоретический иквити, рез-ты (теоретические) по каждой ТС и меняю приоритеты и %риска на ТС.
Какие-то ТС периодически выпиливаются из эксплуатации, добавляются новые.
Важно: эксель фактически использую как толстый клиент, т.е. на VBA там наговнякано изрядно.
В общем то все, чем мы занимаемся это curve fitting. Мы берем curve инструмента и вырезаем из него самые жирные куски. Чем плоха идея повырезать жирные куски из curve портфеля?
Конечно я не буду это делать бездумно, но немного оптимизации подключить хочется.
Выглядит именно так, что взять набор систем, набор параметров — и заоптимизировать их на истории по самое не могу.
по самые не могу я даже отдельные системы не оптимизирую.
Простой пример: сейчас весь январь трендовые системы пилит. У многих трейдеров январь в минусе. У меня трендовые системы составляют часть общего портфеля, я в плюсе. Но вопрос, а не мало/много ли у меня трендовых систем в портфеле, решен на уровне здравого смысла. Здравый смысл в таких решениях всегда выдает не самое оптимальное решение. Я хочу по меньшей мере посмотреть весь диапазон возможных вариантов и результатов.
Данные в экселе хранить, конечно, не вариант.
Ты и сам понимаешь.
С какими-нибудь знакомыми айтишниками в области обработки данных проконсультируйся.
PS Мне кажется, у тебя в таблице фактов полей мало.
Смотрел книжку «Статистика для трейдеров»? Там оч хорошая глава была, как трейды фиксить.
поля фактов ровно те, которые выдает стандартный отчет MT5.
Я даже не понимаю о чем речь, какие еще нужны исходные данные?
Посмотри главу 13 книжки Булашев. Статистика для трейдера.
Особенно 13.8. Отчет о сделках. И 13.9 потом.
Как-то мы пытались применить рэндом форест к ценовым рядам. Писал очень сильный парень, аспирант ВМК. Пока не применили оптимизацию вычислений и не переписали ядерные функции на Си, было ну очень тоскливо. Долго. До суток доходило.
SergeyJu, Эмм, чёт я запутался). Про эксель — я про эксель без VBA. VBA, конечно, расширяет сильно возможности, но хз, мне кажется питон с пандасом и юпитером покруче будет).
Про си, рэндом форест и крутого аспиранта вообще не понял) — это аргумент в пользу того, что питон плох? Или эксель? Если питон… — зачем там писать рэндом форест, в том числе на си) — там же все написано давно). Не пойму короч). Если есть готовые с си под капотом либы на питоне — надо их юзать — удобно и быстро, если нет — уже по ситуации. На готовых либах рэндом форест — ну зависит от гипер-параметров и объема данных, если я много данных заряжу — будет долго, сутки — столько ни разу не заряжал)).
Насчет Си в Питоне. Стандартный технический прием по ускорению счета тяжелых задач — переписать ядерные функции на более быстром языке. Чтобы те 5% кода, которые забирают 90% вычислений считались раз в 30 быстрее.
SergeyJu, Понял теперь.
Ну, не знаю зачем что-то самому писать, в смысле из каких-то стандартных вещей — тот же случайный лес из примера. Его можно найти в нескольких реализациях сейчас — и sklearn и пайторчи-тензорфлоу тоже его реализовали, вроде, да и ещё наверняка много где — вроде даже есть реализации, задействующие возможности GPU)). Мы только на учебе в учебных целей для лучшего понимания писали на питоне реализации чего-то такого)).
Питон, конечно, очень медленный для таких вещей, но так никто его и не использует — именно из-за производительности. И да, C в помощь если надо что-то тяжелое замутить. Пробовал импортировать простенькие вычисления на C в питон, но для боевых задач не приходилось использовать этот подход пока.