Сравнение значеий Moving Average (и любых других индикаторов) и погрешности - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Тут mql в принципе не причем. Возьмем абстрактный язык программирования. В данном конкретном примере, приведенным мной, основная проблема заключается в том, что значения для разности мувингов в одном и том же баре не равны (2e-16 при первом вычислении и ровно 0 - при втором). В этом случае вообще можно это пересечение никак не определить. Если возвращаться к mql, то нормализация подразумевает округление числа (точнее просто отбрасывание всех чисел после определенного знака на подобии сишной функции floor только до определенного знака после запятой). Так вот как определить, до какой цифры нормализовать? Если неправильно выбрать цифру, то все значения могут ВСЕГДА округляться в ровно 0. Поэтому нормализация тут опасна и в общем случае не решает проблему.
Что касается того, что написал Alexey Lebedev. Да, думал в эту сторону. Но если сравнивать на больше или равно с 0 обе разности, то есть вероятность получения ложного сигнала (например, теоретически возможная ситуация, когда мувинги между соседними барами идут с полностью одинаковыми значениями). Тогда их разность как бы знак не меняет (пересечения нет), но программно будет определяться сигнал к пересечению. Можно поставить только одно сравнение на больше или равно, как вы предложили. Но тогда вся проблема в том, что при вычислении в этой ситуации вначале не будет равно 0 (2e-16), а на следующем баре уже будет ровно 0, но там уже будет стоять строгое сравнение.
Тут важно понять все таки, почему одна и та же разность при вычислении ее на разных барах дает НЕ одинаковый результат??? Если бы результат был одинаковый, то вроде бы как проблема всегда бы решалась введением одного нестрого сравнения
При нормализации - да, идёт округление до заданного знака после запятой. Не отбрасывание всех чисел после определенного знака, а именно округление.
Если понимаю вас именно в том контексте, какой вы имеете в виду (в расчёт беру и первый ваш пост со скрином и второй пост), то различные эксперименты таким методом, в т.ч., с учётом DoubleToString при выводе на печать, полагаю, всё же могут помочь вам. Это же упоминал Rosomah до меня вам.
В т.ч., помочь определять для себя, до какой цифры нормализовать при каких-либо задачах, либо нужна ли в каких-либо случаях нормализация (в случаях сомнений, применение или не применение по совокупности сопутствующих факторов, в т.ч., что программа потом может применяться в различных ДЦ и, соответственно, полученные расчётные значения могут отличаться).
С моей точки зрения, опасность получать сигналы, которые можно расценивать как ложные, в зависимости от решаемых задач, может быть как раз тогда, когда не применяется нормализация (или не идёт сравнение первым способом за счёт какой-либо малой величины) там, где это бы не помешало.
Кроме того, если при выводе на печать не применяется DoubleToString, то могут быть просто ошибочные опасения в не одинаковом результате одной и той же разности или одних и тех же значений.
/*На всякий случай ещё раз упомяну, что при выводе на печать чисел типа double нужно применение DoubleToString, поскольку при выводе на печать идёт преобразование числового значения в текстовое. Соответственно, при неприменении этой функции могут быть видны погрешности, которых нет на самом деле.
Количество десятичных знаков в этой функции, естественно, с не меньшим количеством десятичных знаков, чем у нормализованных значениях. А для ненормализованных - побольше-побольше.*/
Скорее всего расчёт функции iMA оптимизирован. Первое значение =сумма(close)/N, второе =предыдущее значение МА+(новый close-устаревший close)/N.
То есть iMA в общем случае для одного и того же бара могут давать разные значения двух мувингов в разное время вызова?
При нормализации - да, идёт округление до заданного знака после запятой. Не отбрасывание всех чисел после определенного знака, а именно округление.
Если понимаю вас именно в том контексте, какой вы имеете в виду (в расчёт беру и первый ваш пост со скрином и второй пост), то различные эксперименты таким методом, в т.ч., с учётом DoubleToString при выводе на печать, полагаю, всё же могут помочь вам.
В т.ч., помочь определять для себя, до какой цифры нормализовать при каких-либо задачах, либо нужна ли в каких-либо случаях нормализация (в случаях сомнений, применение или не применение по совокупности сопутствующих факторов, в т.ч., что программа потом может применяться в различных ДЦ и, соответственно, полученные расчётные значения могут отличаться).
С моей точки зрения, опасность получать сигналы, которые можно расценивать как ложные, в зависимости от решаемых задач, может быть как раз тогда, когда не применяется нормализация (или не идёт сравнение первым способом за счёт какой-либо малой величины) там, где это бы не помешало.
Кроме того, если при выводе на печать не применяется DoubleToString, то могут быть просто ошибочные опасения в не одинаковом результате одной и той же разности или одних и тех же значений.
/*На всякий случай ещё раз упомяну, что при выводе на печать чисел типа double нужно применение DoubleToString, поскольку при выводе на печать идёт преобразование числового значения в текстовое. Соответственно, при неприменении этой функции могут быть видны погрешности
Количество десятичных знаков в этой функции, естественно, с не меньшим количеством десятичных знаков, чем у нормализованных значениях. А для ненормализованных - побольше-побольше.*/
Понятно, что округляется последний значащий знак. Но, если, например, для числа 0.000016 поставить нормализацию с 5 знаками, то это будет число 0.00002, а если меньше знаков, то всегда 0. Поэтому округлять до конкретного знака всегда нельзя. Значения MA мало того, что будут зависеть от таймфрейма, так еще и от самих баров. Поэтому непонятно, каким образом в общем случае выставлять число значащих цифр при нормализации.
Вот про бесконечно малую величину я тут понять не могу, как ее применить. Бесконечно малые (погрешность) применяются для сравнения вещественного числа с 0. Мне же надо разность сравнить. Тут еще хуже может быть ситуация. Например, я ставлю какой-то эпсилон. Когда разность больше эпсилон, считаю, что она положительна. Когда меньше минус эпсилон - отрицательна. Когда находится в границах - 0. Но как тогда определить изменение знака разности? Например, разность мувингов на двух барах находится в пределах эпсилон. Но в первом случае она положительна, во втором - отрицательна (то есть пересечение УЖЕ произошло). А у меня с учетом введения погрешности будет считаться что разность 0. Тогда условие изменение знака надо менять. Условно, сигнал о пересечении двух сверху вниз МА в этом случае будет как и просто сравнение на <0 (было) и >0 (стало), так еще и =0 (было) и >0(стало). И самое главное, что в описанном случае (когда значения в одной и той же точке различны при разных вызовах) введение этой погрешности не помогает. Эта разница всегда может быть такой, что какой эпсилон не выбери, сигнала ты не получишь.
Понятно, что округляется последний значащий знак. Но, если, например, для числа 0.000016 поставить нормализацию с 5 знаками, то это будет число 0.00002, а если меньше знаков, то всегда 0. Поэтому округлять до конкретного знака всегда нельзя. Значения MA мало того, что будут зависеть от таймфрейма, так еще и от самих баров. Поэтому непонятно, каким образом в общем случае выставлять число значащих цифр при нормализации.
Вот про бесконечно малую величину я тут понять не могу, как ее применить. Бесконечно малые (погрешность) применяются для сравнения вещественного числа с 0. Мне же надо разность сравнить. Тут еще хуже может быть ситуация. Например, я ставлю какой-то эпсилон. Когда разность больше эпсилон, считаю, что она положительна. Когда меньше минус эпсилон - отрицательна. Когда находится в границах - 0. Но как тогда определить изменение знака разности? Например, разность мувингов на двух барах находится в пределах эпсилон. Но в первом случае она положительна, во втором - отрицательна (то есть пересечение УЖЕ произошло). А у меня с учетом введения погрешности будет считаться что разность 0. Тогда условие изменение знака надо менять. Условно, сигнал о пересечении двух сверху вниз МА в этом случае будет как и просто сравнение на <0 (было) и >0 (стало), так еще и =0 (было) и >0(стало). И самое главное, что в описанном случае (когда значения в одной и той же точке различны при разных вызовах) введение этой погрешности не помогает. Эта разница всегда может быть такой, что какой эпсилон не выбери, сигнала ты не получишь.
Думаю, что при решении каких-либо конкретных задач, можно исходить ещё из точности представления десятичных значащих цифр. У double это 15 значащих цифр, согласно Документации. Формат точности при нормализации, от 0 до 8, согласно Документации. У DoubleToString - свои особенности форматов точности.
Кроме того, iMA - это, с моей точки зрения, функция с учётом того, что выводимые с помощью неё значения будут применяться в различных ситуациях и для решения различных задач. Соответственно, получаемые с её помощью значения могут далее различно обрабатываться, в т.ч., с учётом конкретных задач.
Кроме того, расчёт средних значений - это математические вычисления. К примеру: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... Соответственно, рассчитанные значения с малым или расширенным округлением увеличивают варианты применения вычислений.
Попутно ещё упомяну, на всякий случай, что вместо iMA можно применять функции из библиотеки MovingAverages, входящей, в т.ч., в стандартную поставку терминала. Или свои функции, составленные на основе имеющихся в этой библиотеке.
/*при математических вычислениях могут проявляться особенности работы с числами типа double */
Про эпсилоны же я пас.
P./S.: Т.е., эксперименты, думаю, могут вам помочь. Теоретические же рассуждения без практических экспериментов (на большом количестве данных) для конкретных задач, в т.ч., и запутать могут, и увести в сторону от приемлемых решений.
Dina Paches:
...
Да капец же. МАшки сравниваем триста дней... Нормализуйте до digits, и не парьтесь...
Нормализовать непосредственно значения можно (разность - ни в коем случае). Но опять же приведенный аля эталонный код для сравнения MA нужно менять и вводить одно нестрого неравенство всяко. Да и к тому же вопрос с разными значениями MA на одном и том же баре при расчете в разное время остается открытым. Если это будет повторяться и далее - не факт, что даже нормализация и введение одного нестрого неравенства решит проблему полностью. Плюс ко всему случай, когда мувинги внутри одного бара пересекаются два раза, никак не отловить, если анализировать не по тикам, а по открытию нового бара. Может поделитесь опытом, как вы в этой ситуации действуете?
Ну во-первых, разность двух нормализованных значений в итоге даст не нормализованное значение. Нужно проверять нормализованную разность.
Во-вторых, если хотите ловить пересечения внутри бара, то снимайте значения по всем тикам на нулевом и первом барах - наловитеееесь ... мама-не-горюй ...
Ежли тестируете по открытию бара, то и советник должен явно отслеживать открытие нового бара, и уже после факта открытия проверять пересечения.
Сначала решите для себя - торгуете на открытии бара, или на каждом тике, потом и код пишите. И, соответственно, так же и тестируйте.
Дина, я поражаюсь твоему ангельскому терпению ...
Спасибо, Артём, но, к сожалению, оказалось, что и оно может иметь границы.