Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
То же самое, что и "int intCheck", но значение присваивается перед функцией, как и другим переменным.
Так это будет работать?
Так это будет работать?
Конечно НЕТ, это только для простых вычислений для рыночных парсов или подобных с меньшим количеством цифр. Ничего не будет работать, если более 10 цифр считаются по обе стороны десятичной точки вместе, пределы. Просто игрушка.
Не усложняйте слишком много
Является ли что-то (или какая-то идея) сложным или сложной - это, я полагаю, вопрос индивидуальной интерпретации.
Плавающее деление, плавающее сложение, преобразование в int, вызов функции (копирование, переход, возврат = 3,) * 2 - все это умножается на два. (18) И это при условии, что деление и преобразование находятся на одном уровне с другими операциями - это не так.
Я никогда не хотел сказать, что решение, которое я создал и использую, является самым эффективным - я понимаю, что это может быть не так. Но важно то, что (1) я понимаю (и на данный момент могу терпеть) его дополнительные накладные расходы и вычислительные затраты и (2) оно решает проблему (по крайней мере, для меня) сравнения двух цен, которые находятся в формате двойной точности с плавающей точкой.
В конечном счете, я понимаю проблему, присущую сравнению на равенство двух реальных чисел, которые находятся в формате двойной точности с плавающей запятой, но я думаю, что вы и я подошли к этой проблеме немного по-разному в данном контексте. Вы используете то, что я мог бы назвать "эпсилонным сравнением", чтобы определить, достаточно ли близки два двойных числа, чтобы воспринимать их как равные - то есть, если разница между двумя двойными числами находится в пределах вашего максимального отклонения (Point / 2.), то эти два двойных числа равны. С другой стороны, я решил превратить цены в инты для сравнения путем деления на Point, округления до ближайшего целого числа, сохранения результата как инт, а затем сравнения двух интов. Я использовал вызов функции, а не встроенный код, потому что это более естественно для меня - я склонен группировать код по подпрограммам/функциям - и потому что это потенциально многоразовое использование (возможно, из-за той небольшой части меня, которая думает в терминах ООП). Я многое взял из того, что вы сказали 16 февраля 2012 года:
Двойное значение от брокера может быть где угодно от 1,2345750000000000 до 1,234584999999999 и все равно будет считаться той же ценой 1,23458.
Именно поэтому я решил округлить до ближайшего целого числа, а не усекать десятичную часть после деления на Point, но перед преобразованием double в int.
Все это не означает, что я не согласен с тем, что вы написали. Скорее, это признание того, что я ознакомился с тем, что вы написали, и сохраню это для дальнейшего использования (и для потенциального использования позже, если понадобится). :)
Как всегда, приветствуются поучительные/конструктивные комментарии. :)
Я считаю, что вопрос о том, является ли что-то (или какая-то идея) сложным или комплексным, является вопросом индивидуальной интерпретации.
Я никогда не хотел сказать, что решение, которое я создал и использую, является самым эффективным - я понимаю, что это может быть не так. Но важно то, что (1) я понимаю (и в данный момент могу терпеть) его дополнительные накладные расходы и вычислительные затраты и (2) оно решает проблему (по крайней мере, для меня) сравнения двух цен, которые находятся в формате двойной точности с плавающей точкой.
Я согласен с вами. ... и я также согласен сWHRoeder.
Мой код был написан для того, чтобы было что подключить к существующему коду, не ломая его и не тратя много часов на поиск ошибок, поэтому он достиг своей цели. Я также хотел бы хотя бы частично учесть то, что написалWHRoeder, и придумать лучшую версию того, что я делаю, сохранив при этом читабельность для моего использования. Если мне это удастся, я опубликую это в этой теме.
Если у меня что-то из этого получится, я опубликую это в этой теме.
Моя функция Flat() была в 17 раз медленнее, чем решениеWHRoeder, у меня есть предложение, которое, как мне кажется, более читабельно и всего в 3 или 4 раза медленнее, в зависимости от типа сравнения. 3 или 4 раза медленнее - это не очень хорошо, но по сравнению с 17-кратным замедлением - это большое улучшение. Я немного протестировал его, пока не очень широко.
Использование:
Типы сравнения: EQ - равно, NEQ - не равно, GT - больше, чем и LT - меньше, чем.
Просто ваши bools
Хорошее замечание.
Производительность существенно не изменилась.
Правила предшествования Не (!) почти самое высокое: когда первое != второму в точности, (!ABS(ненулевое) > nz) == (0 > nz) == false. Если f==s, то (!0 > nz) == (1 > p/2) == true, если точка < 1
Да, хороший улов ...