Золото вместо нефти?
Доходы от экспорта нефти и нефтепродуктов просели в ноябре на фоне ужесточения санкций до $10,97 млрд, всего за 11 месяцев снижение к прошлому году составило 15%, до $148 млрд. Между тем, Россия...
💼 Снова в школу: сектор «Девелопмент»
Сегодня в 10:00 МСК Академия для эмитентов Московской биржи приглашает на вебинар «Как читать нефинансовую отчетность: сектор „Девелопмент“». Вы узнаете:
📍 О ключевых особенностях отрасли...
Облигации «Акрона» — удобряем портфель валютой
На фоне крепкого рубля и быстро меняющейся конъюнктуры на рынке облигаций внимание инвесторов все чаще переключается на валютные выпуски крупнейших российских эмитентов, прежде всего тех,...
Какая доходность среди облигаций с наивысшим рейтингом надежности и сроком погашения от 3 лет?
это платное ПО?
но за наводку спасибо!
скачал бесплатную, мне нравится, про 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 в питон, но для боевых задач не приходилось использовать этот подход пока.