Библиотека Generic классов - ошибки, описание, вопросы, особенности использования и предложения - страница 13
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нельзя сопоставлять HistorySelect(ставит range доступа в тестере) и HistoryDealSelect(ticket), который реально ищет конкретный тикет и кеширует его.
Из-за понимания этого и был создан Clear-вариант сразу. Чтобы можно было сравнить Clear vs Full заодно.
Так история (особенно в тестере) только дополняется, старые записи не изменяются. Речь про Clear-вариант.
На реале, вроде, даже когда ордер исполняется частично и порождает несколько сделок, он не попадет в историю, пока полностью не зафиллится или не будет отменен. Т.е. сохраняется правило замороженной истории.
Если бы мы писали софт без проверок, все давно развалили бы.
Финансовый софт не позволяет писать в режиме "срежу углы". Срежешь в одном месте, затем в другом, а потом разработчики уверуют в право пропускать жесткие проверки и провал неминуем.
В тестере еще можно ослабить проверки, но в реале вообще куча асинхронных процессов, работающих над постоянным изменением всего рыночного окружения параллельно работе вашего эксперта. Там даже подумать страшно о том, что между MQL5 вызовами что-то будет сохранено.
Если бы мы писали софт без проверок, все давно развалили бы.
Финансовый софт не позволяет писать в режиме "срежу углы". Срежешь в одном месте, затем в другом, а потом разработчики уверуют в право пропускать жесткие проверки и провал неминуем.
В тестере еще можно ослабить проверки, но в реале вообще куча асинхронных процессов, работающих над постоянным изменением всего рыночного окружения параллельно работе вашего эксперта. Там даже подумать страшно о том, что между MQL5 вызовами что-то будет сохранено.
Спасибо за разъяснение! Тестер, надеюсь, подкрутите немного.
Из-за понимания этого и был создан Clear-вариант сразу. Чтобы можно было сравнить Clear vs Full заодно.
Вы неправильно понимаете, что тестировали. Это никак не Clear вариант и нет никакой связи с исходно заявленной ссылкой на HistorySelect.
Ваш Full вариант по сути означает двойной вызов(поиск тикета), первый из которого выбирает сделку в кеш, а второй доступается к кешированному результату. В конкретной задаче, где сделка заведомо существует, первый вызов select лишний. Get методы неявно поднимают в кеш затронутую запись.
Для информации: мы внутри обязаны выставлять детальные Last Error коды (под GetLastError() вызов), чтобы разработчики могли получить глубинные причины отказа. Обычно таких проверок несколько на один вызов вглубь платформы.
Вы неправильно понимаете, что тестировали. Это никак не Clear вариант и нет никакой связи с исходно заявленной ссылкой на HistorySelect.
Похоже, Вы этого не заметили
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотека Generic классов - ошибки, описание, вопросы, особенности использования и предложения
fxsaber, 2017.12.08 22:46
Похоже, Вы этого не заметили
Или, может, мы о разных вещах говорим.Заметил.
Какая предварительно загруженная история? Я же указал, что HistorySelect в тестере фейковый и не делает реального переноса в кеш всей указанной в запросе истории, а лишь помечает позиции from & to в существующей базе сделок. Поэтому и стоимость нулевая.
В GetDealProfitClear вы точно так же и точно туда же делаете запрос через HistoryDealGetDouble(Deal, DEAL_PROFIT) как и в неправильно понятом вами методе GetDealProfitFull, где стоят два точно таких же по физической сути метода
То есть, доступ к истории в тестере очень оптимизирован и реально ориентируется на то, что никто не может поменять торговую историю кроме вашего эксперта(при этому проверки все равно есть).
В реальном терминале все не так и HistorySelect дорогой.
Понял, что Вы имели в виду. Спасибо за подробности! Интересно, что у Вас выйдет по итогу
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотека Generic классов - ошибки, описание, вопросы, особенности использования и предложения
Renat Fatkhullin, 2017.12.08 23:19
Я посмотрел наш код - есть возможность оптимизировать вызовы к базе торговых операций. Попробуем к релизу на следующей неделе реализовать.
Ознакомился с реализацией CHashMap
Честно, понравилась.
Есть несколько предложений по возможному улучшению:
1) По скромному мнению реализация содержит не совсем корректный выбор capacity - как начальный размер 3, так и последующие при перестройке хеш-таблицы.
Да, все верно, что нужно выбирать простое число для равномерности распределения.
Однако реализация CPrimeGenerator не отвечает ожиданиям и содержит пропуски простых чисел.
Цель такого "генератора" понятна - обеспечить коэффициент прироста порядка 1.2 с автоматическим получением простых чисел.
Однако, разве это не слишком маленький коэффициент? В C++ для vectors обычно коэффициент составляет 1.5-2.0 в зависимости от библиотеки (так как сильно влияет на среднюю сложность операции).
Выходом может быть константный коэффициент с последующим округлением числа до простого через бинарный поиск в списку простых чисел.
И начальный размер capacity в 3 - это уж слишком мало, мы же не в прошлом веке живем.
2) На данный момент перестройка хеш-таблицы (Resize) выполняется исключительно при 100% заполнении capacity (заполнении всех m_entries[])
В связи с чем возможно значительное количество коллизий для ключей с не очень равномерным распределением.
Как вариант рассмотреть возможность введение коэффициента заполнения, который уменьшит 100% на необходимый лимит для выполнения перестройки хеш-таблицы.
А классический вариант сколько возвращает в Вашем случае?
Это время выполнения printf.
Вы как-то странно поняли мой пример. У меня нет цели что-либо сравнивать с штатным функционалом MetaTrader. Речь лишь о том, как на своем пользовательском уровне организовать эффективные алгоритмы ассоциаций и выборки чего угодно с чем угодно. Пример связи номера сделки с номером ордера нужно рассматривать лишь как пример, с низкой практической ценностью, т.к. есть системная HistoryDealGetInteger(Deal, DEAL_ORDER).
Ну вот сравниваем два выделенных показателя. Получается, что HashMap-доступ в 4 раза быстрее того, что у разработчиков. Но у разработчиков он уже включает историю...
По той же причине сравнение некорректное. Как можно сравнивать пользовательский CHashMap и работу с системными функциями для получения торгового окружения?