Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
фиговый из меня обьяснятель. Попробую еще раз. Стоит задача сформировать портфель валют, каждая валюта со своими параметрами. Во оптимизированном портфеле валюта может не участовать. Немного подсчетов шесть валют по 21 шагов оптимизации по каждой валюте, в совокупности до фига счет на миллиарды.
Теперь вопрос. Запрещаем флагом валюте торговать, то и оптимизировать ее параметры нет никакго смысла, все равно они на результат никак не повлияют, однако оптимизатор будет исправно пытаться подбирать параметры которые на результат не влияют, этот пустой прогон немного напрягает (уже третьи сутки пошли). Вроде как сам знаю что нельзя, но надежда еще теплится.
Да,все верно.Будут лишние проходы.Но это вариант комплексного запуска оптимизации.
Если ТС позволяет ,то как уже ответили,оптимизировать каждую пару отдельно.А для себя,для галочки сделать одиночный мультивалютный прогон.
Общая оптимизация предполагает имхо попадание в ловушку волшебного хеджинга ))).
Есть еще одно решение.В другую сторону от предложенного мной,но снижает лишние прогоны.
К примеру ваш перебор параметра 100 в интервале 50-150.Выделите одно значение на false.
Так на одно измерение снижается количество вариантов.Генетика разруливает.
фиговый из меня обьяснятель. Попробую еще раз. Стоит задача сформировать портфель валют, каждая валюта со своими параметрами. Во оптимизированном портфеле валюта может не участовать. Немного подсчетов шесть валют по 21 шагов оптимизации по каждой валюте, в совокупности до фига счет на миллиарды.
Теперь вопрос. Запрещаем флагом валюте торговать, то и оптимизировать ее параметры нет никакго смысла, все равно они на результат никак не повлияют, однако оптимизатор будет исправно пытаться подбирать параметры которые на результат не влияют, этот пустой прогон немного напрягает (уже третьи сутки пошли). Вроде как сам знаю что нельзя, но надежда еще теплится.
Если у вас есть что-то вроде Init() и Trade() для каждой пары + параметры уже подобраны, осталось лишь определить доли, то задача решаема. Хотя, к сожалению, в общем виде, для любого числа систем - решить не удалось.
Итак, нужно задать шаг "доли системы". Для 6 систем, кол-во проходов вычисляется ф-ей:
Можно скрипт сделать для этого:
далее, оптимизируемая задача имеет два параметра - Mult (не оптимизируется) и part - от 1 до PartCount6(Mult) c шагом 1. ну а далее на примере:
Только учтите, что чем меньше шаг, тем больше шагов в цикле нужно пройти. Например, если скрипт, считающий кол-во проходов, не возвращает значение более 5 минут, то лучше уменьшить шаг. Если шаг уменьшать не хотите, то, например, разделите валюты пополам, прооптимизируйте каждую группу, а потом ещё раз вместе "как группы". (а ещё лучше использовать корреляции систем и оптимизировать по-парно - тогда и циклы не такие страшные; но это уже другая история).
Для другого кол-ва систем (хоть меньшего, хоть большего) - всё по аналогии.
чуть не забыл - после оптимизации нужно ведь будет узнать доли - поэтому запускаем одиночный проход, который больше всего нравиться а в OnDeinit пишем:
Этот баг я обнаружил и оттестировал год назад и даже упоминал о нём на форуме.
Как выяснилось, он до сих пор жив.
Суть: при вызове в конструкторе виртуальной функции, вызывается не родная функция, а функция предка.
Принтует:
Если это баг, исправьте, пожалуйста.
Если фича, осветите её подробно в хелпе и объясните в чём преимущества.
Если неизбежное зло - тем более упомяните в хелпе в особой рамочке.
Иначе и свихнуться недолго в поисках бага у себя в программе.
Конструктор предка ничего не знает о своих потомках и их виртуальных функциях.
Как производится конструирование объекта?
1. Сначала вызывается конструктор "первоиерарха". Он выставляет свою таблицу виртуальных функций. Про потомков, следующих по иерархии наследования, предок ничего не знает, да и таблиц виртуальных функций потомков ещё пока не существует.
2. Вызывается конструктор следующего по иерархии потомка. Этот потомок выставляет свою таблицу виртуальных функций. При этом функции (в т.ч. и виртуальные) предка доступны в потомке. Но опять же этот потомок ничего не знает про следующих за ним по иерархии потомков (как в п. 1)
3. Повторяется п.2 до завершения иерархии
Резюме. Не используйте виртуальные функции в конструкторах. Да и в деструкторах тоже.
Если неизбежное зло - тем более упомяните в хелпе в особой рамочке.
Конструктор предка ничего не знает о своих потомках и их виртуальных функциях.
Как производится конструирование объекта?
1. Сначала вызывается конструктор "первоиерарха". Он выставляет свою таблицу виртуальных функций. Про потомков, следующих по иерархии наследования, предок ничего не знает, да и таблиц виртуальных функций потомков ещё пока не существует.
2. Вызывается конструктор следующего по иерархии потомка. Этот потомок выставляет свою таблицу виртуальных функций. При этом функции (в т.ч. и виртуальные) предка доступны в потомке. Но опять же этот потомок ничего не знает про следующих за ним по иерархии потомков (как в п. 1)
3. Повторяется п.2 до завершения иерархии
Резюме. Не используйте виртуальные функции в конструкторах. Да и в деструкторах тоже.
Ок. Но всё же в хелпе отметьте это на видном месте, если всё так и будет.
А вообще, дело не в иерархичности сборки (которую я себя так и представлял), а в том в каком месте конструктора добавляется VMT. Если её добавлять в начале (до кода прописанного юзером) то этой проблемы вроде как нет, и последующий код уже может вызывать виртуальные функции. Это невозможно, нежелательно или.. ?
Так это, вроде общепринятая практика не вызывать виртуальные функции до завершения конструктора и после начала деструктора.
Ну вот я об этом ничего не знал, даже имея кое-какой опыт на других ОО языках. Возможно потому, что не так уж часто возникает необходимость в виртуальных вызовах внутри конструктора.
Ок. Но всё же в хелпе отметьте это на видном месте, если всё так и будет.
В документации данный факт будет отражён в нескольких местах
ОК, отлично.
Слава, а можно поинтересоваться (для общего развития) почему нельзя таблицу виртуальных методов инициализировать в начале конструктора (после инициализации предков) ?
--
В некоторых случаях код с виртуальными вызовоми в конструкторе мог бы быть весьма удобен. Свежий пример: хотел сделать загрузку объектов из файла прямо в конструкторе. Планировался контроль типов прямо по ходу загрузки путём сравнения с идентификаторами типов, возвращаемыми виртуальными функциями . Вышел облом, в связи с невозможностью виртуальных вызовов из конструктора. Проблему решил, но не так элегантно как планировал.