Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вот щас тобе точно нагрубят... :))
Наверно,
вчитался в суть проблемы, не пойму зачем в каждом индикаторе таймер ставить, да и вообще зачем эта куча индикаторов,
если можно в таймере советника напрямую получать биды нужного инструмента? и складировать в общую сборку,
в таком варианте дискретность будет в порядке а в варианте с индикаторами имеем несинхронизированный поток данных.
другое дело со шпионами, они ведь не имеют тактов и событий по всем инструментам может не быть долго а могут и один за другим тикать.
ЗЫ кстати в дилингах где имеется цена Last, данных по Bid не всегда есть, так что через проверочку пишем либо Bid если нет то Last.
MetaDriver:
Предлагаю компромисс: ловишь тики шпионами и сразу отправляешь в головной эксперт, снабдив милисекундной меткой(GetTickCount()). Эксперт их упорядочивает в соответствии с метками и нарезает секундные блоки.
Не очень просто, зато с точностью будет порядок.
Неплохой вариант. На мой взгляд единственные который стоит взять за основу.
Urain:
ЗЫ кстати в дилингах где имеется цена Last, данных по Bid не всегда есть, так что через проверочку пишем либо Bid если нет то Last.
MetaDriver:
Предлагаю компромисс: ловишь тики шпионами и сразу отправляешь в головной эксперт, снабдив милисекундной меткой(GetTickCount()). Эксперт их упорядочивает в соответствии с метками и нарезает секундные блоки.
Не очень просто, зато с точностью будет порядок.
Неплохой вариант. На мой взгляд единственные который стоит взять за основу.
Хорошее уточнение, не сталкивался с таким. Нужно будет учесть.Вариант может и не плохой, только механизм отправки тиков отсутствует в терминале. Прикиньте 5-10 тиков/сек да по 16 парам. Еще раз, - это уже прошли))
И точность не нужна такая - достаточно 1сек.
В общем, всем спасибо - данную тему закончил.
Проблема очень неприятная, связанная с подменой минутных баров на бары более высоких таймфреймов в далёком историческом прошлом, когда ещё не велась поминутная история. Из решений на ум приходит только сложная конвертация подложных баров в настоящие, да и это без гарантий точности. Дело даже не столько в сложности, сколько в сомнениях относительно точности такой конвертации.
Изначальная задача состоит в проверке актуальности выстраиваемых Временных Зон Фибоначчи. Если зона слишком отдалённая и рабочая ширина всех её субзон (по дефолту - до 34 единиц базовой ширины) суммарно столь узка, что правая граница не достаёт до настоящего момента, то мы её не строим, в противном случае создадим объект на чарте. Пытался решить двумя схожими способами, один из которых привожу. Разница лишь в том, что в первом способе я плясал от начала истории с использованием
а во втором - наоборот (привожу этот способ), суть и результаты абсолютно не меняются. Тестировал на NZD/USD.Если у вас подставная история заканчивается не в 2009 году, как у меня, а на другой дате, перестройте эти две Fibo Time Zones так, чтобы одна из них проходила через эту переломную дату, а вторая - была бы уже полностью в правой части истории, где все бары настоящие. В этом случае не забудьте также поменять в скрипте значения startTime1, endTime1 и при необходимости startTime2, endTime2; цены можно не подгонять - это непринципиально. Теперь можно протестировать... Результат будет печален: при неизменном алгоритме проверки для обоих таймзон он верно сработает лишь для исторически правосторонней зоны, а та, что одной ногой до переломной даты, а другой - после, алгоритм ошибочно отфильтрует и не даст нам её построить. Замечу, что обе зоны располагаются довольно близко друг к другу и имеют схожую ширину, а две эти ширины простираются далеко в будущее и ещё долго будут актуальны, в действительности ни одна из них не должна быть отфильтрована (закомментируйте условия и увидите, что построились обе таймзоны).
Желаемый результат:
Где-то между первой и второй 0-й базовой линией проходит переломная граница, разделяющая подложные минутные бары и настоящие.
Если же отказаться от расчётов в количестве баров, а всё вычислять в датах, то это уж точно не даст желаемой точности, так как придётся вычитать выходные (+/- час закрытия/открытия рынка), праздники и т. д., а уж о пропуске баров при отсутствии тиков более минуты и расхождении с временнОй шкалой я вообще молчу.
Что посоветуете в качестве надёжного решения?
Ошибка загрузки файла в советнике . Из разряда найдите 10 отличий . Первый код относится к срипту .Второй к советнику , они идентичны Ctrl-C Ctrl-V. В скрипте код работает , в советнике нет.
Ошибка загрузки файла в советнике . Из разряда найдите 10 отличий . Первый код относится к срипту .Второй к советнику , они идентичны Ctrl-C Ctrl-V. В скрипте код работает , в советнике нет.
P.S. Чтобы положить в общую(common) папку, нужно либо записать файл с модификатором FILE_COMMON, либо найти что-то типа этого (вариант для XP):
C:\Documents and Settings\All Users\Application Data\MetaQuotes\Terminal\Common\Files\
Что посоветуете в качестве надёжного решения?
Назад, в MT4.
О будущем этой проблемы обращался к разработчикам, они отмолчались, так что лично для меня перспективы непонятны.
Как то не работает switch с символьными переменными...
Вместо:
'type' - illegal switch expression type
'Buy' - constant expression is not integral
Приходится рисовать так:
что не так наглядно да и кривовато.
На других языках прокатывает...
Надо как-то по другому писать?
Как то не работает switch с символьными переменными...
В документации сказано (выделено мною) - Оператор-переключатель switch:
Сравнивает значение выражения с константами во всех вариантах case и передает управление оператору, который соответствует значению выражения. Каждый вариант case может быть помечен целой константой, символьной константой или константным выражением. Константное выражение не может включать переменные или вызовы функций. Выражение оператора switch должно быть целого типа.
На других языках прокатывает...