MetaTrader 4. Build 159. - страница 6

Новый комментарий
 
Объясните в чем проблема.
int i;
double baseBid;

i = 100 + (Bid - baseBid)/Point;



При смещении Bid на 1 пункт от baseBid получается i=101.
При смещении на 2 пункта - все равно i=101.

 
Объясните в чем проблема.
int i;
double baseBid;

i = 100 + (Bid - baseBid)/Point;



При смещении Bid на 1 пункт от baseBid получается i=101.
При смещении на 2 пункта - все равно i=101.



Приводите, пожалуйста, точные значения переменных.
В данном случае, Bid был равен XXX, basebid=YYY, Point=0.0001, получился такой-то результат. Почему?
 

Приводите, пожалуйста, точные значения переменных.
В данном случае, Bid был равен XXX, basebid=YYY, Point=0.0001, получился такой-то результат. Почему?


Renat, привожу точные значения.
baseBid = 1.2972, Point = 0.0001.

При Bid = 1.2973 получается всегда i = 100, хотя должно быть i = 101.
При других значениях Bid все получается правильно.
Какое-то наваждение !
 

Приводите, пожалуйста, точные значения переменных.
В данном случае, Bid был равен XXX, basebid=YYY, Point=0.0001, получился такой-то результат. Почему?


Renat, привожу точные значения.
baseBid = 1.2972, Point = 0.0001.

При Bid = 1.2973 получается всегда i = 100, хотя должно быть i = 101.
При других значениях Bid все получается правильно.
Какое-то наваждение !

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

Вот пример на C/C++:
   double baseBid=1.2972,Bid=1.2973,Point=0.0001;
   int i = 100 + (Bid - baseBid)/Point;
   printf("%d\n",i);


тоже выдает 100.

Тоже самое будет практически в других языках программирования.
Это давно известная проблема округлений - всегда проявляется в финансовом софте.
Обычное решение - добавление половинной погрешности к результату деления.

   double baseBid=1.2972,Bid=1.2973,Point=0.0001;
   int i = 100 + (Point/2+(Bid - baseBid)/Point);
   printf("%d\n",i);
 
2005.03.23 17:00:45 '14070': opening order buy stop 1.00 EURJPY at 137.6900 sl: 137.4800 tp: 0.0000 failed [Invalid S/L or T/P]


А где был рынок в момент установки отложенного ордера? Укажите Bid/Ask.
Похоже что Open price слишком близко к рынку стоял - на него тоже "Invalid S/L or T/P" получить можно.

Проверка на отступ стоплосса от цены открытия тут не причем.
Где проверка на отступ цены Open price от текущей цены Ask ?

Ренат, у меня проверяется _всё_ (по крайней мере, я так думаю =) В том числе и расстояние цены от опенпрайс, СЛ/ТП от опенпрайс, кол-во лотов.. Всё нормализуется и только потом идёт запрос...
 
А где был рынок в момент установки отложенного ордера? Укажите Bid/Ask.

в ту минуту (15:54) лоу был 137.58, хай - 137.64. точнее не скажу
 
Renat, спасибо за подсказку, хотя мне это и не нравится.
Почему тогда все нормально срабатывает при всех других значениях Bid,
кроме отличающегося на +1 пункт ?
И будет ли правильным результат, полученный по Вашему методу,
при всех значениях разности в скобках ? Не хочется тратить время на проверку.

Может в MQL есть какая-нибудь функция нормального округления до целого ?
 
А где был рынок в момент установки отложенного ордера? Укажите Bid/Ask.

в ту минуту (15:54) лоу был 137.58, хай - 137.64. точнее не скажу

Тогда все сходится. Покупка совершается по цене Ask, а на графиках - биды. Если бид=137.64, то аск = 137.68
Была попытка провести операцию buy stop 1.00 EURJPY at 137.6900 sl: 137.4800 tp: 0.0000
Сразу видно, что цена открытия в 1 пункте от рыночной цены. А минимальный отступ для EURJPY 5 пунктов.
То есть, ордер мог пройти только по цене не меньше 137.72
 
Renat, спасибо за подсказку, хотя мне это и не нравится.

А это мало кому нравится. Многие программисты финансового софта с этим постоянно сталкиваются.
Вроде складываешь, вычисляешь, а потом получаешь: $1.00 + $1.00 = $2.01

Почему тогда все нормально срабатывает при всех других значениях Bid,
кроме отличающегося на +1 пункт ?

Особенности округления в архитектуре X86.

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

В данном случае будет все правильно. Очень грубое правило "добавить половину погрешности".

Может в MQL есть какая-нибудь функция нормального округления до целого ?

К сожалению, нет. Округления надо контролировать самостоятельно.

Рекомендую поискать в яндексе про огругление вычислений - очень много интересного узнаете.
 
А это мало кому нравится. Многие программисты финансового софта с этим постоянно сталкиваются.
Вроде складываешь, вычисляешь, а потом получаешь: $1.00 + $1.00 = $2.01

Беда в том, что деньги нельзя выражать вещественными числами, полкопейки смысла не имеют (обычно).
Для этого есть другие типы данных - Decimal, Money, на худой конец Int32.
И котировки правильнее было бы представлять в поинтах в Int32 (внутри МТ),
И места меньше занимает, и вероятность всяких описанных проблем меньше.
А так получается что свои внутренние проблемы (ошибки проектирования) вы на юзеров перекладываете,
да еще обвиняете их при этом в недалекости ...
1234567
Новый комментарий