Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вопрос разработчикам:
почему в тестере невозможно получить поле структуры
MqlTradeResult price; // Цена в сделке, подтверждённая брокером ? Выдает 0.
На демо нормально работает.
Есть ли какая-либо взаимосвязь между списочной структурой таймфреймов и флагов видимости объектов (ведь даже длина списков разная: 22 vs 23)? Вообще, спрашиваю для того, чтобы эффективно и компактно назначать видимость объектов на таймфреймах в цикле с заданными границами, а не перечислять и суммировать вручную флаги. Какой логикой воспользоваться, если взят наугад произвольный таймфрейм, на нём построен графический объект и нужно разрешить его видимость на всех таймфреймах не старше текущего (т. е. того самого, на котором он был построен)? Алгоритм должен быть универсальным, а не для одного конкретного случая. С поиндексной корреляцией - уже в пролёте, нету здесь никакого даже индексного соответствия. Парсить строки имён и сравнивать - опять же в пролёте из-за невозможности работать со строкой в случае с константами видимости. Пока на ум приходит сложная, туманная и очень кривая реализация.
Взаимосвязь конечно есть, но она до того неявная, что написать <флаг_видимости>=F(<таймфрейм>) получится только так:
x100intraday:
Какой логикой воспользоваться, если взят наугад произвольный таймфрейм, на нём построен графический объект и нужно разрешить его видимость на всех таймфреймах не старше текущего (т. е. того самого, на котором он был построен)?
если надо таки не шашечки)
рассматриваем TF[i], задаём Visibility[i]..
или видимость=(int)(MathPow(2,i+1)-1);
если надо таки не шашечки)
рассматриваем TF[i], задаём Visibility[i]..
или видимость=(int)(MathPow(2,i+1)-1);
Спасибо за формулу видимости - может, куда приспособлю. Было видно по значениям на таймфреймах, что это степень чего-то, но пытаться самостоятельно восстановить формулу не пробовал.
А разве -1 надо? Вообще, Visibility[], по-моему, заполнен некорректными значениями, в действительности же должно быть везде без -1, то есть: 1, 2, 4, 8, 16...
Взаимосвязь конечно есть, но она до того неявная, что написать <флаг_видимости>=F(<таймфрейм>) получится только так:
Спасибо, изящно. Всё именно так и пытался сделать, окромя собственно сдвига, его-то мне и не хватало.
И в конечном счёте обращался я собственно по вопросу вычисления значений флага на каждом витке регрессионного цикла по массиву таймфреймов _p_int (что-то ведь в итоге нужно будет складывать пофлагово), а не только на одном текущем. Ну получили мы сдвигом значение флага видимости на текущем ТФ, а потом с каждым витком i-- должно где-то что-то меняться... Там либо формулу возведения в степень нужно прикладывать, либо тот же принцип сдвига использовать. Пока ещё не сообразил как...
...Хотя да, это же функция с ТФ-аргументом - её в цикле попробую покрутить...
Впрочем, опять не то. Сейчас поясню. В примере заведён static ENUM_TIMEFRAMES _p_int[] на 21 элемент, но! Хотелось бы вот чего: у меня уже есть подобный массив, но он может быть произвольной длины. Это массив, содержащий те таймфреймы, на которых будет что-то строиться, но видимость-то должна у них быть и на всех младших таймфреймах, а ими ни один массив не забит ни отдельно, ни дополнен из существующих. То есть здесь-то я и упоминаю необходимость на лету, отплясывая от текущего ТФ, в регрессионном цилке вычислять флаги с текущего и всех младших таймфреймов и суммировать их. Фишка имеенно в том, чтобы не создавать полный массив предзаданных значений чего-либо (хоть таймфреймов, хоть флагов видимости) и шерстить их, а вычислять в уме на каждом витке только для неполного массива предзаданных для работы таймфреймов.
Пойду пока поразбираюсь, если застряну, спрошу.
Я почему (int)(MathPow(2,i+1)-1) или ((int)1)<<i не спешу использовать-то... Раз есть i, то спокойно можно подставлять в цикл и прогонять... Но как в случае с возведением в степень, так и в случае со сдвигом - надёжно ли это всегда? А то ведь если вдруг разработчики когда-нибудь добавят новые таймфреймы, не поползёт ли вся логика под откос? Навскидку - в примере со сдвигом мы ожидаем совпадения текущего периода с предзаданным:
if(period==_p_int[i])
поэтому, даже если в реальном случае какие-то таймфеймы из теоретически полной последовательности будут пропущены или эта последовательность будет расширена разработчиками, логика не должна поползти. А вот если б мы полагались на чистую математику и просто гнали бы цикл по формуле от границы к границе, не оглядываясь на возможное отсутствие или присутствие новых таймфреймов, то рано или поздно, в очередном билде, получили бы, вестимо, перекос...Я почему (int)(MathPow(2,i+1)-1) или ((int)1)<<i не спешу использовать-то... Раз есть i, то спокойно можно подставлять в цикл и прогонять... Но как в случае с возведением в степень, так и в случае со сдвигом - надёжно ли это всегда? А то ведь если вдруг разработчики когда-нибудь добавят новые таймфреймы, не поползёт ли вся логика под откос? Навскидку - в примере со сдвигом мы ожидаем совпадения текущего периода с предзаданным:
поэтому, даже если в реальном случае какие-то таймфеймы из теоретически полной последовательности будут пропущены или эта последовательность будет расширена разработчиками, логика не должна поползти. А вот если б мы полагались на чистую математику и просто гнали бы цикл по формуле от границы к границе, не оглядываясь на возможное отсутствие или присутствие новых таймфреймов, то рано или поздно, в очередном билде, получили бы, вестимо, перекос...Опасения очень обоснованные. Вышеприведённый код оправдывает только то, что набор флагоф видимости - фактически макрос.
Правильнее будет работать через:
Спасибо за формулу видимости - может, куда приспособлю. Было видно по значениям на таймфреймах, что это степень чего-то, но пытаться самостоятельно восстановить формулу не пробовал.
А разве -1 надо? Вообще, Visibility[], по-моему, заполнен некорректными значениями, в действительности же должно быть везде без -1, то есть: 1, 2, 4, 8, 16...
1,2,4 и т.д. - видимость обьекта на одном тф. =MathPow(2,i);
на текущем и меньших 1, 1+2, 1+2+4, 1+2+4+8 и т.д., таки =MathPow(2,i+1)-1;
В двоичном коде наглядней..
Опасения очень обоснованные. Вышеприведённый код оправдывает только то, что набор флагоф видимости - фактически макрос.
Правильнее будет работать через:
Тож самое в принципе. При изменении в списке тф придётся редактировать код.
Какого-то универсального решения не представляю и таки подозреваю) что предусмотреть возможные изменения теоретически не возможно.
x100intraday:
Впрочем, опять не то. Сейчас поясню. В примере заведён static ENUM_TIMEFRAMES _p_int[] на 21 элемент, но! Хотелось бы вот чего: у меня уже есть подобный массив, но он может быть произвольной длины. Это массив, содержащий те таймфреймы, на которых будет что-то строиться, но видимость-то должна у них быть и на всех младших таймфреймах, а ими ни один массив не забит ни отдельно, ни дополнен из существующих. То есть здесь-то я и упоминаю необходимость на лету, отплясывая от текущего ТФ, в регрессионном цилке вычислять флаги с текущего и всех младших таймфреймов и суммировать их. Фишка имеенно в том, чтобы не создавать полный массив предзаданных значений чего-либо (хоть таймфреймов, хоть флагов видимости) и шерстить их, а вычислять в уме на каждом витке только для неполного массива предзаданных для работы таймфреймов.
не, неполучится. Соответствие тф и видимости придётся задать. Или два соответствующих массива, иль вариант со switch.
+массив с теми тф которые нужны, +в инит расчитать по всем этим данным видимость обьекта для каждого используемого TF. Как-то так..)
Всю голову сломал, не пойму в чем дело?
2011.12.29 01:16:07 Core 1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54507 VirtualSL = 1.53378
2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
Всю голову сломал, не пойму в чем дело?
Ошибка в оптимизаторе компилятора. Спасибо за сообщение, исправим.
Ошибка возникает при такой конструкции
В условии первого if из второй части можно убрать VirtualSL!=0.0 т.к. после проверки первой части условия это выражение всегда истина. При этом ошибка оптимизатора пропадёт.Исправлено, исправление войдёт в следующий билд.