Сравнение значеий Moving Average (и любых других индикаторов) и погрешности - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Спасибо за советы конечно, но хэлп я и сам читать умею. И повторюсь вычислительная математика не привязана к конкретному языку программирования. Тут как раз с погрешностями вычислений надо разбираться, с которыми вы пас.
Если вы хелп не только читать умеете, но и понимаете его, то, значит, ведёте сознательную демагогию, упорно продолжая отзываться о нормализации и её возможностях применения в принижающем духе. В том числе, сознательную демагогию об опасности её применения.
И я не умничаю, а привожу контрпримеры (в т.ч. для вашей любимой нормализации).
Демагогия была. Контрпримеров - так и не было по нормализации.
Не считая то, что кто-то может её не правильно применять.
Так и эпсилоны могут применяться не правильно. Да и о демагогии уже упомянула.
P./S.: Пост о нормализации, поэтому не упоминаю о скользящих средних.
Да и, считаю, что по советникам с применением МА, Артём может лучше помочь вам, чем я, в трудных для вас моментах.
Ищите пересечения на каждом тике. В чём проблема-то?
Не нужно ничего никогда нормализовывать при сравнении двух вещественных чисел.
Если числа действительно равны, то в памяти они хранятся одинаково. Собственно именно благодаря этому свойству и возможно существование вычислительных машин.
Отсюда следует, что сравнения вида if(a<b) или if(a==b) корректны при любом раскладе и нормализация шморализация не требуется.
Если пытливый ум исследователя всё же найдет противоречие этому правилу, значит либо его машина не исправна, либо ум. Одно из двух.
Справки и документации читать конечно нужно хотя бы иногда (их тоже писали человекоподобные как и мы), но необходимо иметь и собственные здравые рассуждения.
Если вы хелп не только читать умеете, но и понимаете его, то, значит, ведёте сознательную демагогию, упорно продолжая отзываться о нормализации и её возможностях применения в принижающем духе. В том числе, сознательную демагогию об опасности её применения.
Демагогия была. Контрпримеров - так и не было по нормализации.
Не считая то, что кто-то может её не правильно применять.
Так и эпсилоны могут применяться не правильно. Да и о демагогии уже упомянула.
Были контрпримеры (во всяком случае в плане нормализации еще и разности, как тут озвучивалось). Повторю снова: нормализация - самой простой путь для тех, кто не хочет копаться в тонкостях. Он почитал документацию и свято верит этому всему. Опять же повторю, что язык программирования в рамках вычислительной математики не имеет никакого значения. Если в этом в хэлпе написали такие рекомендации, то это не значит, что это истина (иначе бы не было никаких проблем вычислительной математики и эпсилонов, которые вы так не любите). На заборе тоже много чего написано, но это не значит, что это правда в последней инстанции. Вас устраивает вариант хэлпа, имеете на это полное право. Но это лично ваш выбор. И это далеко не означает, что он решает все проблемы, которые я тут пытался донести. А считать демагогией то, в чем вам просто не хочется разбираться (опять же это ваше право), не означает, что это самой демагогией является. Я не спрашиваю тут риторические вопросы о смысле жизни (ответы на который как раз и являются демагогией), я всего лишь пытаюсь разобраться с тем, с чем я еще не сталкивался. Повторюсь, ладно бы еще значения были одинаковые всегда, когда не вычисляй. Там можно было бы что-то из той же вычислительной математики почерпнуть. Но когда еще и значения разные - тут хоть мега-гуру будь - универсальный алгоритм не придумаешь.
Плюс ко всему я всего лишь хочу удостовериться, что мое понимание того, что если робот работает не по тикам, то получение множественного пересечения внутри одно бара в принципе невозможно, верно. Это уже как раз можно отнести чисто к тонкостям mql.
P.S. Я не пытаюсь с кем-то спорить беспочвенно, не считаю себя все время правым гением. Просто не люблю, когда пытаются умничать и что-то пишут, даже толком не прочитав ничего. К вам лично это вообще никак не относится. Вам спасибо за помощь и изложение своих соображений на этот счет. Но все таки ИМХО неправильно писать что-то про терпение, когда вы настаиваете на одной лишь точки зрения документации (которой вы свято верите и не принимаете никаких альтернативных мнений и примеров), а эпсилоны вам не по душе. Надеюсь и Artyom поймет то, что я написал в посткриптум до этого. Всем спасибо за ответы и пардон, если где-то немного вспылил.
P.P.S. Нормализация до определенного знака после запятой по сути это аналог введения эпсилона как раз порядком этого же знака.
P.P.P.S. Коли у нас разгорелась такая жаркая дискуссия, буду очень признателен, если поделитесь своим опытом в этой теме, ибо должных ответов (особенно на волнующие меня 2 и 3 пункты) по сути не получил. Хотя уже пошерстив много форумов практически пришел к убеждению, что да, 2 пункт невозможен. Тут уже разработчикам mql об этом можно было подумать и предусмотреть большую гибкость, ибо это очень неудобно (в любом другом языке программирования есть возможность динамически менять интерфейс программы, а тут получается его нет((()
Были контрпримеры (во всяком случае в плане нормализации еще и разности, как тут озвучивалось). Повторю снова: нормализация - самой простой путь для тех, кто не хочет копаться в тонкостях. Он почитал документацию и свято верит этому всему. Опять же повторю, что язык программирования в рамках вычислительной математики не имеет никакого значения. Если в этом в хэлпе написали такие рекомендации, то это не значит, что это истина (иначе бы не было никаких проблем вычислительной математики и эпсилонов, которые вы так не любите). На заборе тоже много чего написано, но это не значит, что это правда в последней инстанции. Вас устраивает вариант хэлпа, имеете на это полное право. Но это лично ваш выбор. И это далеко не означает, что он решает все проблемы, которые я тут пытался донести. А считать демагогией то, в чем вам просто не хочется разбираться (опять же это ваше право), не означает, что это самой демагогией является. Я не спрашиваю тут риторические вопросы о смысле жизни (ответы на который как раз и являются демагогией), я всего лишь пытаюсь разобраться с тем, с чем я еще не сталкивался. Повторюсь, ладно бы еще значения были одинаковые всегда, когда не вычисляй. Там можно было бы что-то из той же вычислительной математики почерпнуть. Но когда еще и значения разные - тут хоть мега-гуру будь - универсальный алгоритм не придумаешь.
Плюс ко всему я всего лишь хочу удостовериться, что мое понимание того, что если робот работает не по тикам, то получение множественного пересечения внутри одно бара в принципе невозможно, верно. Это уже как раз можно отнести чисто к тонкостям mql.
P.S. Я не пытаюсь с кем-то спорить беспочвенно, не считаю себя все время правым гением. Просто не люблю, когда пытаются умничать и что-то пишут, даже толком не прочитав ничего. К вам лично это вообще никак не относится. Вам спасибо за помощь и изложение своих соображений на этот счет. Но все таки ИМХО неправильно писать что-то про терпение, когда вы настаиваете на одной лишь точки зрения документации (которой вы свято верите и не принимаете никаких альтернативных мнений и примеров), а эпсилоны вам не по душе. Надеюсь и Artyom поймет то, что я написал в посткриптум до этого. Всем спасибо за ответы и пардон, если где-то немного вспылил.
P.P.S. Нормализация до определенного знака после запятой по сути это аналог введения эпсилона как раз порядком этого же знака.
P.P.P.S. Коли у нас разгорелась такая жаркая дискуссия, буду очень признателен, если поделитесь своим опытом в этой теме, ибо должных ответов (особенно на волнующие меня 2 и 3 пункты) по сути не получил. Хотя уже пошерстив много форумов практически пришел к убеждению, что да, 2 пункт невозможен. Тут уже разработчикам mql об этом можно было подумать и предусмотреть большую гибкость, ибо это очень неудобно (в любом другом языке программирования есть возможность динамически менять интерфейс программы, а тут получается его нет((()
Для меня применение преобразования данных с помощью функции NormalizeDouble при сравнении чисел типа double - это один из двух оговорённых в Документации путей для получать срабатывание условий программы именно там и так, где и как задумывалось при прописывании конкретных условий в коде. О чём и говорила ранее. Соответственно, это не только устранение каких-либо погрешностей. Это и различные продуманные варианты преобразования данных для выполнения каких-либо условий.
Об этом говорила вам и говорю на основе моего личного практического опыта в том языке программирования, который вы только начинаете изучать. Из-за этого и предлагала неоднократно в этой теме, воспользоваться таким практическим способом.
Попутно скажу, отчасти согласившись с вами, что не буду оспаривать, что нормализация с помощью этой функции, может быть и самым простым путём для каких-либо задач в плане преобразования данных вещественного типа
Но какой из двух способов, рекомендуемых в Документации, применять при преобразовании данных вещественных типов, каждый выбирает сам.
И выбор какого-либо из этих способов не относится к определяющим критериям того, что человек из тех, кто старается разобраться в каких-либо необходимых тонкостях или не старается.
О том, что не люблю эпсилоны, не было с моей стороны слов. Не применять какой-либо способ - это не обязательно любовь/не любовь. Да и на применении только второго способа из двух - не настаивала.
Мои дословные слова в плане практического применения особенностей работы с числами типа double, что:
P./S.: Так сложилось, что первый способ из Документации мне оказался менее удобен в применении, в т.ч., исходя из задач, что, как правило, решала для себя. Соответственно, у меня нет большого накопленного опыта по первому способу.
Но при применении второго способа (то бишь, при сравнении нормализованной разности двух вещественных чисел с нулевым значением в выражении условного оператора), какие-либо проблемы не возникали однозначно.
А вот если делала сравнения ненормализованных чисел (здесь имею в виду, в т.ч., что и без применения первого способа), то да, было, что выявляла некорректное срабатывание условий на основе сравнений чисел типа double.
Кроме того, и такое уточнение приводила:
P./S.: При этом на всякий случай ещё раз уточню, что сравнение вещественных чисел первым способом из двух здесь перечисленных, за счёт сравнения разницы чисел с какой-то малой величиной, не могу назвать хуже, чем применение нормализации, когда нужно отрегулировать уровень сравнений (в т.ч., поскольку для меня второй способ оказался более удобен, то первый и не рассматривала для себя более детально для практического применения).
Т.е., в плане нормализации при преобразовании данных типа double, первый способ мне просто не требовался. В т.ч., за счёт удобности для меня применения функции NormalizeDouble при решении различных задач (и не только при сравнениях).
На сайте есть огромная накопленная база знаний.
Люди решали и решают с помощью языка MQL4 задачи различнейшего уровня сложности.
После того, как язык MQL4 был приближен к MQL5, возможности первого ещё более возросли.
Думаю, вам стоит получше познакомиться с этим языком программирования и не пренебрегать накопленной на сайтах здесь базой знаний. Накопить свой практический опыт применения. И уже только тогда может быть что-то уверенно заявлять в плане каких-либо применений в этом языке программирования и его возможностей.
В том, что ТЗ у меня другое) И опять же я уже писал, какие есть проблемы в тиках. Не объяснишь ты никак заказчику, почему робот в сделку вошел, если на графике он не видит пересечения
Берите значения МА на нулевом и первом барах на каждом тике - тогда, и только тогда вы сможете найти пересечения МАшек на нулевом баре. Вы же их берёте с первого бара во время открытия нулевого - а там значения МАшек уже те, которые были в момент закрытия первого бара, а не в момент его формирования. Вы просто поздно считываете значения МАшек, и потому не видите их пересечений. Нормализация тут совсем ни при чём. И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
Уважаемые участники форума. Пожалуйста не устаивайте разборки на форуме. Только по теме топика.
Я думаю что тему можно закрыть. Авторы ( не топика) высказываний к единому мнению не пришли. Были отдельные моменты шовинизма, что не приветствуется.
Но ни один , ни второй свою правоту доказать не сумели. Потому - тему закрываю. Дальнейшее обсуждение может караться (максимум баном суточным).
Хотя если будут приведены нормальные доказательства, то приветствуется.
Судьями будем мы с Володей.
Это не обсуждается.
Не видела всего того, что здесь было, поэтому не знаю, какие аргументы приводились в рамках темы. Но поскольку полагаю, что речь идёт о доказательствах моей позиции, созвучной с позицией Артёма в этом посте (и ранее здесь в теме), то ниже приведу в цифрах один из примеров, в привязке к тому, что нужно ли вообще применять нормализацию тем или иным способом при работе с числами вещественного типа.
Со скринами и вариантом тестового кода.
Артём написал в посте выше:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
А поскольку и я считаю (как и многие, думаю, другие), что это простой и действенный способ в наиболее распространённых направлениях задач, то сделаю от себя только такое маленькое дополнение:
с каким количеством десятичных знаков задумано, чтоб отображалась линия МА, или просто проводились вычисления на основе какого-либо количества десятичных знаков (те же сравнения), с таким количеством десятичных знаков и нормализация (округление до определённого десятичного знака).
/*При решении некоторых индивидуальных задач, могут быть "исключения", и можно варьировать для получения нужного результата, например, сравнением значения с меньшим десятичным знаком, со значением с бОльшим десятичным знаком. Но если такое нужно для решения поставленных задач, то, с моей точки зрения, об этом хорошо может подсказать, при необходимости, как и о выше озвученном способе, вывод получаемых значений на печать и сопоставление полученных значений с визуально отображаемой отрисовкой на чарте.*/
Если же нужно вывести значения типа double в виде текста (через Print, Comment, OBJ_LABEL и тд.), то, поскольку идёт преобразование числа в текст, обязательное применение DoubleToString.
Теперь от вступительного пояснения к наглядности:
На скринах:
Данные тестового скрипта - это значения МА, полученные с помощью функции iMA (с преобразованием данных с помощью функций, описанных для работы с вещественными типами в Документации, и без преобразований).
В окне данных и на чарте видно, что линии с меньшим десятичным знаком сравнялись по значениям на третьем, не считая текущего, баре чарта. Там же видно, что значения МА из стандартного набора к терминалу, нарисованные по десятичным знакам чарта, не равны и визуально сравнялись на чарте чуть пораньше.
Т.е., если увеличить скрины или провести свои эксперименты с помощью прилагаемого тестового скрипта или своих кодов, то будет видно, что линии МА, с количеством десятичных знаков как на чарте, пересекаются чуть ранее.
И это понятно. Если проводить аналогию, то линии с десятичными знаками меньше на единицу - это линии, построенные по двузначным котировкам на чарте с трёхзначными котировками. Что позволяет видеть их наглядно в "старых" пунктах времён, когда ещё не получили широкое распространение трёх-пятизначные котировки в терминалы, и, одновременно, иметь для торговых действий преимущества расширенных по десятичным знакам котировок (в т.ч., и меньший спред).
То есть, линии, построенные на значениях с меньшим количеством десятичных знаков, имеют меньший "шум".
Но если бы не было применено округление значений (в данном случае, с помощью функции нормализации), то число, чётко ограниченное конкретным десятичным знаком, было бы получить проблематичнее.
Или, если просто в цифрах:
123.4561 и 123.4556 - не равны. И их разница не равна нулю.
Однако, если их округлить, то и первое, и второе число, будут одинаковы и равны 123.456. Соответственно, разница между ними будет равна 0.
До какого десятичного знака округлять получаемые значения, зависит от решаемых задач.
А в журнале "Эксперты" на скринах, видны значения МА, выведенные с помощью iMA с преобразованиями, описанными в Документации, и без преобразований получаемых значений. Настройки МА в тестовом скрипте равны настройкам индикаторов на чарте.
На втором скрине видны дельты между значениями двух МА, выведенные с применением преобразований и без.Ниже, как и упоминала, небольшой тестовый код. Он не оптимизирован, но позволяет провести какие-то различные эксперименты со значениями МА, в т.ч., меняя какие-либо параметры.
Количество баров в нём задаётся в этой строке:
P./S.: Заменила прилагаемый тестовый скрипт. Не тот вариант попал у меня в публикацию к посту. Не тот. Sorry.
Замена ранее прилагаемых скринов не требуется, поэтому оставляю их прежними.