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


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

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


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

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





Спасибо:


1 2  >
Mikhail Sukhov

Фотография
Дата: 15.02.2011
Ответить


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 просто логически быссмысленнен. И конечно, чем больше шаг, тем больше маркет-данных.
Спасибо:

anebotov

Фотография
Дата: 17.02.2011
Ответить


Mikhail Sukhov Перейти
pyhta4og Перейти

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

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


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

Mikhail Sukhov

Фотография
Дата: 17.02.2011
Ответить


anebotov Перейти

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


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

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


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


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

anebotov

Фотография
Дата: 17.02.2011
Ответить


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

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

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

pyhta4og

Фотография
Дата: 19.02.2011
Ответить


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

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

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

Получил
Код

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-вроде обещают продавать с миллисекундной точностью данные включая стаканы.

Спасибо:

Mikhail Sukhov

Фотография
Дата: 20.02.2011
Ответить


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. Они еще в седле?
Спасибо:

pyhta4og

Фотография
Дата: 21.02.2011
Ответить


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
Дока:
Цитата:
Интервал стратегии. Как часто StrategyManager будет вызывать метод Process(DateTime).
В реальности нет метода StrategyManager.Process(DateTime). Есть только факт того что Strategy.OnProcess вызывается не чаще чем этот интервал.

TimeShiftStrategyManager.TimeStep
Дока:
Цитата:

Временной шаг перемещения во времени, на который будет изменятся время 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
дока:
Цитата:

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


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

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


Цитата:

pyhta4og Перейти

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


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


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

Цитата:

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,
};

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

Цитата:

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 наверно...

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




Цитата:

pyhta4og Перейти

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



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



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

Mikhail Sukhov

Фотография
Дата: 21.02.2011
Ответить


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

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

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

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

Juri

Фотография
Дата: 21.02.2011
Ответить


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

Спасибо
Спасибо:

Mikhail Sukhov

Фотография
Дата: 21.02.2011
Ответить


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

Спасибо


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

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy