Баго-фича при сохранении данных Trade

Баго-фича при сохранении данных Trade
Atom
11/10/2012
DrChemist


Решил описать один неприятный эффект, с которым мне пришлось столкнуться и который, увы, забрал много времени.

Если Trade.Price содержит «лишние» десятичные цифры после запятой (по всей видимости, цифры большей точности, чем Security.MinStepPrice), то при сохранении таких данных в TradeStorage и последующем чтении данные очень сильно искажаются ( более чем на 100%) из-за больших накапливающихся ошибок.

У меня этот эффект возник при генерации и сохранении искусственных сделок, информацию для которых я брал из альтернативных (кастом) таблиц (мировые индексы, по которым не поступала информация в таблицу всех сделок).

Tags:


Thanks:


Mikhail Sukhov

Avatar
Date: 11/11/2012
Reply


Проблема определена. Будет фикс на Кодеплексе. Сейчас хранилище поддерживает цены, не кратные шагу. Предполагается, что такая цена может возникнуть у внесистемных сделок (не обязательное условие).
Thanks:

Mikhail Sukhov

Avatar
Date: 11/12/2012
Reply


Mikhail Sukhov
Проблема определена. Будет фикс на Кодеплексе. Сейчас хранилище поддерживает цены, не кратные шагу. Предполагается, что такая цена может возникнуть у внесистемных сделок (не обязательное условие).


Фикс доступен на кодеплексе. Просьба отписаться о результатах.
Thanks:

DrChemist

Avatar
Date: 11/14/2012
Reply


Проверил на версии 4.1.6
Подтверждаю. Проблема устранена полностью . Данные читаются и восстанавливаются точно с любым количеством десятичных знаков после запятой в поле Price.

Для тех, кому это может быть нужно, обращаю внимание, что, по всей видимости, формат записи изменился. Мне не удалось прочитать данные записанные версией 4.1.6 программой, использующей библиотеку 4.1.5

Однако я обнаружил еще один эффект, с которым хотел бы разобраться.
Дело в том, что я обнаружил, что в хранилище сохраняются не все искусственные сделки, которые я создаю.
Возможно, происходит некоторая фильтрация ( возможно, правильная) или в _tradesBuffer Гидры или в самом хранилище.

Дело в том, что данные из кастом таблиц Quik, по всей видимости, приходят с дублированием:

Вот типичный пример, сделанный по моим собственным независимым логам:

Code

1. miniSP500&WIDX,20:14:01,2012-11-14 20:14:01.0(00:00:01.9850995),1365.73553345389,buy
2. miniSP500&WIDX,20:14:01,2012-11-14 20:14:01.0(00:00:01.9850995),1365.73553345389,sell
3. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:00.9850995),1365.73553345389,buy
4. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:00.9850995),1365.73553345389,sell
5. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:01.9444995),1365.73704038577,buy
6. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:01.9454995),1365.73704038577,sell
7. miniSP500&WIDX,20:14:03,2012-11-14 20:14:03.0(00:00:00.9464995),1365.73704038577,buy
8. miniSP500&WIDX,20:14:03,2012-11-14 20:14:03.0(00:00:00.9464995),1365.73704038577,sell


Время указано по данным из таблицы, в скобках задержка по отношению к компьютерному времени.

Если посмотреть, например, на строки 2 и 4, 5 и 7, то видно, что они соответствуют строго одному и тому же компьютерному времени, но задержки как-бы разные. Все параметры сделки, кроме времени в них идентичны.

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

Из хранилища были прочитаны вот эти данные:

Code

[1]	{2012-11-14 20:14:01 0 1365.73553345389 1}
[2]	{2012-11-14 20:14:01 0 1365.73553345389 1}
[3]	{2012-11-14 20:14:02 0 1365.73553345389 1}
[4]	{2012-11-14 20:14:02 0 1365.73553345389 1}
[7]	{2012-11-14 20:14:03 0 1365.73704038577 1}
[8]	{2012-11-14 20:14:03 0 1365.73704038577 1}


Т.е. сделки, соответствующие строкам 5 и 6 были отфильтрованы (отбракованы?) и не были сохранены.

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранении, и по каким принципам?


Thanks: Геннадий Ванин (Gennady Vanin)

Mikhail Sukhov

Avatar
Date: 11/15/2012
Reply


DrChemist

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранении, и по каким принципам?


В примере нет самого важного параметра - номера сделки.
Thanks:

DrChemist

Avatar
Date: 11/16/2012
Reply


Mikhail Sukhov

В примере нет самого важного параметра - номера сделки.


Что-то я недооценил этот параметр. Его нет потому, что его нет[bored] Т.е. он всегда ноль.
Искусственные сделки я создаю вот таким кодом, который находится в подкрученном HydraQuikTrader.cs:
(QuikStockIndexes - моя собственная структура, используемая в кастом таблице, откуда я буру данные)

Code

                List<Trade> toTrades = new List<Trade>();
                foreach (QuikStockIndexes si in _idxData)
                {
                    var mySecurLst = _secur.Where(s => (s.Id == (si.SecurID + "@" + si.ClassID)));
                    if (mySecurLst.Any())
                    {
                        var mySecur = mySecurLst.First();
                        var myTrade = new Trade
                        {
                            Security = mySecur,
                            Price = si.Price, //decimal.Round(si.Price, 4),
                            Volume = 1,
                            Time = si.UpdateTime,
                            Latency = si.Latency,
                            OrderDirection = OrderDirections.Buy
                        };
                        toTrades.Add(myTrade);
                    }
                }

                smTestLog( toTrades);

                if (toTrades.Any())
                    RaiseNewTrades(toTrades);


Для правильного сохранения нужно обязательно определять еще и Id?
Тогда не подскажете ли как правильно его определять? Можно ли использовать простой счетчик или нужно что-то более сложное?
Thanks:


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

loading
clippy