Вопросы по архитектуре history testing

Вопросы по архитектуре history testing
Atom
2/15/2011
pyhta4og


В каких случаях вызывается Strategy.OnRunning?
Отдельно интересно узнать в случае запуска отдельно на realtime и отдельно на history.

Верно ли что в случае исторического
HistoryStrategyManager.TimeStep определяет частоту вызова Strategy.OnRunning?
а в случае realtime
StrategyManager.Interval определяет частоту вызова Strategy.OnRunning


В чем тогда разница между StrategyManager.Interval и HistoryStrategyManager.TimeStep ?

Я подписался в стратегии на Trader.NewTrades и они приходят пачками. Чем больше HistoryStrategyManager.TimeStep тем больше.
А если моя логика завязана на каждый тик, то какой мне TimeStep ставить? 0 не проходит пишет DivisionByZero.





Thanks:


1 2  >
Mikhail Sukhov

Avatar
Date: 2/15/2011
Reply


pyhta4og
В каких случаях вызывается Strategy.OnRunning?
Отдельно интересно узнать в случае запуска отдельно на realtime и отдельно на history.


Когда Strategy.ProcessState переходит в Running. Не зависит от realtime и history.

pyhta4og

Верно ли что в случае исторического
HistoryStrategyManager.TimeStep определяет частоту вызова Strategy.OnRunning?


Нет, определяет Strategy.OnProcess.

pyhta4og

а в случае realtime
StrategyManager.Interval определяет частоту вызова Strategy.OnRunning


Нет, так же Strategy.OnProcess[laugh] Прочитайте доку по созданию стратегий. Нам расписано про члены классы Strategy.

pyhta4og

В чем тогда разница между StrategyManager.Interval и HistoryStrategyManager.TimeStep ?


Первый - это скорость изменения второго.

pyhta4og

Я подписался в стратегии на Trader.NewTrades и они приходят пачками. Чем больше HistoryStrategyManager.TimeStep тем больше.
А если моя логика завязана на каждый тик, то какой мне TimeStep ставить? 0 не проходит пишет DivisionByZero.


TimeStep - это шаг в истории. 0 просто логически быссмысленнен. И конечно, чем больше шаг, тем больше маркет-данных.
Thanks:

anebotov

Avatar
Date: 2/17/2011
Reply


Mikhail Sukhov
pyhta4og

В чем тогда разница между StrategyManager.Interval и HistoryStrategyManager.TimeStep ?

Первый - это скорость изменения второго.


Что? можно поподробнее!
точно скорость изменения TimeStep , а не MarketTime?
Thanks:

Mikhail Sukhov

Avatar
Date: 2/17/2011
Reply


anebotov

Что? можно поподробнее!
точно скорость изменения TimeStep , а не MarketTime?


http://stocksharp.com/do...a-a699-da47b666194a.htm

Quote:
Через свойство TimeShiftStrategyManager.TimeStep задается временной шаг в истории, на значение которого увеличивается ITrader.MarketTime.


Quote:
Дополнительно, через свойство StrategyManager.Interval задается время ожидания между итерациями тестирования (одна итерация равна одному вызову метода Strategy.OnProcess() для всех зарегистрированных стратегий в TimeShiftStrategyManager). По умолчанию, оно равно Zero, что указывает на отсутствие задержки между итерациями. Если такой режим нагружает процессор, и необходимо понизить интенсивность, то это значение можно увеличить до секунды и больше.


Где неясность? Я поправлю доку.
Thanks:

anebotov

Avatar
Date: 2/17/2011
Reply


Показалось, что в топике 2 было сказано, StrategyManager.Interval это скорость изменения HistoryStrategyManager.TimeStep. Это и смутило.

В доке всё понятно. StrategyManager.Interval введен с целью не загружать процессор на 100%, и если нас такая загрузка процессора не напрягает, то мы данный параметр оставляем в значении по умолчанию.

TimeStep - это параметр, на который изменяется MarketTime на каждой итерации тестирования, устанавливается перед запуском теста, и, в нормальной ситуации, не меняется в процессе тестирования.
Thanks:

pyhta4og

Avatar
Date: 2/19/2011
Reply


[3.0.5]
Тестировал SampleHistoryTesting на RTS-03.11. Данные с РТС, метка времени у трейдов - с точностью до секунды (к сожалению), соответственно много трейдов с одинаковой меткой времени.

Поставил TimeShiftStrategyManager.TimeStep=0.1сек.

В SmaStrategy подписался на Trader.NewTrades и Trader.QuotesChanged и печатал в них приходящие трейд и пару бид-аск с соответственными моментами времени.

Получил
Code

T (0);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178250@1
T (1);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178260@2
T (2);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178260@1
T (3);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178260@1
T (4);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178250@1
T (5);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178250@1
T (6);MT=20110111 10:30:20.000; TT=20110111 10:30:20.000;178260@2
MD(0);MT=20110111 10:30:20.000;LCT=20110111 10:30:20.000;BID=178259@13;OFFER=178259.2@1
MD(0);MT=20110111 10:30:20.100;LCT=20110111 10:30:20.100;BID=178260@17;OFFER=178261@9
MD(0);MT=20110111 10:30:20.200;LCT=20110111 10:30:20.200;BID=178259.6@15;OFFER=178260.8@6
MD(0);MT=20110111 10:30:20.300;LCT=20110111 10:30:20.300;BID=178259.2@3;OFFER=178260.3@5
MD(0);MT=20110111 10:30:20.400;LCT=20110111 10:30:20.400;BID=178260@8;OFFER=178260.4@20
MD(0);MT=20110111 10:30:20.500;LCT=20110111 10:30:20.500;BID=178259.2@18;OFFER=178260.4@4
MD(0);MT=20110111 10:30:20.600;LCT=20110111 10:30:20.600;BID=178259.9@19;OFFER=178261.1@4
MD(0);MT=20110111 10:30:20.700;LCT=20110111 10:30:20.700;BID=178258.9@3;OFFER=178259.8@12
MD(0);MT=20110111 10:30:20.800;LCT=20110111 10:30:20.800;BID=178258.6@13;OFFER=178259.9@20
MD(0);MT=20110111 10:30:20.900;LCT=20110111 10:30:20.900;BID=178259.3@7;OFFER=178260.1@14
OnPro;MT=20110111 10:30:20.900;BestBid=Бид 178259.3 7;BestAsk=Оффер 178260.1 14;LastTT20110111 10:30:20.000;178260@2
T (0);MT=20110111 10:30:21.000; TT=20110111 10:30:21.000;178260@1
T (1);MT=20110111 10:30:21.000; TT=20110111 10:30:21.000;178250@2
T (2);MT=20110111 10:30:21.000; TT=20110111 10:30:21.000;178260@1
T (3);MT=20110111 10:30:21.000; TT=20110111 10:30:21.000;178250@1
MD(0);MT=20110111 10:30:21.000;LCT=20110111 10:30:21.000;BID=178249.4@17;OFFER=178251.1@4
MD(0);MT=20110111 10:30:21.100;LCT=20110111 10:30:21.100;BID=178248.7@14;OFFER=178249.5@10
MD(0);MT=20110111 10:30:21.200;LCT=20110111 10:30:21.200;BID=178248.4@11;OFFER=178249.6@7
MD(0);MT=20110111 10:30:21.300;LCT=20110111 10:30:21.300;BID=178249.6@7;OFFER=178251.5@13
MD(0);MT=20110111 10:30:21.400;LCT=20110111 10:30:21.400;BID=178249@3;OFFER=178250.1@12
MD(0);MT=20110111 10:30:21.500;LCT=20110111 10:30:21.500;BID=178249.3@19;OFFER=178250.2@4
MD(0);MT=20110111 10:30:21.600;LCT=20110111 10:30:21.600;BID=178248.5@5;OFFER=178249.5@8
MD(0);MT=20110111 10:30:21.700;LCT=20110111 10:30:21.700;BID=178249.4@1;OFFER=178250.4@17
MD(0);MT=20110111 10:30:21.800;LCT=20110111 10:30:21.800;BID=178248.6@5;OFFER=178249.3@7
MD(0);MT=20110111 10:30:21.900;LCT=20110111 10:30:21.900;BID=178249.1@17;OFFER=178250.2@10
T (0);MT=20110111 10:30:22.000; TT=20110111 10:30:22.000;178255@1
T (1);MT=20110111 10:30:22.000; TT=20110111 10:30:22.000;178255@4
T (2);MT=20110111 10:30:22.000; TT=20110111 10:30:22.000;178260@1
T (3);MT=20110111 10:30:22.000; TT=20110111 10:30:22.000;178260@1
T (4);MT=20110111 10:30:22.000; TT=20110111 10:30:22.000;178260@1
T (5);MT=20110111 10:30:22.000; TT=20110111 10:30:22.000;178255@2
MD(0);MT=20110111 10:30:22.000;LCT=20110111 10:30:22.000;BID=178255.1@13;OFFER=178256.5@9
OnPro;MT=20110111 10:30:22.000;BestBid=Бид 178255.1 13;BestAsk=Оффер 178256.5 9;LastTT20110111 10:30:22.000;178255@2
MD(0);MT=20110111 10:30:22.100;LCT=20110111 10:30:22.100;BID=178253.4@6;OFFER=178255.1@11
MD(0);MT=20110111 10:30:22.200;LCT=20110111 10:30:22.200;BID=178254.5@6;OFFER=178255.3@13
MD(0);MT=20110111 10:30:22.300;LCT=20110111 10:30:22.300;BID=178253.3@9;OFFER=178254.5@1
MD(0);MT=20110111 10:30:22.400;LCT=20110111 10:30:22.400;BID=178254@12;OFFER=178255.2@20
MD(0);MT=20110111 10:30:22.500;LCT=20110111 10:30:22.500;BID=178254.2@6;OFFER=178255.8@10
MD(0);MT=20110111 10:30:22.600;LCT=20110111 10:30:22.600;BID=178254@18;OFFER=178255.8@5
MD(0);MT=20110111 10:30:22.700;LCT=20110111 10:30:22.700;BID=178253.8@14;OFFER=178254.7@11
MD(0);MT=20110111 10:30:22.800;LCT=20110111 10:30:22.800;BID=178254@17;OFFER=178255.7@3
MD(0);MT=20110111 10:30:22.900;LCT=20110111 10:30:22.900;BID=178253.8@2;OFFER=178255.2@8
T (0);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178250@5
T (1);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178250@5
T (2);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178245@2
T (3);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178240@1
T (4);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178240@3
T (5);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178250@2
T (6);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178250@1
T (7);MT=20110111 10:30:23.000; TT=20110111 10:30:23.000;178240@10
MD(0);MT=20110111 10:30:23.000;LCT=20110111 10:30:23.000;BID=178239.2@10;OFFER=178240.1@1
MD(0);MT=20110111 10:30:23.100;LCT=20110111 10:30:23.100;BID=178240.2@5;OFFER=178240.7@17
OnPro;MT=20110111 10:30:23.100;BestBid=Бид 178240.2 5;BestAsk=Оффер 178240.7 17;LastTT20110111 10:30:23.000;178240@10


Здесь T - означает пришел ивент NewTrades, MD - пришел ивент QuotesChanged, OnPro - пришел OnProcess;
MT = Trader.MarketTime, TT=Trade.Time, LCT=MarketDepth.LastChangeTime; BID,OFFER - лучший бид и офер в MarketDepth-e.



Что тут видно:

1. MarketTime прихода OnProcess не 0.1 сек как хотелось а 1.1 сек! А именно
10:30:20.900,10:30:22.000,10:30:23.100.

Это по-моему неправильно, раз я заказывал 0.1 сек.

2. Новый стакан генерится с интервалом 0.1 сек, при этом опорная цена берется последняя из тиков датированных последней секундной отметкой.

3. В связи с первым пунктом писать тиковые стратегии не получится тк OnProcess после каждого тика не вызовется. Тут есть гипотеза что это в связи с тем что точность времени у тиков 1 секунда. Но все исторические источники обладают у нас таким недостатком. Поэтому как вариант предлагаю ввести спецпараметр "генерация рандомных миллисекунд для трейдов" - т.е. например с меткой 10:30:23 пришло 8 трейдов. Искуственно поставить им временные метки 10:30:23.100, 10:30:23.200 и тд. Для стратегий одного инструмента как правило конкретное значение временной метки будет не слишком важно, а вот возможность протестировать на КАЖДОМ тике - мне кажется важнее.

4. Стакан генерируется с шагом цены 0.1 пункта вместо 5. Так и должно быть?

5. По виду генерируемый стакан осуществляет некоторое случайное блуждание вокруг цены последней сделки.
Насколько генератор пытается оценить величину реального спреда?

У меня родилась некая идея как можно было бы генерировать стакан.
Я ее нарисовал на картинке. http://stocksharp.com/fo...lbum.aspx?u=285&a=9
Так вот, алгоритм следующй ( на картинке называется алгоритм2)

Пусть цена последней сделки(сделка1) равна P1. Симулятор знает цену следующей сделки после этой (в будущем) с ценой отличной от P1 (т.е. если после сделки1 идут несколько с той же ценой их пропускаем и берем следующую, с другой ценой). Пусть эта цена P2. Тогда после сделки1 (которая с ценой P1) принимаем лучший бид равным min(P1,P2), лучший аск равным max(P1,P2).

Если посмотреть на рисунок, то, как мне кажется, спред имитируется правдоподобно.


В заключение уместно добавить, что я наткнулся на BidAskHistory.ru-вроде обещают продавать с миллисекундной точностью данные включая стаканы.

Thanks:

Mikhail Sukhov

Avatar
Date: 2/20/2011
Reply


pyhta4og

1. MarketTime прихода OnProcess не 0.1 сек как хотелось а 1.1 сек! А именно
10:30:20.900,10:30:22.000,10:30:23.100.

Это по-моему неправильно, раз я заказывал 0.1 сек.


А интервал у самой стратегии изменили? По умолчанию он как раз равен секунде. И видимо это и сыграло свою роль.

pyhta4og

2. Новый стакан генерится с интервалом 0.1 сек, при этом опорная цена берется последняя из тиков датированных последней секундной отметкой.


Что в этом не так?

pyhta4og

3. В связи с первым пунктом писать тиковые стратегии не получится тк OnProcess после каждого тика не вызовется. Тут есть гипотеза что это в связи с тем что точность времени у тиков 1 секунда. Но все исторические источники обладают у нас таким недостатком.


Это не источник, а биржа. Она транслирует с секундной точностью.

pyhta4og

4. Стакан генерируется с шагом цены 0.1 пункта вместо 5. Так и должно быть?


// создаем тестовый инструмент, на котором будет производится тестирование
var security = new Security
{
Id = "RTS-9.09", // по идентификатору инструмента будет искаться папка с историческими маркет данными
Code = "RI",
Name = "RI",
MinStepSize = 0.1,
MinStepPrice = 2,
Decimals = 1,
Exchange = Exchange.Test,
};

pyhta4og

5. По виду генерируемый стакан осуществляет некоторое случайное блуждание вокруг цены последней сделки.
Насколько генератор пытается оценить величину реального спреда?


Абсолютно никак. И хорошо что Вы привели решение.

pyhta4og

У меня родилась некая идея как можно было бы генерировать стакан.
Я ее нарисовал на картинке. http://stocksharp.com/fo...lbum.aspx?u=285&a=9
Так вот, алгоритм следующй ( на картинке называется алгоритм2)

Пусть цена последней сделки(сделка1) равна P1. Симулятор знает цену следующей сделки после этой (в будущем) с ценой отличной от P1 (т.е. если после сделки1 идут несколько с той же ценой их пропускаем и берем следующую, с другой ценой). Пусть эта цена P2. Тогда после сделки1 (которая с ценой P1) принимаем лучший бид равным min(P1,P2), лучший аск равным max(P1,P2).

Если посмотреть на рисунок, то, как мне кажется, спред имитируется правдоподобно.


Рисунок мне нравиться. Не нравиться, то что сделку ищем в будущем. Потому как получается, что у нас есть сделка на текущей момент в истории. Она получилась не просто так, а потому что произошло пересечение бида и оффера в прошлом (миллисекунда назад или чуть больше, но это было, а не будет). Но идея очень интересная. Можно смотреть по прошедшим тика. Если у нас тики начинаю идти в разброс, значит спред раздвигается. И наоборот, если сделки начали идти во круг какой-то цены, значит происходила сдвижка спреда.

pyhta4og

В заключение уместно добавить, что я наткнулся на BidAskHistory.ru-вроде обещают продавать с миллисекундной точностью данные включая стаканы.


У них дата последняя за 11.2010. Они еще в седле?
Thanks:

pyhta4og

Avatar
Date: 2/21/2011
Reply


Mikhail Sukhov
pyhta4og

1. MarketTime прихода OnProcess не 0.1 сек как хотелось а 1.1 сек! А именно
10:30:20.900,10:30:22.000,10:30:23.100.

Это по-моему неправильно, раз я заказывал 0.1 сек.


А интервал у самой стратегии изменили? По умолчанию он как раз равен секунде. И видимо это и сыграло свою роль.

Поставил Strategy.Interval=TimeSpan.Zero. OnProcess начал приходить как заказывал в TimeShiftStrategyManager.TimeStep=0.1сек. В realtime не проверял, насколько корректно ставить Strategy.Interval=0?

Хотя, с этими интервалами реально путаница в случае с историческим тестироваием. Их слишком много ;)

Strategy.Interval
Дока:
Quote:
Интервал стратегии. Как часто StrategyManager будет вызывать метод Process(DateTime).
В реальности нет метода StrategyManager.Process(DateTime). Есть только факт того что Strategy.OnProcess вызывается не чаще чем этот интервал.

TimeShiftStrategyManager.TimeStep
Дока:
Quote:

Временной шаг перемещения во времени, на который будет изменятся время from до to в методе Start(DateTime, DateTime).

В реальности это минимальный интервал времени биржи Trader.MarketTime с которым вызывается Strategy.OnProcess.

результат моего эксперимента. Если поставть Strategy.Interval=1000msec, TimeShiftStrategyManager.TimeStep=200msec то OnProcess приходит с периодом 1200msec,
А если Strategy.Interval=999msec, а TimeShiftStrategyManager.TimeStep=200msec, то с периодом 1000msec.
Похоже там где-то > на >= надо заменить ;)

TimeShiftStrategyManager.Interval я бы переименовал в SimulationDelay, потому что это просто задержка программы симулятора на какое-то время и к Trader.MarketTime отношения похоже не имеет. Причем я поставил 1 секунду, а OnProcess у меня в реальности раз в 2 секунды вызывался (судя по наручным часам).


Плюс еще есть параметр конструктора HistoryTestTrader
дока:
Quote:

securitySettings:
// Инструменты, с которыми будет вестись работа, и интервал обновления для каждого
// инструмента. Интервал показывает степерь ликвидности инструмента, которое
// влияет на скорость обновления стакана.


В реальности я ставил всякие значения от 100 мс до 10 сек, но стаканы(генерированные) у меня приходили раз в 200 мсек, т.е. как указано было в TimeShiftStrategyManager.TimeStep=200мсек. Причем разные стаканы.

Так что поясните что такое "скорость обновления стакана" пожалуйста ;)


Quote:

pyhta4og

2. Новый стакан генерится с интервалом 0.1 сек, при этом опорная цена берется последняя из тиков датированных последней секундной отметкой.


Что в этом не так?


В общем-то все нормально, за исключением того что стоит подумать над реализацией более реалистичного стакана

Quote:

pyhta4og

3. В связи с первым пунктом писать тиковые стратегии не получится тк OnProcess после каждого тика не вызовется. Тут есть гипотеза что это в связи с тем что точность времени у тиков 1 секунда. Но все исторические источники обладают у нас таким недостатком.


Это не источник, а биржа. Она транслирует с секундной точностью.


Пусть у меня 10 тиков датированные 10:30:00. На ликвиде типа RIH1 этого предостаточно. Я хочу чтобы симулятор сам наставил им миллисекунд чтобы они равномерно распределились по промежутку 10:30:00-10:30:01. Тогда у меня будут нормально генерится стаканы, т.е. 1-й тик, 1-й стакан; 2-й тик, 2-й стакан и тд. Сейчас сначала все 10 тиков, потом стакан для последнего тика в секунде.

Насчет биржи. Если в тике нет миллисекундной пометки, а есть только секундная, то можно в realtime-адаптерах милисекунды прикидывать по фактическому времени прихода тика.
Т.е. пришел из смарта тик за 10:30:00 в 10:30:00.100. Он 100 мс шел от биржи через ITINVEST до S#. Cледующий пришел 10:30:00.500. Можно второму тику поставить 500-100=400 мсек, считая что они идут до нас одинаковый промежуток времени с биржи.





pyhta4og

4. Стакан генерируется с шагом цены 0.1 пункта вместо 5. Так и должно быть?


// создаем тестовый инструмент, на котором будет производится тестирование
var security = new Security
{
Id = "RTS-9.09", // по идентификатору инструмента будет искаться папка с историческими маркет данными
Code = "RI",
Name = "RI",
MinStepSize = 0.1,
MinStepPrice = 2,
Decimals = 1,
Exchange = Exchange.Test,
};

спасибо, теперь понял

Quote:

pyhta4og




5. По виду генерируемый стакан осуществляет некоторое случайное блуждание вокруг цены последней сделки.
Насколько генератор пытается оценить величину реального спреда?


Абсолютно никак. И хорошо что Вы привели решение.

pyhta4og

У меня родилась некая идея как можно было бы генерировать стакан.
Я ее нарисовал на картинке. http://stocksharp.com/fo...lbum.aspx?u=285&a=9
Так вот, алгоритм следующй ( на картинке называется алгоритм2)

Пусть цена последней сделки(сделка1) равна P1. Симулятор знает цену следующей сделки после этой (в будущем) с ценой отличной от P1 (т.е. если после сделки1 идут несколько с той же ценой их пропускаем и берем следующую, с другой ценой). Пусть эта цена P2. Тогда после сделки1 (которая с ценой P1) принимаем лучший бид равным min(P1,P2), лучший аск равным max(P1,P2).

Если посмотреть на рисунок, то, как мне кажется, спред имитируется правдоподобно.


Рисунок мне нравиться. Не нравиться, то что сделку ищем в будущем. Потому как получается, что у нас есть сделка на текущей момент в истории. Она получилась не просто так, а потому что произошло пересечение бида и оффера в прошлом (миллисекунда назад или чуть больше, но это было, а не будет). Но идея очень интересная. Можно смотреть по прошедшим тика. Если у нас тики начинаю идти в разброс, значит спред раздвигается. И наоборот, если сделки начали идти во круг какой-то цены, значит происходила сдвижка спреда.


Использование "будущих данных" при тестировании большой грех. Сам много "граалей" находил, которые вперед на 1 шаг заглядывали по ошибке кодирования;)

Но в данном случае по будущей получается красивее спред. Если брать расброс предыдущих, то следующая тиковая сделка может внутрь текущего имитируемого спреда попасть, а в случае с будущей - кладется на край имитируемого спреда как влитая.

Правда чтобы заимплементить хотя бы с вариантом "разброс в прошлом" надо чтобы MarketDepthGenerator знал историю сделок каждой бумаги. Можно хранить в нем Map<Security->Last_n_Ticks> и заполнять в Generate(Security) беря tick из Security.Price. Это если Generate вызывается ровно 1 раз на 1 тик. Но лучше его подписать на ITrader.NewTicks наверно...

А вот вариант с "будущей сделкой" как имплементить я не знаю потому что неведомо мне как читаются данные.




Quote:

pyhta4og

В заключение уместно добавить, что я наткнулся на BidAskHistory.ru-вроде обещают продавать с миллисекундной точностью данные включая стаканы.



У них дата последняя за 11.2010. Они еще в седле?



Не знаю. Пока ничего покупать не пытался, только пару демостаканов скачал.
Thanks:

Mikhail Sukhov

Avatar
Date: 2/21/2011
Reply


Цитировать уже нереально, буду по пунктам.

1. securitySettings - так правильно, тестирование оживает каждый раз, как только TimeStep увеличивает время. Соответственно и смотрится, если стакан должен был сгенерироваться (у него высокая ликвидность), он генерируется. Если нет (у него низкая ликвидность), ожидаем второй итерации.

2. Миллисекунды в тиках. Это уже эвристика пошла. Не уверен, что ее стоит зашивать внутрь S#.

3. "Если брать расброс предыдущих, то следующая тиковая сделка может внутрь текущего имитируемого спреда попасть". Это я не понял. Стакан строиться по тикам за период. Как будет влиять на спред то, какой именно период был взят, предыдущий или будущий?
Thanks:

Juri

Avatar
Date: 2/21/2011
Reply


Подскажите пожалуйста, где можно познакомиться с описанием существующего алгоритма генерации стакана?

Спасибо
Thanks:

Mikhail Sukhov

Avatar
Date: 2/21/2011
Reply


Juri
Подскажите пожалуйста, где можно познакомиться с описанием существующего алгоритма генерации стакана?

Спасибо


В аттаче. Это то что в версии 3.0.5
Thanks:
1 2  >

Attach files by dragging & dropping, , or pasting from the clipboard.

loading
clippy