NormalizeDouble VS MathRound - страница 6

Новый комментарий
 
kermit:

Т.е.

double a=OrderOpenPrice()

переменная "а" пусть ведёт себя как и раньше, а значение OrderOpenPrice() и т.п. всегда было по умолчанию нормализовано.


Такое возможно?

Все значения внутри ордера уже нормализованы с допустимой погрешностью в подавляющем бОльшинстве случаев.

Но! Если используется банковское свопирование через переоткрытие позиций, то цена OrderOpenPrice() будет иметь бОльшее количестов знаков после запятой.

Пример (значения примерные):
была позиция #10 BUY 1.00 EURUSD at 1.4550, market 1.4570
лонг своп 0.3 пипса через переоткрытие
в конце рабочего дня закрываем позицию #10 BUY 1.00 EURUSD at 1.4550, close at 1.4570
и тут же ее переоткрываем с учетом свопа #11 BUY 1.00 EURUSD at 1.45703, market 1.4570
Вот так вот легко OrderOpenPrice меняет точность с 4х знаков после запятой до 5 знаков после запятой.

ps: рекомендую не выдумывать правила математических операций и округлений, а принять все как есть. Мы не с потолка взяли условия - уже 8-й год пишем торговый софт.
 

По закрытию этой сделки мне всё равно учтут не 1.45703, а "округлённое" значение. При всех конечных расчётах всё равно используется цена кратная Point.

Так почему при работе пользователя используется "промежуточная" цена? Пусть терминал работает с "промежуточными" значениями, а пользователю по запросу выдаётся уже нормализованная цена. ту, которую ему потом зачтут.

Я понимаю, что нам дают возможность увидеть "реальные рабочие" цены, но зачем они пользователю, если деньги дают только по ценам кратным Point?

 
kermit:

По закрытию этой сделки мне всё равно учтут не 1.45703, а "округлённое" значение. При всех конечных расчётах всё равно используется цена кратная Point.

Так почему при работе пользователя используется "промежуточная" цена? Пусть терминал работает с "промежуточными" значениями, а пользователю по запросу выдаётся уже нормализованная цена. ту, которую ему потом зачтут.

Я понимаю, что нам дают возможность увидеть "реальные рабочие" цены, но зачем они пользователю, если деньги дают только по ценам кратным Point?

Учтут и Покажут в отчетах именно цену 1.45703 - чтобы это проверить, достаточно открыть счет или демку в компании (обычно банки), которая использует свопы через переоткрытие позиций.
 

Про банки, которые начисляют свопы переокрытием я не подумал ... хотя изначальный вопрос возник на интрадэевских операциях, где о свопах речь не идёт и цена ни просто не "ровная", а отличается на 0.00...01 от должной из-за чего и ошибка.

:)

 
кстати, а почему на форуме нет смайлов? хотя бы самых примитивных?
 
kermit:
кстати, а почему на форуме нет смайлов? хотя бы самых примитивных?

И где я только раньше был.... :(..... два дня потерял, пока это в эксперте отловил.... пытался так:

if (OrderOpenPrice()==NormalizeDouble(LevelOpen, Digits)..........

а надо было так:

if (NormalizeDouble(OrderOpenPrice(),Digits)==NormalizeDouble(LevelOpen, Digits)..........


Так что "примитавные"  не подойдут, ту матершинные просяися :)

 

Тему специально не перечитывал дабы не сбиться с мысли...

И так... имеем округление вниз. С этим всё понятно, НО! имеем при этом и накапливающуюся ошибку.

Есть ли возможность создать пользовательскую функцию со своим типом нормализации?

Например "математическую штатную" или с округлением вверх.

Таким образом слагая расчёты произведёные мкл4 со своими расчётами получим более точный результат.

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

*

Или я на неверном пути, точнее пошел на поводу у мысли? :)))

123456
Новый комментарий