Разработчикам.Формат времени в терминале МТ5 - страница 4

 
stringo:

GetTickCount? Полностью? Не смешите.

Ваши трейдинг-потребности не представляют ограниченных возможностей GetTickCount

Вопрос сомнительной, конечно, полезности измерения скорости тиков в рамках меты полностью решается через ограниченные возможности GetTickCount.

Тут даже спорить на нужно, любой желающий может решить эту задачу очень быстро.

Что же касается миллисекунд в общем и своих потребностей, то свое мнение ненужности их в MT5 я более-менее обоснованно высказал.

 
Swan:

Все расчёты по последним 10(иль сколько заданно) тикам..

С минутным tick_volume получится несколько другое) Период на порядок(и) больше.

Если пройтись по минуткам и поделить 60 000 миллисекунд на размер tick_volume, разве не получится скорость поступления тиков в каждую исследованную минуту с точностью до миллисекунды?

Если взять текущее локальное время компьютера с миллисекундами (средствами WinAPI), поделить эти миллисекунды на текущий накопленный tick_volume, разве не получится текущая скорость поступления тиков?

 
hrenfx:

Вопрос сомнительной, конечно, полезности измерения скорости тиков в рамках меты полностью решается через ограниченные возможности GetTickCount.

Тут даже спорить на нужно, любой желающий может решить эту задачу очень быстро.

Что же касается миллисекунд в общем и своих потребностей, то свое мнение ненужности их в MT5 я более-менее обоснованно высказал.

Вам никто не мешает получать текущее время с миллисекундами. Дальше - дело техники
 

hrenfx:

Но GetTickCount полностью решает эту простую задачу. Миллисекунды тут не при чем.

Идея хорошая. Над будет попробовать)

Но таки с миллисекундами во времени тика, всё было бы проще.

 
Я даже для четвёрки писал скрипт, получающий текущее время с миллисекундами. Поищите на четвёрочном форуме.
Документация по MQL5: Дата и время / TimeCurrent
Документация по MQL5: Дата и время / TimeCurrent
  • www.mql5.com
Дата и время / TimeCurrent - Документация по MQL5
 
Swan:
реклама здесь запрещена :)
,,,ага...когда  сливается депо и нет тому объяснений, то тогда человеческий разум начинает "метаться" из крайности в крайность и искать причины происходящему, но при этом забывая посмотреть в зеркало.
 
stringo:
Вам никто не мешает получать текущее время с миллисекундами. Дальше - дело техники

Вы невнимательно, видимо, читаете:

P.P.S. Никто не мешает собирать тики в мете с миллисекундами (через эмуляцию с помощью GetTickCount). Это очень просто. Вопрос лишь в том, а надо ли?

GetTickCount хорош тем, что не требует использования в MQL WinAPI. Но его преимущество гораздо сильнее в другом, локальное время не обязательно синхронизировано с временем торгового сервера. А данные по времени прихода тика надо получать все же во времени торгового сервера. Поэтому миллисекунды эмулируются через GetTickCount. Так точность выше, чем учет постоянно плавающей рассинхронизации двух времен.

Понимаете, это не теоретические рассуждения, а трейдинг-практика. 

 
hrenfx:
А данные по времени прихода тика надо получать все же во времени торгового сервера. Поэтому миллисекунды эмулируются через GetTickCount. Так точность выше, чем учет постоянно плавающей рассинхронизации двух времен.

+ верно.

замерять время на стороне терминала - это значит иметь еще и задержки на пересылку этих данных.

а иметь сохраненное время от сервера - это то что нужно.

Станислав. но ведь касательно ордеров оно ведь у вас и так есть в системе. Просто дайте его в терминал, чтоб трейдеры могли брать.

С тиками - вопрос не решен на уровне сервера. поэтому за это даже и не заикаюсь.

 
papaklass:

 Смотрите, когда к Вам придет тик, то это говорит о том, что произошло одно их следующих событий:

1. Если изменился Bid 1-го уровня (Bid_1);

2. Если Bid_1 не изменился, но изменился объем на данном ценовом уровне (увеличился/уменьшился);

3. Если Bid_1 не изменился, а изменился либо Bid_2, либо объем на ценовом уровне Bid_2;

и т.д.

Тоже самое с Ask. А теперь все вместе Bid, Ask и объемы на каждом ценовом уровне. Представляете сколько различных данных. И это все уложено в 1с.

В секунду может быть до несколько десятков таких тиков. Как их классифицировать? Дискретность времени в 1с - очень грубая классификация, нужно более мелкий шаг измерения времени - миллисекунды. В общих чертах понятно? 

,,, ну и что... к примеру на сервере задержка и и все биды с асками всё равно придут в будущем, не зависимо от того сколько их было.

,,, реально как это в торговле помогает?... пока не догоняю., ну разве что волатильность мерить.

,,, да и кстати , вы уверены что все тики с милисекундной скоростью дойдут от начального источника до вашего монитора(конечная визуальная точка) если МК добавят м.секунды?

 

Прочел ветку и понял что миллисекунды нужны только для спортивного интереса. Чтобы с точностью до мс замерять забег цены на 100 м.

sergeev

Просто дайте его в терминал, чтоб трейдеры могли брать.

Чтобы его дать, нужно чтобы тип datetime стал 10 байтным, и структура MqlDateTime пожирнела.

Дождитесь MQL6, там будет вам и миллисекундный таймер и тиковая история и много других вкусностей. А сейчас не вижу смысла это добавлять. ИМХО.

Причина обращения: