Для чего это делается? В INFO-режиме такое поведение удобно, а вот в ALL ждешь получения сырых данных, а их показывает только GUI.
Если цена не изменялась, то она нулевая просто. А так выходит, что флаги - лишняя сущность. Вместо того, чтобы показывать нулевые цены, увеличили MqlTick-структуру на этот флаг.
В tkc хранятся только (без нулевых цен) флаги, хранятся только (без флагов) цены или же там нерационально присутствуют и флаги и цены?
И зачем введен флаг?
TICK_FLAG_VOLUME – тик изменил объем
Изменился объем или нет - не важно совершенно. Или я что-то не понимаю?
ЗЫ Сырые ALL-данные нужны особенно для кастомных символов, т.к. это напрямую касается вопроса канала обмена данным через кастомные символы.
Копитикс в режиме COPY_TICKS_ALL занимается самодеятельностью - заполняет нулевые Bid/Ask-поля.
Для чего это делается? В INFO-режиме такое поведение удобно, а вот в ALL ждешь получения сырых данных, а их показывает только GUI.
Если цена не изменялась, то она нулевая просто. А так выходит, что флаги - лишняя сущность. Вместо того, чтобы показывать нулевые цены, увеличили MqlTick-структуру на этот флаг.
В tkc хранятся только (без нулевых цен) флаги, хранятся только (без флагов) цены или же там нерационально присутствуют и флаги и цены?
И зачем введен флаг?
Изменился объем или нет - не важно совершенно. Или я что-то не понимаю?
ЗЫ Сырые ALL-данные нужны особенно для кастомных символов, т.к. это напрямую касается вопроса канала обмена данным через кастомные символы.
Вы пишете в сервисдек о выявленных вами недочетах?
Такое ощущение что всё уходит в пустоту.
И зачем введен флаг?
TICK_FLAG_VOLUME – тик изменил объем
По моему это очень важный показатель. Как иначе узнать что совершена сделка, а не просто изменились, передвинулись bid ask?
Вы пишете в сервисдек о выявленных вами недочетах?
В СД оперативно реагируют на все заявки. Дальнейшие обсуждения ведутся там.
По моему это очень важный показатель. Как иначе узнать что совершена сделка, а не просто изменились, передвинулись bid ask?
Достаточно только флага
TICK_FLAG_LAST – тик изменил цену последней сделки
Переделав его на "прошла сделка". То, что last-цена изменилась - никого не волнует. Может быть несколько подряд сделок с полностью совпадающими ценой и объемом. Поэтому флаг должен быть только один - сделка.
В СД оперативно реагируют на все заявки. Дальнейшие обсуждения ведутся там.
Достаточно только флага
Переделав его на "прошла сделка". То, что last-цена изменилась - никого не волнует. Может быть несколько подряд сделок с полностью совпадающими ценой и объемом. Поэтому флаг должен быть только один - сделка.
Если реагирует это хорошо.
По поводу флагов:
Тоже была такая мысль, в советниках для анализа ситуации, объединить совпадающие сделки, этого как бы достаточно.
Такая ситуация - время биржи, время сервера, время компьютера не совпадают. Как узнать что MarketClosed, если пришла сделка даже по прошлой цене значит торговля идет.
И если объединить все сделки на одном уровне то непонятно будет за какое время уровень торговался?
P.S. лишние флаги не влияют на объем передаваемых флагов.
Тоже была такая мысль, в советниках для анализа ситуации, объединить совпадающие сделки, этого как бы достаточно.
Такая ситуация - время биржи, время сервера, время компьютера не совпадают. Как узнать что MarketClosed, если пришла сделка даже по прошлой цене значит торговля идет.
И если объединить все сделки на одном уровне то непонятно будет за какое время уровень торговался?
Зачем объединять на одном уровне? Я бы не объединял, а оставил ленту, как сейчас - что пришло от биржи.
P.S. лишние флаги не влияют на объем передаваемых флагов.
Флаги - вынужденная мера, т.к. сырые данные MQ не возвращают. Они их модифицируют внутри CopyTicks.
Если на терминале еще не закачаны тиковые данные, то при вызове CopyTicks как терминал узнает, какие tkc-файлы тянуть?
CopyTicksRange реализован на основе CopyTicks или же самостоятельно?
Правильно ли понимаю, что получить тики за сентябрь, например, будет всегда быстрее через CopyTicksRange, чем через CopyTicks, т.к. CopyTicks не знает через входные параметры, за какой месяц нужно тянуть данные?
Нужно в индикаторе получить как можно быстрее историю. Есть возможность сделать запрос через CopyTicksRange и получить отлуп в виде -1, пока все не закачается. А если запрашивать по месяцу: текущий, затем предудыщий и т.д. То получится не медленнее же, но при этом индикатор будет готов работать хоть с какой-то историей. Верно?
Результат
Копитикс меняет исходные данные
Результат
Почему формируются лишние тики?
Скрипт выводит лишние тики
Результат на EURUSD Metaquotes-Demo
Копитикс в режиме COPY_TICKS_ALL занимается самодеятельностью - заполняет нулевые Bid/Ask-поля.
Для чего это делается? В INFO-режиме такое поведение удобно, а вот в ALL ждешь получения сырых данных, а их показывает только GUI.
Если цена не изменялась, то она нулевая просто. А так выходит, что флаги - лишняя сущность. Вместо того, чтобы показывать нулевые цены, увеличили MqlTick-структуру на этот флаг.
В tkc хранятся только (без нулевых цен) флаги, хранятся только (без флагов) цены или же там нерационально присутствуют и флаги и цены?
И зачем введен флаг?
Изменился объем или нет - не важно совершенно. Или я что-то не понимаю?
ЗЫ Сырые ALL-данные нужны особенно для кастомных символов, т.к. это напрямую касается вопроса канала обмена данным через кастомные символы.
Копитикс в режиме COPY_TICKS_ALL занимается самодеятельностью - заполняет нулевые Bid/Ask-поля.
Для чего это делается? В INFO-режиме такое поведение удобно, а вот в ALL ждешь получения сырых данных, а их показывает только GUI.
Если цена не изменялась, то она нулевая просто. А так выходит, что флаги - лишняя сущность. Вместо того, чтобы показывать нулевые цены, увеличили MqlTick-структуру на этот флаг.
В tkc хранятся только (без нулевых цен) флаги, хранятся только (без флагов) цены или же там нерационально присутствуют и флаги и цены?
И зачем введен флаг?
Изменился объем или нет - не важно совершенно. Или я что-то не понимаю?
ЗЫ Сырые ALL-данные нужны особенно для кастомных символов, т.к. это напрямую касается вопроса канала обмена данным через кастомные символы.
Вы пишете в сервисдек о выявленных вами недочетах?
Такое ощущение что всё уходит в пустоту.
И зачем введен флаг?
По моему это очень важный показатель. Как иначе узнать что совершена сделка, а не просто изменились, передвинулись bid ask?
Вы пишете в сервисдек о выявленных вами недочетах?
В СД оперативно реагируют на все заявки. Дальнейшие обсуждения ведутся там.
По моему это очень важный показатель. Как иначе узнать что совершена сделка, а не просто изменились, передвинулись bid ask?
Достаточно только флага
TICK_FLAG_VOLUME – тик изменил объем
Как-то раньше не задумывался над написанным в справке.
Объем чего он изменил?Что вообще означает написанное выше?))
В СД оперативно реагируют на все заявки. Дальнейшие обсуждения ведутся там.
Достаточно только флага
Переделав его на "прошла сделка". То, что last-цена изменилась - никого не волнует. Может быть несколько подряд сделок с полностью совпадающими ценой и объемом. Поэтому флаг должен быть только один - сделка.Если реагирует это хорошо.
По поводу флагов:
Тоже была такая мысль, в советниках для анализа ситуации, объединить совпадающие сделки, этого как бы достаточно.
Такая ситуация - время биржи, время сервера, время компьютера не совпадают. Как узнать что MarketClosed, если пришла сделка даже по прошлой цене значит торговля идет.
И если объединить все сделки на одном уровне то непонятно будет за какое время уровень торговался?
P.S. лишние флаги не влияют на объем передаваемых флагов.
Если реагирует это хорошо.
По поводу флагов:
Тоже была такая мысль, в советниках для анализа ситуации, объединить совпадающие сделки, этого как бы достаточно.
Такая ситуация - время биржи, время сервера, время компьютера не совпадают. Как узнать что MarketClosed, если пришла сделка даже по прошлой цене значит торговля идет.
И если объединить все сделки на одном уровне то непонятно будет за какое время уровень торговался?
Зачем объединять на одном уровне? Я бы не объединял, а оставил ленту, как сейчас - что пришло от биржи.
tkc-файлы разбиты по месяцам. Вопросы из-за этого