Ошибки, баги, вопросы - страница 3035
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Утверждение получилось немного двусмысленное. На всякий случай уточняю. Да, при обработке тика все таймсерии обрабатываются по порядку, от младшей к старшей. Каждый тик добавляется к данным каждой таймсерии, затем производится расчет индикаторов на каждой таймсерии, по порядку. Т.е. для индикатора в OnCalculate() данные самих таймсерий (всех) безусловно обновленные, но данные индикаторов старших таймфреймов еще не пересчитаны.
Что значит "расчет индикаторов на каждой таймсерии, по порядку" т.е. в зависимости от "ENUM_TIMEFRAMES period"?
int iCustom(
string symbol, // имя символа
ENUM_TIMEFRAMES period, // период
string name // папка/имя_пользовательского индикатора
... // список входных параметров индикатора
);
А если два индикатора с одним и тем же ENUM_TIMEFRAMES period при этом один рассчитывается на данных другого, то как обеспечить правильность последовательного расчета?
Я правильно понял, что если индикатор рассчитывается (ENUM_TIMEFRAMES period) на M1, то при запроси информации OHLC он получит актуальную информацию по последнему тику для любого верхнего ТФ в любом случае?
iSpread ?
Смотрю он примерно похож значению спреда если сделать запрос баров в Символах/Бары в терминале.
При этом естественно эти значения не соответствуют реальным значениям выдаваемым SYMBOL_SPREAD.
Почему такая разница? И какой такой нереальный спред выдаётся по iSpread ?
Что значит "расчет индикаторов на каждой таймсерии, по порядку" т.е. в зависимости от "ENUM_TIMEFRAMES period"?
int iCustom(
string symbol, // имя символа
ENUM_TIMEFRAMES period, // период
string name // папка/имя_пользовательского индикатора
... // список входных параметров индикатора
);
А если два индикатора с одним и тем же ENUM_TIMEFRAMES period при этом один рассчитывается на данных другого, то как обеспечить правильность последовательного расчета?
Это обеспечивает терминал.
Я правильно понял, что если индикатор рассчитывается (ENUM_TIMEFRAMES period) на M1, то при запроси информации OHLC он получит актуальную информацию по последнему тику для любого верхнего ТФ в любом случае?
Да, именно так.
Это обеспечивает терминал.
Да, именно так.
Антон, очень не хватает отдельной функции для получения всех М1(только М1) вне зависимости от параметра MAX_BARS без кеширования и сохранения данных на диск. Это бы дало программисту новые возможности для формирования собственной структуры исторических данных.
осталось выяснить сколько пользователей или программистов будут использовать это? - включите в настройках терминала свойства графика Unlimited и пользуйтесь
пока выглядит как "разработчик приедь и включи мне настройку Unlimited если не сделаешь новые плюшки"
осталось выяснить сколько пользователей или программистов будут использовать это? - включите в настройках терминала свойства графика Unlimited и пользуйтесь
пока выглядит как "разработчик приедь и включи мне настройку Unlimited если не сделаешь новые плюшки"
Unlimited - это очень дорогая опция для всего терминала. Сразу гигантски растет потребление дискового пространства и трафика. Но если мне нужен Unlimited только одного инструмента и только один раз?
Ведь мои файловые хранилища исторических данных занимают в 5 раз меньше дискового пространства в сравнении со штатными, и при этом более информативны, так как содержат еще время для High и для Low и все уже расчитанные ТФ и их не требуется расчитывать каждый раз налету.
Уверяю тебя Игорь, что если я опубликую в КБ такую библиотеку, то много программистов начнут пользоваться ею или создадут свое подобное глядя на ее эффективность.
А если это еще продукт в Маркете?
Я должен всех просить чтобы они включили этот Unlimited, зная, что этим самым я очень сильно посажу их на трафик и дисковое пространство?
По-моему моя просьба совершенно адекватна, при том, что она не требует больших ресурсов для реализации, так как все уже существует и так. Делов на 10-15 мин.
Ведь когда max_bars = 1000 и ты запросишь 1000 W1 баров, то все равно загружается вся история М1, а из нее уже расчитывается W1, только М1 не сохраняется в файл.
Ведь когда max_bars = 1000 и ты запросишь 1000 W1 баров, то все равно загружается вся история М1, а из нее уже расчитывается W1, только М1 не сохраняется в файл.
Как это? Загрузили, но не сохранили?
Как это? Загрузили, но не сохранили?
Загружаются с сервера только М1, а из него формируются любые другие ТФ.
На диск сохраняются не более max_bars баров тех ТФ, которые были запрошены программно или пользователем через выбор ТФ.
1000 бар W1 - это где-то двадцать лет данных, т.е. почти вся история М1 будет загружена.
Можешь Андрей проверить мои слова. Открой в обзоре рынка новый символ и открой его окно и сразу же включи месячный ТФ. И увидишь с какой скоростью данные подкачиваются.
Но при этом в файле ...MetaQuotes\Terminal\...\bases\...\history\...\cache\M1.hc ты увидишь маленький файл.
И что самое прикольное, файлы hcc за все года будут сформированы и будут уже весить до полугигабайт. А формат hcc это и есть уже скаченые М1, но не доступные для программиста.
То есть их и скачивать то не надо будет.
И судя по размеру структуры MqlRates = 60 байт, hcc файлы на упакованы от слова совсем. Очень расточительно!
ЗЫ более внимательно сделал эксперимент и выяснил, что при запросе данных любых периодов, сохраняются неупакованные данные этих периодов в файлах hcc (минутные бары), а в каталог Cache данные выгружаются из ОЗУ только при закрытии терминала.
Т.е. в памяти формируюстя и расчитываются таймфреймы и они сохраняются в файловый кэш при закрытии терминала. Что собственно логично. Нелогично только hcc файлы держать в неупакованном виде и не давать к ним доступа для программистов.
ну если уж так нужно, то только ждать, при условии, что разработчики увидят в этом смысл.... только готовьтесь ждать ну... года два, а может быть и три, увы быстрее никак - я так про перегрузку операторов спрашивал, админ сказал ненужная фича, потом лет 5 не занимался MQL, а вот уже все есть! ))))
ну если уж так нужно, то только ждать, при условии, что разработчики увидят в этом смысл.... только готовьтесь ждать ну... года два, а может быть и три, увы быстрее никак - я так про перегрузку операторов спрашивал, админ сказал ненужная фича, потом лет 5 не занимался MQL, а вот уже все есть! ))))
да, печальное зрелище. Согласен.
Причина, как уже говорил, ручное управление компании.