my-trade

Какой тип переменной у вас для цен? C#,проблемка, нид хелп))

Изначально цены были во float, после перевода на decimal алгоритм замедлился в Nраз.
(Всмысле я не конвертировал каждый float в decimal, что вроде как нельзя, а просто изначально парсил биржевую ленту что б цена создавалась в decimal и дальше с ней работал).
 
Это у меня что-то не так или у вас такие же изменения в скорости? 

Задуматься о типе переменных заставил конкретный пример, когда лоу бара float 59,15 и рассчетную цену, округлённую до сотых через Round 59,15 алгоритм расценивает как не равные:
Какой тип переменной у вас для цен? C#,проблемка, нид хелп))



Вот еще решил поразвлекаться… (первая строчка — это тот же пример выше, оба типа там гарантированно float)↓

Какой тип переменной у вас для цен? C#,проблемка, нид хелп))

На decimal этот глюк пропадает.

Если у вас есть самописный алго, напишите чем пользуетесь и были ли такие ситуации, спс.
===============================================================

Всем спасибо, мне уже помогли. Публикую совет, который решил проблемы (остальные советы не успел проверить).
Уточняю, что округление было не Round, a Floor. 
То что выше — пример округления, которое было.
То что ниже — пример округления, которое теперь не глючит. 
(задача, округлить расчетную величину х 59.1576 вниз до ближайшего тика (по нефти CL)).

Какой тип переменной у вас для цен? C#,проблемка, нид хелп))

======================
Update2: я немного наврал насколько замедлился алго при переводе цен на decimal. (я при замерах скорости забыл кое-что отключить).
Реальное замедление составило 4 минуты за тот же кусок истории, который анализировался за 2.5. 

А это новое округление тоже замедлило алго… с 2.5 минут до 3х на том же куске истории (вдруг кому интересен вопрос скорости, мало ли).
★9
а зачем тебе decimal нужен был? ты бухгалтерию ведешь? зачем тебе точность в 29 знаков?

decimal это для финансовых расчетов
avatar

meat

meat, там фиксированная запятая и никаких подобных глюков нет, по крайней мере в моем примере глюк исчезает
Леха Мартьянов (my-trade), какой еще глюк? речь про тип данных, я вопрос же задал

ты знаешь в чем отличие от float, double и decimal?
meat, алсо погугли сравнение вещественных чисел
meat, Я бухгалтерию не веду, мне просто нужно что бы 59,15 было = 59,15.
float меня подводит.
Ты можешь что-то посоветовать, что бы это исправить, кроме как «погуглить самому»? 
Леха Мартьянов (my-trade), p = floor( p / point + 0.5 ) * point и будет тебе счастье. Какое тебе дело что там после значащей цифры, если после округления до нее все в порядке будет?
Леха Мартьянов (my-trade), а точность принципиальная? из за разных алгоритмов округления/экспорта/конвертирования иногда делал сравнение не с 0 а с какой-нибудь малой величиной. тем более тут цена, у которой количество знаков после запятой ограничено биржей, и, по идее, число 59,15 и число 59,15029349 вроде как одно и тоже
meat, Кто-то дал такой совет (не проверял еще)
«пусть умножит на 1 000000. потом округлит. а потом разделит на 1000000 обратно например… оставив в покое float»
Леха Мартьянов (my-trade), https://docs.microsoft.com/ru-ru/dotnet/api/system.single?view=netframework-4.8#testing-for-equality

почитай все, что там написано про этот тип

есть несколько разных вариантов сравнения, выбери какой тебе по точности необходим, можно самым простым как уже ниже написали с epsilon
Леха Мартьянов (my-trade), это — универсальный приём. С его помощью создаются «кластеры» значений данных с требуемым шагом. Для анализа статистики, например. Или для сравнений (в одном кластере или нет).
Леха Мартьянов (my-trade), деление очень затратная для процессора операция, лучше его избегать.
(пишу сюда, что б коммент был в самом верху).

В посте я говорю о том, что с новым округлением алго тоже замедлился.
Так вот на самом деле, оказалось, что он замедлился не из-за нового округления, а из-за изменения анализа с новым округлением… т.е. замедление не из-за математических рассчетов, а из-за того что в новой версии анализа появилось больше каких-то новых элементов и т.д. и т.п.

Короче, что моё глючное округление, что новое — занимает одинаковое кол-во времени.
Интересно. Послушаю. Начал изучать C#. 
В любом случи надо брать decimal. float и double не годятся для денежных расчетов.
Лет 5 назад тут все пестрело от C#… даже Мартын изучал
а щас все стихло )
разорились походу шарписты-алгоритмисты
avatar

astray

astray, Это печально).
Но по опыту разработки самописных алго могу сказать что они не разорились, а просто не осилили закончить то, что хотели реализовать, т.к. недооценили скрытый объем работы))). 
Леха Мартьянов (my-trade), мало того… не осилили скрытый психологический огромный груз который возникал после запуска робада на боевое депо
одно дело списать лусь на руки  . мол там не доглядел… поздно вошел

но на алгоритме сидишь на нервах как незнаю кто
ибо не знаешь.… перестал ли он уже работать в рынке
astray, а когда руками торгуете,
считается что система продолжает работать по умолчанию вечно? )
astray, это в точку прям! И когда на 100 процентов уверен, что он уже сломался и никогда не выйдет из минуса, не проходит и месяца, как хай переписан! 
astray, Шарп сейчас шибко никому не нужен. Старые шарписты еще держаться, а новых нет.
astray,  тут я, шарпист-алгоритмист . Правда у меня только консольные приложения с библиотекой alglib. А чисто для торговли trans2quik.dll. Поэтому никому не интересен.  Тем более у меня не полный робот: квик включи, программы закачки по DDE (спасибо Морошкину) запусти, торгового робота на C# запусти, днем изредка поглядывай, чтобы программа сравнения реальных и теоретических не «ругалась». Если последняя «ругается», то разберись в чем дело и если нужно программу коррекции запусти и в ней цену заявок вставь.
У меня специально нет проверки исполнения стоп-лимит заявок, чтобы не случилось зацикливания и набора позиции больше максимальной.

Ну и вечером дневную торговую программу выключи, а вечернюю включи. 
А. Г., Мой внутренний автоматизатор рутины очень бы ругался в таком контексте)).
А. Г., alglib и вправду «everywhere» ;)
А. Г., а как насчет transaq connector в т.ч. hft? Как никак родной конторский) Я, кстати, финамовский счет не бросаю только благодаря транзаку) 

chizhan, с моими «скоростями» — это очередная трата времени и куча кодов. Я с trans2quik. dll разбирался 3 месяца и то, только для того, чтобы ставить и снимать стоп-лимит заявки. Это раз. А два — это опять надо думать как закачивать таблицу всех сделок по нужным мне эмитентам, формировать минутки и бросать в MySQL, откуда их берут торговые алгоритмы. С последним я вообще не разбирался, а взял свободно распространяемый DDE сервер от Морошкина, позволяющий скачивать любую таблицу из квика и только добавил алгоритм формирования минуток и записи в базу. Причём последнее потому, что не смог в одном проекте совместить сервер и торговый алгоритм.

Так что если делать все своими руками, то вряд ли я сделаю лучше. Я ведь программирую на уровне 90-х: программы-подпрограммы. Из нового я изучил только связку C#-MySQL. 
А. Г., куда обратиться в случае чего вы знаете.
Тарас Громницкий,  да знаю конечно. Но народ там занятой, им не до меня. Мы вон уже год решаем задачу мобильной версии комона. А задачу отображения графиков с нуля при сдвиге ползунка вообще поставили в самый конец. 

А. Г., я человек не сильно скромный и имел в виду себя.

Что касается разработки на C# под Россию или запад.

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

Например работу с той же таблицей всех сделок и агрегацией данных в одном модуле.

Тарас Громницкий, да я с этим не разберусь. Классы и прочее, я в этом ничего не понимаю. Все это объектно-ориентированное программирование — это не моё. Я же говорю, что я программирую на уровне 90-х, когда ещё был MS-DOS. Вот как я изучал trans2quik. dll? Скачал файл с примерами и стал делать консольные приложения копипастом  и смотреть, что получается в квике. Только так опытным путем и вычленил, что мне надо и создал подпрограмму в торговом роботе, ставящую и снимающую стоп-лимит заявки. Про закачку уже писал: скачал код  открытыго DDE-сервера, нашёл в коде массив со скачиваемой таблицей и его образование, разобрался параметрами строк и столбцов и все. Дальше поставил свои параметры, настроил вывод таблицы, написал кусок обработки массива и закачки в MySQL. Все. В программу сверки объемов другими двумя консольными приложениями той же DDE-программой качаю две таблицы позиций: для фондового рынка и срочного, бросаю в текстовый файл, который берет программа сверки, как и txt файл, в который пишет торговая программа теоретические объёмы при каждой смене позиции и утром.

Как видите, минимум программирования, если не считать сами торговые алгоритмы. Но последние писать вообще просто: изначально пишется тестер системы, вырабатывающий эквити со всеми параметрами. А после выбора параметров просто копируется кусок этого кода, убирается цикл по параметрам, параметры просто задаются константами и все.
astray, Да нет, просто тихо моем бабки.
для чего это вообще?
Биотехнолог, пытается создать черный ящик… а на автомате рубить папло
Scorpion, никогда бы не доверил алгоритму торговать моими деньгами.
Биотехнолог, сам такой!!! 
Биотехнолог, Это звучит по меньшей мере странно, учитывая что в алго исполняет твою волю)) тот порядок действий, который ты в него вложишь). Только вот есть небольшое отличие, алго, в отличие от тебя, действительно так поступит, когда ты сам можешь нарушить свои же правила)).
Леха Мартьянов (my-trade), это не странно, потому что разворотные моменты не подаются стандартным описаниям. На разворотные моменты влияет куча факторов: наклонность тренда, закрытие свеч, длина свеч, уровни...
А иногда индексы оскакивают вообще без каких либо признаков разворота. Только потому что очень сильно упали без откатов.
Такое нельзя прописать алгоритмом.
Биотехнолог, лишние сделки надо убирать и всего то делов
Напрямую сравнивать на  = вещественные числа неправильно. Должно быть так:
f_eps = 0.000001
abs(c.low-unit.t.y)<f_eps

И да, нет смысла переходить с float(или double) на decimal.

Есть стандарты MISRA и CERT по надёжному программированию. Тупое следование их рекомендациям уберет 99% потенциальных ошибок.
avatar

v_0ver

v_0ver, Спс. 
А почему 0.000001,  а не больше или меньше?
Я просто в этом профан полный, спс.

Леха Мартьянов (my-trade),  это значение с какой точностью ты хочешь сравнивать значения. С точностью до одного знака после запятой (0.1), с точностью до 5-го знака после запятой (0.00001).
Эх, был же Леха раньше, как Леха… А ща, какуйто муйню несет, про float  шарпио и хуярпио. 
avatar

Scorpion

Scorpion, Соглашусь, постарел, обрюзг… занимаюсь какой-то хуйнёй, вместо того что б тёлочек жарить на острове

Scorpion, я помню еще Леху который говорил:

если к вам придет алгоритмист — сразу дайте ему в морду )

astray, в общем он своим коментом выше, рассказал все что думает об этом.В общем, он — переобулся. Скоро еще переедет куда нить в китай и все.((
astray, Да, было такое)) Правда я имел ввиду тех, кто не торговал руками… т.е. алгоритмизует не свой торговый опыт, а какие-то мат.модели\стат.закономерности

Леха Мартьянов (my-trade), не важно торговал руками или нет.

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

Или не показывает.

Собственно вы и сами занимаетесь созданием моделей.

Попробуй в отладчике на вкладке «Контрольные значения» написать:
c.low.ToString(«F10») и unit.r.y.ToString(«F10»)

Увидишь значения не с двумя знаками после запятой, а с 10. Может оно действительно меньше при использовании float.

Можешь попробовать использовать double. Он использует 64 бита на число(у float 32 бита).

Выше рекомендовали адаптировать сравнение:
вместо «c.low <= unit.r.y» использовать «c.low <= unit.r.y + Epsilon», где Epsilon константное значение, заданное тобой. Выбирается исходя из того, какая точность тебя устраивает. Если цена в долларах(т.е. 59.15 — это $59.15), то можешь попробовать Epsilon = 0.001d.
avatar

aks19

aks19, а если оба значения действительно будут равны, а мы ко второму еще и +0.001d прибавим, оно разве покажет, что они равны?

Леха Мартьянов (my-trade), исходный вопрос был именно про a <= b условии, что a и b float-ы. Именно для этого случая следует делать проверку указанным способом: a <= b + Epsilon.

Проверять же два float значения на равенство не следует через ==. Нужно делать следующим образом: Math.Abs(a — b) < Epsilon.
В противном случае что-то может пойти не так. 

aks19, Нифига… они все равно там равны




Леха Мартьянов (my-trade), хм...
a.ToString(«F10») возвращает строку, содержащую float-значение с 10 знаками после запятой.
Раз строки идентичны, видимо, разница между сравниваемыми числами меньше, чем 10^-10.

Можешь попробовать вывести 20 чисел в дробной части, т.е. a.ToString(«F20») и посмотреть, что там.

Есть еще такой вариант: ((decimal)c.low) — ((decimal)unit.r.y).
Т.е. мы знаем, что точности float нам не хватает. Поэтому мы конвертим оба float числа в decimal и смотрим там, сколько же составляет разница между нашими значениями. Видимо, она действительно крайне мала(https://www.youtube.com/watch?v=Dtjsm4TS0co).
aks19, ничего не помогло))

Леха Мартьянов (my-trade), Вот как правильно оказалось:




Не пользуюсь функцией Round. Если надо округлить, то умножаю на 10^n до нужного размера, беру целое, а потом делю на 10^n. Того глюка, который Вы описываете, нет. 
avatar

А. Г.

А. Г., а n насколько большие бывают?
aks19, да немного, у нас же нет цен больше, чем с 5 цифрами после запятой. 
А. Г., я правильно понимаю, что Вы сначала считаете выражение «цена * кол-во лот * размер лота», а потом его округляете своим методом?
aks19, нет. В double я считаю уровень, пробой которого означает операцию. Он считается «хитро» и имеет не то число знаков после запятой, что и цена. А в стоп-лимит заявку надо ставить именно цены. Для этого и округляется до ближайшей цены.
А. Г., ясно.
Просто способ такого округления опасный :)
Если х — float, то (x*10^3) / 10^3 не обязательно равно х.
aks19,  я уже писал, что у меня x double, а при взятии целого числитель вообще становится int. 
А. Г., ясно, Вам виднее, конечно.
Но в коде ниже мелкие расхождения уже проявляются(хотя дробная часть при умножении уходит):
class MainClass {public static void Main (string[] args) {double v = 0.0;for (int i = 0; i < 1000; ++i){v += 0.001;
var v1 = v * 1000;var v2 = v1 / 1000;if (v2 != v){Console.WriteLine($"{v} — {v2}");}}}}
А. Г., 
UPDATE: вариант которые помог опубликовал в этом посте

Дело в устройстве типа float.

Мантисса, все дела.

Можете тут поэкспериментировать 

https://www.h-schmidt.net/FloatConverter/IEEE754.html

А вообще каждый должен заниматься своим делом.

Если у трейдера есть стоящая идея, то от него требуется подробное описание, а всё остальное — это дело иных специалистов.

Стать нормальным программистом не быстро и не просто.

Наговнокодить конечно можно, но потом проблем и переделок не оберётесь.

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

Тарас Громницкий, Я тоже так раньше думал)).
По факту пишу алго уже где-то 4 года))). И начинал я именно со спецом программистом.
В итоге, сейчас, уже как год, пишу код уже сам, пользуясь тем, что с ним наработали за все это время. Я к текущему моменту уже сам в C# освоил всё то, что мне нужно для продолжения разработки торговых правил и анализа биржевой ленты.
Проблема оказалась, не в программисте. Он то как раз кодил все мои блок схемы как орешки. Проблема оказалась в том, что если торговые правила не совсем банальны, типа покупать на пересечении мувинга))), а довольно сложны (я ведь алгоритмизую то, как я сам вручную принимал решения и что я сам анализировал, торгуя руками), то сделать какое-то готовое подробное описание системы невозможно, ибо невозможно заранее всё просчитать в голове. В этом я уже убедился миллион раз. Даже сейчас, когда я сам кодирую свою же идею, когда я проверяю первые результаты — они в 99.9% случаев не соответствуют ожиданиям, потому что я недостаточно все продумал и просчитал все возможные условия и варианты с которыми пришлось иметь дело. Поэтому практически ВСЕГДА после отладки любой свеженаписанной схемы мне приходится дополнять его новыми условиями, которые я не смог изначально просчитать. Рынок всегда оказывается слишком сложен и изворотлив)).
Поэтому работа с программистом может быть более-менее приемлема, если вы с этим программистом вместе живете, спите, едите и не отходите друг от друга дальше чем на метр, иначе, при удалённое работе разработка замедляется в 10000 раз — это один из ответов на то, чем можно было заниматься столько лет и до сих пор не закончить работу))

Леха Мартьянов (my-trade), может уделять больше времени проектированию и обдумыванию деталей ?

Рисованию на бумаге, составлению блок-схем и пр.

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

Программист или вы сами.

В обоих случаях оно отнимет дополнительное время.

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

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

Тарас Громницкий, 
может уделять больше времени проектированию и обдумыванию деталей 

Это не помогает. Я в этом убедился на все 100%. Т.е. я могу заручится за то, что после 4-х лет разработки, следующую более-менее сложную схему я не смогу изначально просчитать на все 100% и заранее всё предусмотреть в своем же тех.задании (самому себе). Рынок всё равно подсунет на истории мне такие ситуации, которые мне и в голову не могли бы придти, даже если б я уехал в тибет на 2 года и пытался бы их все представить в своей голове. Это невозможно, даю зуб. 
Напротив, время и опыт разработки привели меня к тому, что бы не тратить много времени просчет всех возможных ситуаций в голове, а делать более-менее адекватный набросок блок-схемы, а потом допиливать её в процессе отладки, исключая неадекватные ситуации, в которые она по факту попадает (добавляя в неё новые логические условия), тем самым по факту допиливая эту схему до того конечного варианта, который я сам должен был, по вашему мнению, изначально просчитать в голове.

Возможно, все дело в том, что я просто тупой. Но мне кажется, что таких людей, которые могут все наперед просчитать в сложном алгоритме не существует. Даже я б сказал не ВСЁ а даже 85-90% конечного варианта.

Леха Мартьянов (my-trade), конечно могу ошибаться, но сдаётся мне, что вы излишне мудрите.

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

Т.е. у вас нет нужного инструментария(сущностей и связей) для корректного описания процесса.

В этом случае следует садиться и перелопачивать всю модель, формализуя упрощая и переводя её на качественно иной уровень.

А то можно получить тот же ад, что был у египтян с треугольниками.

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

Тарас Громницкий, Тарас)). Так мудрю то не из-за того, что шибко умный, а как раз таки из-за того, что слишком тупой по сравнению со сложностью рынка (да и по сравнению еще с много чем :).
Проблема в том, что на очень сложном рынке невозможно работать эффективно с простыми правилами — это только надежды для наивных глупцов. Другое дело, о чем вы и говорите, когда сложную систему можно описать настолько просто и лаконично, что она не будет содержать в себе миллионы условий и мегабайт кода, а будет компактной и на вид простой. Но не простой на самом деле.
Т.е. что б донести до вас мысль, вот простое действие: запросить значение последнего элемента в списке. Это простое действие. Но если ты запрашиваешь последний элемент, зная какое-там ранжирование, соот-но тоже самое действие обретает дополнительный смысл и взаимосвязь. 
И когда сложный неудобный код сложной системы оптимизируется, избавляясь от ненужных нагромождений, то условий становится меньше, то на каждое из них становится в несколько раз больше смысла и взаимосвязей, чем раньше.
Поэтому, знаете ли, что бы сложную систему написать просто и лаконично, на практике просто невозможно переступить через этап нагромождений и огромного неповоротливого кода, потому что, как я уже озвучил, невозможно изначально всё так продумать в своей голове. При сложной разработке можно лишь только НАЧАТЬ делать… а со временем оптимизировать, упрощать, разбивать нагромождения и т.д. Т.е. это как бы живой процесс. Я не верю в то, что в сложной разработке можно сразу прыгнуть в конечную точку, в которой умный алго будет сразу представлен
на вид простыми правилами, но на самом деле в этой простоте будет гениальность, т.к. (как я уже написал) за каждым из этих простых правил будет много смысла и много взаимосвязей… отличающих их от реально банальных правил, которые тоже выглядят простыми, но за собой не имеют глубины.

Леха Мартьянов (my-trade), в том то и дело.

Похоже вы пытаетесь произвести интегрирование при помощи примитивных операций.

Ну или построить ракету из дерева.

Необходимо подниматься выше.

И программирование тут не поможет, поскольку является лишь инструментом.

Скорее вам нужна более сложная и функциональная математика.

Тарас Громницкий, Возможно… нужна. Но я об этом никогда не узнаю, потому что в математике полный ноль)). Поэтому работаю с тем, что имею).
Леха Мартьянов (my-trade), 
Проблема в том, что на очень сложном рынке невозможно работать эффективно с простыми правилами — это только надежды для наивных глупцов.
Работают и простые правила, но для этого нужно иметь преимущество в чём-то ещё. Например, в арбитражных стратегиях логика обычно весьма примитивна.
Eugene Logunov, ну это да… но я не избранный и не имею никаких технических преимуществ ни в чем.
Тарас Громницкий, Но еще раз, оговорюсь, что главная проблема написать умный алгоритм простыми правилами коротко и лаконично заключается в том, что сложно сделать ТЗ конечного варианта. Если бы существовало тех. задание и полное подробное описание алго, то даже сложный алгоритм, наверное, возможно закодить просто и лаконично с первого раза. Поэтому проблема в том, что в процессе разработки ТЗ меняется, дополняется, усложняется… и это невозможно обойти.
Леха Мартьянов (my-trade), речь скорее о полной формализации того, что трейдер-ручник воспринимает как должное — роботу эти «самособой-вещи» приходится дожевывать и дожевывать уже после того, как система казалось бы формализована и для какого-нибудь толкового ученика этого было бы достаточно. Роботу этого мало.

Возможно, все дело в том, что я просто тупой.


Леха Мартьянов (my-trade), нет, не тупой, просто вы вначале наработки программистского опыта и такого же мироощущения.


Первые 10 лет нарабатывать этот опыт и менять мироощущение особенно интересно за счёт постоянного эффекта новизны. 

Леха Мартьянов (my-trade), +100500
Леха Мартьянов (my-trade), 
Поэтому практически ВСЕГДА после отладки любой свеженаписанной схемы мне приходится дополнять его новыми условиями, которые я не смог изначально просчитать. Рынок всегда оказывается слишком сложен и изворотлив)).
При таком подходе есть риск скатиться к подгонке стратегии под исторические данные :\
Eugene Logunov, я возможно просто плохо описал ситуацию. Задача что бы алго входил в конкретных формациях. Но когда я эти формации описываю, то на практике под эти же критерии попадают и другие, совершенно не приемлемые, но формально проходящие мои критерии ситуации. Т.е. это означает, что я просто сделал неполное ТЗ… не просчитал реально всех логические условия, которые отфильтруют то, что не похоже на нужный паттерн.
Eugene Logunov, при таком подходе есть риск просто сойти с ума в какой-то момент )))
ПBМ,  тоже только double и int использую. 

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

Выставляешь заявку — приведи цену к шагу цены.

А во внутренних расчётах оставляй как есть, разницы не должно быть какая у тебя цифра 59,15 или 59,1499999999999999999999

Aleksey Smirnoff, мне перед тем, как купить или продать нужно сделать анализ. Один из его элементов — коснулась ли цена какого-то уровня. В вашем вышенаписанном случае 59.1499999 формально не коснулась 59.15, поэтому анализ получается не правильным.

Леха Мартьянов (my-trade), занимаюсь алготрейдингом 11 лет, не считаю что анализ пострадает от такой неточности.

Рынок сам по себе ещё более неточный, не коснётся цена на 59.15, так коснётся 59.16. 

Леха Мартьянов (my-trade), любой уровень — не палосачка, а зона.
Как зону роботу и подавать (диапазон Мин/Мах).
Это я не учу — уверен, что сами это давно знаете.
во время разработки что бы от точности не страдать используй decimal, но с ним тоже есть несколько приколов (от сборки зависит).
и только потом если скорости будет не хватать думай про оптимизацию.
но что у тебя там за расчёты такие, что decimal тормозит? :)

до чего прогресс дошёл, легенда скальпинга программированием занялся :)
Алексей, обновил инфу в посте… я немного напутал, замедление на самом деле намного меньше...  прошу прощения за дезинформацию. 
Я так понял тебе никто не ответил. Если речь про два знака после запятой. Умножаешь на 100, прибавляешь 0.5, округляешь в меньшую сторону и делишь на 100
Все цены в double, перед сравнением на равенство использую округление до нужного шага. Мелкие неточности не играют роли.
Jame Bonds, у меня эти мелкие неточности возвращают false вместо true). А это, как бы, уже большая разница. Это уже как купить или продать)). Разница есть.
Леха Мартьянов (my-trade), читайте внимательно, используйте округление до шага цены и мелкие неточности не будут влиять.
Jame Bonds, проблема и была округлить до ближайшего тика, это оказалось не так то просто)). Правильный ответ обновил в теле поста.

Следующее правило определяет операцию остатка от деления:
а % b == а — math.floor(a/b)*b
Для целочисленных операндов она работает обычным образом и дает
результат с тем же знаком, что и у второго аргумента. Для вещественных
операндов у нее есть некоторое дополнительное применение. Например,
х%1 дает дробную часть х, следовательно, х-х%1 дает его целую часть.
Аналогично, х-х%0.01 дает х ровно с двумя десятичными цифрами после
запятой:
х = math.pi
print(х — х%0.01) --> 3.14

х = math.pi
print(х — х%0.01) --> 3.14


vladimir55, прикольное расширение операции % на плавучку. 

Посмотрел Python и Ruby — там тоже это реализовано. 


Да, и на Java'е — тоже, и на JavaScript'е...


Тот же C#...

А C/C++ на плавучке этого не поддерживают. 

Красивое решение. 

Очень интересно, но не чего не понял. 
на тиках мне кажется мало рыбы осталось, ну по крайней мере во так сходу,
сам фреймворки переписывал раза 4 наверное
щас гибрид котлин + питон, всю тиковую часть снес для упрощения.
На шарпе был тоже фреймворк который на тиках бэктестил, тогда с линуксом он не очень дружил поэтому двинул в жвм.
Питон очень рекомендую чтобы полуфабрикат выплюнутый стратегий повертеть
Я использую прием который позволяет мне протестировать много факторов без лишних прогонов стратегии: беру базовую стратегию и к сделкам прикручиваю факторы, потом смотрю в питоне как и какие факторы влияют на прибыльность, получается гораздо быстрее чем оптимизировать по факторам.
ваще хрень какая то ...
когда в почте увидел в теме письма «My-trade написал пост на смартлабе»,
Я глазам … ля не поверил!! 

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

а тут че?

че… ля? че за?, че за х…ня … ля!!! да вы че гоните!???    

@#$%^!!!





avatar

Timik88

Timik88, кто-то взломал его страницу, видимо)).
Леха Мартьянов (my-trade), 
UPDATE: вариант которые помог опубликовал в этом посте
Леха Мартьянов (my-trade), не знаю что ты там пытался сделать, но ты взял все равно опять decimal
meat, Почему? у меня decimal на нижнем скрине только для пользователей смартлаба)). Типо показать, что нижнее округление работает. А в самом округлении только float, никакого decimal. 
Леха Мартьянов (my-trade), покажи хоть эквити того, что уже есть?
ПBМ, 
UPDATE: вариант которые помог опубликовал в этом посте
Для хранения и расчётов можно long (System.Int64) использовать. Цены с бирж приходят с плавающей точкой, переводишь их в целое —
long priceTicks = (long)(price / ticksize + 0.4)
Будет и быстро и по памяти оптимально.
avatar

Mike

Mike, Откуда у вас 0.4 то взялось? Понимаю, если бы 0.5 добавили…
Eugene Logunov, был опыт с IQFeed, там иногда приходит цена с точностью большей чем один цент. Например 50.55543211, в тиках это 5055.54321, прибавим 0.4 и округлим до наименьшего целого, получим 5055. Если прибавить 0.5 то после округления получается на тик больше. Субъективно это кажется неверно, так как нет информации почему цена иногда приходит с точностью больше одного цента.
ПBМ, 
он родной для всех процов
Можно ещё вспомнить про 80-битное представление вещественных чисел (C: long double; Delphi/Pascal: extended; asm: tbyte), оно вроде бы ещё более родное для FPU :)
б) использованием алгоритма Кэхэна  — он работает быстро.
Да, этот вычислительный трюк — просто огонь, хоть и нужен крайне редко.

p.s. Тоже практически везде использую double, точности хватает.
The0bald, может и самообман, но с новой округлялкой алго стал мне возвращать TRUE вместо FALSE в моей глючной ситуации, а мне пока большего и не нужно
Для не целочисленных значений использую double. Несколько классов, в свое время, успел перевести/реализовать на decimal, и уже пожалел об этом. В процессе написания различных стратегий, так или иначе все равно приходится часто приводить значения к double.
Есть один момент — стратегии ни разу не ХФТ.
avatar

Prophetic

Ivanka, я больше программист, чем трейдер.

Собственные стратегии меня пока что не устраивают.

У моих клиентов(трейдеров) получается значительно лучше.

Есть несколько человек со стратегиями большой ёмкости и среднегодовой доходностью 20-30% на горизонте более 5 лет и просадкой в районе 5%.


....все тэги
UPDONW