Почему double, а не decimal?

А ведь ни цены, ни объём не могут быть отрицательными. Почему бы не использовать для цен тот же самы...

2012-11-07T05:25:13Z

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

Alexander Mukhanchikov

А ведь ни цены, ни объём не могут быть отрицательными.
Почему бы не использовать для цен тот же самый Decimal, а для объёмов ulong?

Зато их разница - может
Текущая чистая позиция - разница объёмов, может быть отрицательная
"% изменения от закрытия"
Вход. чист. поз.

Разница цены последней к оценке предыдущей сессиии
Разница цены последней к предыдущей сессиии
и т.д.

Половина парметров, которыми я пользуюсь из КВИК, могут быть отрицательными

И? Мы и используем decimal поэтому.

А ведь ни цены, ни объём не могут быть отрицательными. Почему бы не использовать для цен тот же самы...

2012-11-06T20:56:37Z

Alexander Mukhanchikov

И при чем тут деление? Не понимаю :) Подозреваю, что кусов кода и текст ошибки не связаны между собо...

2011-05-02T13:27:21Z

Mikhail Sukhov

Maxim

И при чем тут деление? Не понимаю :)

Подозреваю, что кусов кода и текст ошибки не связаны между собой.

Я тоже это подозреваю.
Потому что программа просто заканчивается.
Никаких привычных исключений в дебагере не появляется.

Исключение, которое я написал, появляется в Output окне.

И при чем тут деление? Не понимаю :) Подозреваю, что кусов кода и текст ошибки не связаны между собо...

2011-05-02T09:22:35Z

Maxim

И при чем тут деление? Не понимаю :)

Подозреваю, что кусов кода и текст ошибки не связаны между собой.

Михаил, может сталкивались со следующим? При выполнении участка кода: ring _query = "SELECT HistoryI...

2011-05-02T08:32:14Z

Михаил, может сталкивались со следующим?

При выполнении участка кода:

Code

ring _query = "SELECT HistoryId, Money, Paper FROM {0} WHERE Date = (SELECT MAX(DATE) FROM {0} )";
_query = String.Format(_query, sqlTableName);
SqlCommand _sqlCommand = new SqlCommand(_query, _sqlConn);

using (SqlDataReader _dataReader = _sqlCommand.ExecuteReader())
  while (_dataReader.Read())
  {
      HistoryId = _dataReader.GetInt64(0);
      Money = _dataReader.GetDecimal(1);
      Paper = _dataReader.GetInt32(2);
  }

Получается исключение:

Code

A first chance exception of type 'System.DivideByZeroException' occurred in mscorlib.dll
System.Transactions Critical: 0 : <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Critical"><TraceIdentifier>http://msdn.microsoft.com/TraceCodes/System/ActivityTracing/2004/07/Reliability/Exception/Unhandled</TraceIdentifier><Description>Unhandled exception</Description><AppDomain>Mts.vshost.exe</AppDomain><Exception><ExceptionType>System.DivideByZeroException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType><Message>Attempted to divide by zero.</Message><StackTrace> at System.Decimal.FCallDivide(Decimal&amp; d1, Decimal&amp; d2)
at System.Decimal.op_Division(Decimal d1, Decimal d2)
at Goricap.Mts.BuySell.&lt;initProfitTimer&gt;b__c(Object data) in G:\C\Development\MTS_Decimal\Programm\BuySellClass.cs:line 333
at System.Threading._TimerCallback.TimerCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading._TimerCallback.PerformTimerCallback(Object state)</StackTrace><ExceptionString>System.DivideByZeroException: Attempted to divide by zero.
at System.Decimal.FCallDivide(Decimal&amp; d1, Decimal&amp; d2)
at System.Decimal.op_Division(Decimal d1, Decimal d2)
at Goricap.Mts.BuySell.&lt;initProfitTimer&gt;b__c(Object data) in G:\C\Development\MTS_Decimal\Programm\BuySellClass.cs:line 333
at System.Threading._TimerCallback.TimerCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading._TimerCallback.PerformTimerCallback(Object state)</ExceptionString></Exception></TraceRecord>

Исключения появляется при исполнении
using (SqlDataReader _dataReader = _sqlCommand.ExecuteReader())

Раньше было Double, все работало. Ошибка появилась после перехода на Decimal.
Буду благодарен помощи.
Гугление как то не дает результатов.

И при чем тут деление? Не понимаю :)

Если говорить о тех анализе, я его вообще считаю профанацией. А это, мне кажется, надо сделать слог...

2011-05-01T15:54:29Z

Maxim

Mikhail Sukhov

Если говорить о тех анализе, я его вообще считаю профанацией.[laugh]

А это, мне кажется, надо сделать слоганом S# :)

Это мое личное мнение. А так, на S# чего только не делалось (не мной). В том числе и тех анализ.

Так сделано сейчас в HistoryEmulationTrader. Вы еще что-то на части разбиваете? Для бектестинга не ...

2011-05-01T15:53:33Z

Maxim

Mikhail Sukhov

Так сделано сейчас в HistoryEmulationTrader. Вы еще что-то на части разбиваете?

Для бектестинга не использую S#. Все свое :)

Значит нужно сделать переход на S# и решить проблему с потреблением памяти.

Если говорить о тех анализе, я его вообще считаю профанацией. А это, мне кажется, надо сделать слог...

2011-05-01T15:30:07Z

Mikhail Sukhov

Если говорить о тех анализе, я его вообще считаю профанацией.[laugh]

А это, мне кажется, надо сделать слоганом S# :)

Так сделано сейчас в HistoryEmulationTrader. Вы еще что-то на части разбиваете? Для бектестинга не ...

2011-05-01T15:25:48Z

Mikhail Sukhov

Так сделано сейчас в HistoryEmulationTrader. Вы еще что-то на части разбиваете?

Для бектестинга не использую S#. Все свое :)

Mikhail Sukhov

А вы пробовали в конце сессии писать результирующие данные, чтобы на следующий день не делать пересчет для 6 гигов тиков?

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

Maxim

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

Я не использую S# для бектестинга )

Maxim

Вам то удалось самому найти такой алго?

Торговый робот работает с нового года.
До этого времени шел поиск золотого грааля :)
Но постоянно возникают косяки, которые мешают оценить результативность алго.
(Стоит уточнить, что в среднем одна-две сделки в неделю)
Так что через месяц другой может смогу дать Вам ответ.

Все верно пишите. Только как раз не хотелось заниматься разбитием процесса на части (загрузки и выгр...

2011-05-01T14:11:26Z

Maxim

Все верно пишите.
Только как раз не хотелось заниматься разбитием процесса на части (загрузки и выгрузки частями).

Так сделано сейчас в HistoryEmulationTrader. Вы еще что-то на части разбиваете?

Maxim

Если касательно торгового робота (где я использую S#), то 5.6 гигов необходимо один раз, при первом старте стратегии, что бы просчитать все данные которые, были с начала истории по текущий момент.

Maxim

Если касательно бэктестинга, то там я S# не использую. Но там много памяти надо постоянно :)

Maxim

Считаю, что если алгоритм с небольшим количеством параметров (у меня ~7) дает хорошие результаты на 10 годах истории, то с большой вероятностью он будет хорошим и в ближайшие пол года. То есть подгонка в некоторых случаях имеет право на жизнь.
Вы не согласны?

Если говорить о тех анализе, я его вообще считаю профанацией.[laugh] А если ближе к деталям, то у нас рынок меняется каждые 2 года и кризисы каждые 5 лет[smile] . С этими факторами российского стиля жизни сложно найти инструменту, который бы был стабилет на стратегии в течении 10 лет. Так что да, я не верю, что алго даст профит хотя бы на ближайшие пол года. Я думаю это плохое тестирование, которые в реальности не показало бы на прошедших 10 годах тот показатель, что был получен на истории.

Вам то удалось самому найти такой алго?

Все верно пишите. Только как раз не хотелось заниматься разбитием процесса на части (загрузки и выгр...

2011-05-01T13:58:39Z

Все верно пишите.
Только как раз не хотелось заниматься разбитием процесса на части (загрузки и выгрузки частями).

Если касательно торгового робота (где я использую S#), то 5.6 гигов необходимо один раз, при первом старте стратегии, что бы просчитать все данные которые, были с начала истории по текущий момент.

Если касательно бэктестинга, то там я S# не использую. Но там много памяти надо постоянно :)

Считаю, что если алгоритм с небольшим количеством параметров (у меня ~7) дает хорошие результаты на 10 годах истории, то с большой вероятностью он будет хорошим и в ближайшие пол года. То есть подгонка в некоторых случаях имеет право на жизнь.
Вы не согласны?

Перевел на decimal. Потребление ОЗУ увеличилось с 5.6Гб до 6.6Гб. Пока что влажу в лимит. Все правил...

2011-05-01T13:33:11Z

Maxim

Перевел на decimal.
Потребление ОЗУ увеличилось с 5.6Гб до 6.6Гб.
Пока что влажу в лимит.

Все правильно, размер Trade увеличился на 1.18. Меня пугает размер 5.6. Это получается что-то порядка 136 282 616 тиков. Уверены, что такой сайз нужен в памяти? Больше выделение объемов памяти плохо сказывается на производительности GC. Плюс не совсем понятно, зачем такой объем держать. Чтобы оптимизировать стратегию необходимо небольшой участок данных. Далее, найденные значения применяются ко всему периоду, который подгружается частями и выгружается. Держать больший период в памяти имеет смысл, если на нем идет частая проверка данных. Если это как раз оптимизация - то это уже плохо с точки зрения поиска на истории, так как идет подгонка параметров.

Алгоритм приблизительно такой: пробегаем по всем историческим данным и находим несколько производных...

2011-05-01T08:16:14Z

Maxim

Алгоритм приблизительно такой:
пробегаем по всем историческим данным и находим несколько производных значений от цены и объема, например, для каждой секунды.
Конечно, можно сделать разбиение на части и уложится даже в 10Мб.

Но зачем усложнять жизнь, если все можно одним куском в память запихнуть?

В случаи не бектестинга, а робота, это надо сделать только один раз.
Просчитать все данные. После этого прога работает в 32 битном режиме и 7 гиов
ей не надо.

Если у Вас несколько таких роботов будет, то сколько памяти потребуется? И нет тут никакого особого усложнения жизни - сделаете еще одного робота, и придется все равно ее себе "усложнять". И дело не в double-decimal, а в проектировании программы: если так делать, то Вам вскорости никакой памяти не хватит.

Алгоритм приблизительно такой: пробегаем по всем историческим данным и находим несколько производных...

2011-05-01T05:49:03Z

Данные для тестирования беру из SQL. Наверно, для понимания моей ситуации стоит отметить, перед перв...

2011-04-30T16:18:07Z

Maxim

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

B для этого Вам нужно забивать 7 гигов памяти? А не проще ли сохранять значения в sql или подгружать данные не все разом а постепенно пакетно? А вообще мне очень интересно как Вы умудряетесь забить 5-7 гигов памяти, ведь наверняка активно пользуете намного меньше.

Перевел на decimal. Потребление ОЗУ увеличилось с 5.6Гб до 6.6Гб. Пока что влажу в лимит. Эх, все же...

2011-04-30T15:33:11Z

Перевел на decimal.
Потребление ОЗУ увеличилось с 5.6Гб до 6.6Гб.
Пока что влажу в лимит.

Эх, все же придется задуматься об оптимизации алгоритмов.

Также замечу, что некоторые методы Math и DateTime не принимают Decimal.
Лишнее преобразование в Double :)

Вот кстати сегодня тоже обнаружил что мой робот кушает 470мб оперативки. Это работа с 4мя квиками (г...

2011-04-29T20:29:21Z

Вот кстати сегодня тоже обнаружил что мой робот кушает 470мб оперативки.
Это работа с 4мя квиками (где берутся ленты и стаканы из каждого квика), и по 3 стратегии на каждом квике.

Не знаю много это или нет, т.к. не помню сколько было.

Данные для тестирования беру из SQL. Результаты тестирования сохраняю в SQL. SQL кушает порядка гига...

2011-04-29T19:18:01Z

Данные для тестирования беру из SQL.
Результаты тестирования сохраняю в SQL.
SQL кушает порядка гигабайта.

Насчет того, насколько увеличилось потребление памяти
при переходе на decimal сейчас сказать не могу. Все еще
в процессе переделывания на новый лад. Как сделаю, напишу.
Перенос всей программы на decimal то еще увлекательное мероприятие :)

Но чисто теоретически, double занимает 8байт, decimal 16 байт.
71млн значений цены для сбера занимали ~500Мб, теперь должны занимать ~1000Мб.
Производных данных от цены меньше, но надо будет посмотреть сколько это все вместе
будет теперь занимать.

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

Пока все это писал, понял, что Вы скорей всего не поймете
моей ситуации, так как для этого надо более детально описывать
структуру моего торгового робота.

Проехали :)

Основная мысль, что переход на decimal для меня тот еще геморой.
А с другой стороны все устраивало на double.

Поздно конечно пить боржомии... Напишу основной минус, который вижу для себя. Размер необходимой пам...

2011-04-29T18:50:48Z

Maxim

Поздно конечно пить боржомии...
Напишу основной минус, который вижу для себя.
Размер необходимой памяти для дабл в два раз больше.
И для хранения в SQL и для ОЗУ.

При тестировании на истории Sql не используется. Насчет занимаемой памяти я так и не понял, возросло с переходом на decimal или не возросло.

Поздно конечно пить боржомии... Напишу основной минус, который вижу для себя. Размер необходимой пам...

2011-04-29T14:45:27Z

Поздно конечно пить боржомии...
Напишу основной минус, который вижу для себя.
Размер необходимой памяти для дабл в два раз больше.
И для хранения в SQL и для ОЗУ.

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

На текущий момент бэктестинг еле влезает в 8Гб ОЗУ.
Больше ОЗУ добавить низя. Нужен новый сервер.
Правда там же крутится SQL.

Крайне неохото разбивать процесс на этапы, что бы
оставаться на том же железе. Пока еще не перевел
все на decimal. Очень надеюсь, что все влезет.

Вначале пути тоже выбирал double или decimal.
Выбрал double исключительно из-за ОЗУ.

Это все так... Лирика.
Больше некому поплакаться, не поймут. [rolleyes]