Удивительное рядом: iEnvelopesOnArray
Логично. Ширина канала вычисляется как доля от значения (значение умножить на коэффициент). Если значение отрицательное, значит и ширина отрицательная, а значит, верхняя граница оказывается снизу, а нижняя сверху.
Ну я с этой логикой не согласен. Upper - значит верхняя линия. И такой должна оставаться! Ведь и в логике своих систем мы закладываемся на то, что она всегда будет сверху. Ладно бы еще она называлась как-то по-другому. Плюс верхняя, - значит математически большая чем нижняя. Когда это верх оказывался у нас низом, а меньшее значение именовалось большим?? Но пусть бы в описании на это указывалось. :))) А так - сюрприз!!!
Но я не собираюсь спорить, в кодах советников это можно поправить. Только вот если разработчики вдруг все же решат действительно сделать верхнее верхним, а нижнее нижним :))) то это может дать сбой массы советников.
Ну я с этой логикой не согласен. Upper - значит верхняя линия. И такой должна оставаться! Ведь и в логике своих систем мы закладываемся на то, что она всегда будет сверху. Ладно бы еще она называлась как-то по-другому. Но верхняя, значит большая чем нижняя. Когда это верх оказывался у нас низом?? Но пусть бы в описании на это указывалось. :)))
Но я не собираюсь спорить, в кодах советников это можно поправить. Только вот если разработчики вдруг все же решать сделать верхнее верхним, то это может дать сбой массы советников.
Советую самостоятельно написать как-вам-надо-работающую функцию MyEnvelopesOnArray(), что враз избавит Вас от мучений, связанных с ожиданием внезапного исправления оригинальной функции разработчиками. Уверен даже, что длина кода этой функции будет меньше, чем длина первого сообщения в топике).
Советую самостоятельно написать как-вам-надо-работающую функцию MyEnvelopesOnArray(), что враз избавит Вас от мучений, связанных с ожиданием внезапного исправления оригинальной функции разработчиками. Уверен даже, что длина кода этой функции будет меньше, чем длина первого сообщения в топике).
Да написать то можно что угодно, но: 1) хотелось чтобы штатные средства работали согласно описанной логике, 2) думаю всем будет полезно знать о данной особенности этой функции, чтобы не наступить на грабли.
Кстати, а нужно бы проверить и другие подобные функции!
Она верхняя, но с отрицательным знаком. Становится внизу. Это логично. Проверяйте знак.
Хотелось бы избегать интерпретаций. Нужна однозначность, а не догадки / эксперименты.
В мануале читаем:
MODE_UPPER 1 Upper line (верхняя линия)
MODE_LOWER 2 Lower line (нижняя линия)
Соответственно, если я ставлю моду MODE_UPPER, то должен быть уверен, что получу именно верхнюю линию.
Если же верх вдруг становится низом, а низ верхом (оп-па: меняются местами без предупреждения!), то либо об этом должно быть написано в том же мануале, либо это... "косяк".
Где об этом в руководстве? Там ничего. Да и ну НЕ логично! Термины должны использоваться корректно, интуитивно понятно.
А здесь явная ошибка. Разве сложно признать? Ну никто же не осуждает, просто нужно либо в мануале написать об этой особенности, либо привести к логике названий.
Индикатор нужен для анализа цены, так ? Цена бывает отрицательной ? нет.. ...
На мой взгляд, iEnvelopesOnArray может и должен и создавался как раз для того, чтобы находить корректные математические конверты самых разных рядов данных (например OsMA, CCI, вообще осциллятов, но не только, а в том числе и для кастомных индикаторов). А вот для собственно цены как раз есть просто iEnvelopes(string symbol, int timeframe, ...).
Поэтому если для Вас несоответствие терминологии реальным результатам "совершенно логично", то пожалуйста, оставайтесь при своем мнении. Но мой опыт показывает, что корректность использования терминов весьма важна. Тем более, что разработчикам это было крайне легко обеспечить. Ну не продумали до конца, бывает. Но зачем Вам, Techno, доказывать, что "черное это белое", да еще искажать суть термина "конверт"? :)
Но вообще, повторюсь - больше интересует только один вопрос - останется так навсегда или нет? Хотя судя по всему, менять никто ничего не собирается. :)
Дак стройте эти конверты, кто мешает то ? Если вам кажется что где-то есть расхождение в какой-нить терминологии, дайте заказ в сервисе работы, чтобы программист привел в соответствие вашим персональным понятиям, любую терминологию.
Мое пожелание в данном случае, чтобы работа функции просто соответствовала логике ее же терминов и описания. Для этого разработчики могут либо указать особенности в мануале, либо доработать. Это только на пользу всем. MT4 как продукт весьма и весьма хорош!! Ну если и есть какой мелкий недочет, так и на Солнце бывают пятна. Только если уж пятна обнаружены, лучше их убрать или, хотя бы, задокументировать. Иначе юзеры топчут одни и те же грабли, пишут на форумах :) и т.д.
Всё.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Слегка шокирован поведением функции iEnvelopesOnArray. У нее при отрицательных значениях исходных данных меняются местами UPPER (верхняя) и LOWER (нижняя) линии:
Как я понимаю логику и термины, такого быть НЕ должно! И если не знать, то нарушает систему работы эксперта.
Коллеги и разработчики, скажите - так должно быть?? Или это баг? Если да, то его функцию нужно исправлять. А я ж ее использую! :) Ну как внезапно исправят...
Прилагаю скрипт (я запускал как советника), который демонстрирует данную проблему. Информация пишется в файл "---notes.csv", только учтите, что там разделители дробной - точки (на вашем компе могут быть запятые).