Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 1800
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Оптимизируемые параметры и зоны роста падения баланса. Мысль интересна не оптимизацией, а вытащить значимые характеристики для зон роста падения баланса, но наука говорит что это сложно или невозможно через какие либо характеристики ВР при наличии СБ. А находить мат. модели описывающие ряд с достаточной точностью сложно, и не понятно какой размер ВР необходим.
Мне больше симметричные условия кажутся более правильными. Ряд может и перевернуться.))))
Наука может говорить много чего, но надо попробовать и проверить, какой есть потенциал, может идеально нельзя, а неидеальный вариант будет достаточен для улучшения показателей в целом.
Может проще искать Х случайных из N?
Если работать с номером комбинации, то надо эту комбинацию внутри строить из номера.
А номеров комбинаций может быть огромное число. Например для выбора 10 из 100. Будут миллионы или миллиарды (что-то в какой то степени). Как вы будете решать, какую комбинацию брать? 1,2, 158451, или 5454554 ?
Случайную уникальную проще найти, просто рандомом выбираете 1 из N., потом второй и т.д. до Х-го.
При выборе если элемент уже отобран, то пропускаете дубликат и повторяете выбор. Т.е. будет попыток больше чем X. Например если будете брать 90 из 100, то будет очень много дублирующих попыток.
Для скорости, можно выкидывать отобранный элемент из N массива и выбирать из N-1 оставшихся. (Меняете отобранный элемент с последним и укорачиваете массив на 1.) Таким способом ровно за Х попыток найдёте Х случайных элементов. Если элементов N > 3000, то генератор рандома лучше брать не встроенный, а посложнее. Сравнение рандомов тут.
Цель именно в переборе. Из 250 000 листьев получилось 15 000 уникальных сплитов. Полный перебор листьев с 3 сплитами займет примерно 250 дней, как я прикинул, на одно значение целевой. Думаю, что сплиты нужно сгруппировать, для этого выделить начальные сплиты и искать сплиты активирующиеся на их области, а уже потом производить перебор отдельно каждой получившейся группы. Такой подход значительно сократит число комбинаций.
А там точно есть формула, позволяющая по индексу получить комбинацию? Можете её написать, пожалуйста.
Там не формула, а алгоритм. Посмотрите Окулова, там немного и несложно.
Там не формула, а алгоритм. Посмотрите Окулова, там немного и несложно.
Я вот скачал и посмотрел - спасибо!
Если оценили как "несложно", то видимо разобрались, а я вот нет - язык программирования там мне не понятный, в текстовом описании недосказанность, могу ли Вам задавать вопросы по материалу?
Я вот скачал и посмотрел - спасибо!
Если оценили как "несложно", то видимо разобрались, а я вот нет - язык программирования там мне не понятный, в текстовом описании недосказанность, могу ли Вам задавать вопросы по материалу?
Если в меру, то задавайте. Идея там простая - строим массив (двумерный) из всех сочетаний и потом берём строку (или столбец) по номеру. Два варианта - либо храним массив, либо каждый раз считаем его заново (экономим либо память либо время)
Вот пример на R:
Если в меру, то задавайте. Идея там простая - строим массив (двумерный) из всех сочетаний и потом берём строку (или столбец) по номеру. Два варианта - либо храним массив, либо каждый раз считаем его заново (экономим либо память либо время)
Вот пример на R:
Массив строится через циклы, а это трата времени, не очень подходит. Интересен вариант нахождения значения расчетным путем, без предварительной полной таблицы.
Массив строится через циклы, а это трата времени, не очень подходит. Интересен вариант нахождения значения расчетным путем, без предварительной полной таблицы.
Не уверен, что существует такая формула.
Не уверен, что существует такая формула.
Должен быть какойто алгоритм, а то получается, что для 15000 элементов по 3 комбинации нужно массив в памяти держать на 4 терабайта! А даже больше, это я посчитал, если на 1 элемент тратить 8 бит.
Должен быть какойто алгоритм, а то получается, что для 15000 элементов по 3 комбинации нужно массив в памяти держать на 4 терабайта! А даже больше, это я посчитал, если на 1 элемент тратить 8 бит.
Тогда остаётся вариант, когда мы не храним этот массив в памяти, но при каждом вызове, фактически, высчитываем его заново от начала до нужной нам строки (столбца). Вместо огромных затрат памяти, будут огромные затраты времени. Это вполне стандартная ситуация для комбинаторных задач.
посмотрел...
нынешний файл с балансом не содержит в себе цен , цены которые вы мне скидывали ранее не сходятся по размерам с нынешним балансом
В приложении в одном файле и баланс и OHLCV - может так удобней будет.
У меня, оказалось, происходила проверка на ошибку в индикаторе, поэтому так получилось - надо с индикаторами разбираться отдельно ещё - эх.