Примагничивание точки привязки графического объекта. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
294 билд. Уже лучше.
Но если на меньшем тф не загружеа история, то примагничивания не происходит. Проверил на той же трендовой, что выше на картинке. Первоначальное примагничивание на месячном графике.
Сейчас при отсутствии минутных данных происходит привязка по данным более высокого таймфрейма.
От решения "в лоб" сейчас нас удерживает экономия ресурсов. На этом билде потестируемся и будем дальше решать вопрос детальных привязок.
Если на графике стоит неограниченное или достаточное количество баров для загрузки, то точность привязки до минуты так как терминал может загружать дальнюю минутную историю. Но если на чартах стоит ограничение в 100 000 баров (минутки за 70 дней), то терминал поднимает в память это количество минуток и точность привязки падает для точек старее 70 дней. Терминал пытается использовать более высокие таймфреймы чтобы поближе подобраться до нужной точке привязки.
Проверить точность привязки можно путем просмотра дат - если дата с точностью до минут, значит все в порядке. Если кратна часу или 30 минутам - значит неполная точность.
Для глубоких и точных построений лучше всего использовать режим "неограниченное количество баров" и 64 битную версию терминала. Так все точки будут точно привязываться, да и проблем с ресурсами не будет.
Терминал пытается использовать более высокие таймфреймы чтобы поближе подобраться до нужной точке привязки.
По логике, терминал должен пытаться совершить правильные и очевидные вещи: начать выкачивать минутную историю старого сегмента, для которого эти минутки отсутствуют на клиенте (и при этом они должны присутствовать на сервере), а потом интерполяцией честно находить требуемое значение до минутной точности. Почему он этого не делает? - вот в чём вопрос года.
Для глубоких и точных построений лучше всего использовать режим "неограниченное количество баров" и 64 битную версию терминала.
Ещё раз внимательно перечитал ответ и не нашёл причин для того, чтобы в 32-разрядной версии не могло бы запросто осуществляться то, что преспокойно осуществляется в 32-разрядной же версии при ручном и вполне точном построении-привязке объектов. Как я понимаю, при ручном построении нет максимальной точности лишь на столь древних исторических данных, когда ещё в принципе не велась тиковая и минутная история (тут и выкачивать, получается, попросту нечего), а для исторических периодов, когда уже начали более детальное протоколирование, терминал выкачивал недостающие минутки и с ними уже работал. Разве нет?
Если пояснение про 64-битную версию имеет смысл, то почему точное такое же никто не пытается приложить к ручному точному построению в 32-битной версии, сказав, что и здесь невозможна максимальная точность для данных старше 70 дней по причине того-то и того-то? Ведь возможна же! А раз так, в чём тогда разница? Почему проблем с точностью в ручном режиме нет, а при написании программ - вдруг есть?
И как успехи? Найдено красивое решение спустя год?
По логике, терминал должен пытаться совершить правильные и очевидные вещи: начать выкачивать минутную историю старого сегмента, для которого эти минутки отсутствуют на клиенте (и при этом они должны присутствовать на сервере), а потом интерполяцией честно находить требуемое значение до минутной точности. Почему он этого не делает? - вот в чём вопрос года.
Ещё раз внимательно перечитал ответ и не нашёл причин для того, чтобы в 32-разрядной версии не могло бы запросто осуществляться то, что преспокойно осуществляется в 32-разрядной же версии при ручном и вполне точном построении-привязке объектов. Как я понимаю, при ручном построении нет максимальной точности лишь на столь древних исторических данных, когда ещё в принципе не велась тиковая и минутная история (тут и выкачивать, получается, попросту нечего), а для исторических периодов, когда уже начали более детальное протоколирование, терминал выкачивал недостающие минутки и с ними уже работал. Разве нет?
Если пояснение про 64-битную версию имеет смысл, то почему точное такое же никто не пытается приложить к ручному точному построению в 32-битной версии, сказав, что и здесь невозможна максимальная точность для данных старше 70 дней по причине того-то и того-то? Ведь возможна же! А раз так, в чём тогда разница? Почему проблем с точностью в ручном режиме нет, а при написании программ - вдруг есть?
Поставьте себе в настройках терминала "Графики - Максимум баров в окне: Unlimited" и работайте на здоровье. Точность будет максимальной.
Если в какой-то момент начнется недостаток памяти (2 Gb на процесс в 32 битных версиях), то лучше переходить на 64 битные версии операционки и терминала.
Поставьте себе в настройках терминала "Графики - Максимум баров в окне: Unlimited" и работайте на здоровье. Точность будет максимальной.
Если в какой-то момент начнется недостаток памяти (2 Gb на процесс в 32 битных версиях), то лучше переходить на 64 битные версии операционки и терминала.
Ну это-то понятно. А что, в 64-битных версиях на процесс уходит менее 2 Гб? Но даже если, допустим, и меньше, то 64-битная версия терминала, очевидно, встанет только на x64 операционку, которая сама по себе априори требует для нормальной работы оперативки в разы больше, чем 32-битная ОС. Так что я пока не понимаю, чем один вариант лучше другого.
Суть 64 бит в том что там ОС "видит" больше 4 Gb оперативы. Поэтому увеличив память до предельно допустимых размеров (насколько позволяет материнка) можно спокойно работать и при 4 Gb на процесс и при 8. Конечно желательна операционистка и процессор на 64 bit тогда (но если взять специализированные ОС типа Win 2003/2008 и "подшаманив" их немного можно попытаться и старым CPU обойтись)...
Ну это-то понятно. А что, в 64-битных версиях на процесс уходит менее 2 Гб? Но даже если, допустим, и меньше, то 64-битная версия терминала, очевидно, встанет только на x64 операционку, которая сама по себе априори требует для нормальной работы оперативки в разы больше, чем 32-битная ОС. Так что я пока не понимаю, чем один вариант лучше другого.
Если жить в рамках одного чарта и играться в теоретические рассуждения, не принимать во внимание, что чартов может быть открыто много, что могут одновременно использоваться разнообразные по ресурсоемкости индикаторы и эксперты, то конечно, можно делать удивленное лицо и требовать ответа по поводу 2 гигабайт.
Но мы живем в реальном мире, где торговые серверы предоставляют огромные базы истории (минутки по EURUSD занимают 250 мб), трейдеры используют большое количество чартов, индикаторов, экспертов и тд, что легко позволяет занять эти потенциально доступные 2 гб памяти в 32 битах. Чудес не бывает - ресурсы конечны.
Явно неразумно бросаться спорить с разработчиками в таких вопросах.
Суть 64 бит в том что там ОС "видит" больше 4 Gb оперативы. Поэтому увеличив память до предельно допустимых размеров (насколько позволяет материнка) можно спокойно работать и при 4 Gb на процесс и при 8. Конечно желательна операционистка и процессор на 64 bit тогда (но если взять специализированные ОС типа Win 2003/2008 и "подшаманив" их немного можно попытаться и старым CPU обойтись)...
Кстати, я сам лично видел на своем компьютере, как 64 битные тестерные агенты в режиме MQL5 Cloud Network съедали по 3-4 Gb памяти каждый при работе некоторых особо прожорливых экспертов.
В последующем мы серьезно переписали механизмы работы кешей в агентах, что позволило кратно уменьшить затраты памяти во всех случаях работы агентов.
Это к тому, что эксперт может легко запросить "дай мне все по всем фронтам", что выливается в поднятие гигантских объемов данных в память. К счастью, мы реализовали очень эффективные механизмы работы кешей.