MetaTrader 4 Client Terminal build 610 - страница 70

 
VOLDEMAR:

вы создайте значение типа 1,3333333333333333333 и выведите его в Comment("Point value= ",DoubleToStr(.....,5));
Работает:
#property strict
void start()
{
double dgt=MarketInfo(Symbol(),MODE_DIGITS);

Comment(DoubleToString(0.123456789*0.123456789,16),"\n",DoubleToString(0.123456789*0.123456789,5));
}
также и для 1,33(3):
 
kazakov.v:

преобразовать в строку, убрать точку, преобразовать в инт )))




умный как утка, а плаваешь как утюг :)

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

 
mql5:

Я написал про то, как работает FPU (часть процессора CPU - железо) и это приемлемо во всём мире, например в компиляторах от MS, Intel, gcc.
Надо быть очень внимательным, когда работаете с числами с плавающей точкой, особенно, когда имеет место преобразование результата вычисления.

Вот об такой код, чистый с точки зрения школьной математики, ломают копья мужи:


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

Дело тут, как я уже писал, в том, что нет точного представления числа 0.7 и при преобразовании из double в int не происходит округления.

Что бы избежать ошибки используйте функцию MathRound.



мне все равно не понятно почему умножение на 0.1 не равно делению на 10 ?
 
keekkenen:


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

При чем тут mql? Лет 20 назад писал на paradox-е программульку одну для процессингового центра счета-фактуры печатать для банков. И вот тоже, думал глюк какой-то: то в одну сторону округлит, то в другую... А банки ить за копейку удавятся ))). А оказалось, что это так и задумано: округлять в сторону нечетного числа - чтобы ошибка округления не накапливалась при длинной цепочке вычислений. RTFM, короче ))

 
kazakov.v:

При чем тут mql? Лет 20 назад писал на paradox-е программульку одну для процессингового центра счета-фактуры печатать для банков. И вот тоже, думал глюк какой-то: то в одну сторону округлит, то в другую... А банки ить за копейку удавятся ))). А оказалось, что это так и задумано: округлять в сторону нечетного числа - чтобы ошибка округления не накапливалась при длинной цепочке вычислений. RTFM, короче ))


да, в общем-то понятно что ртфм
 

Как сохранить\загрузить сеттинг настроек для индикатора?
В предыдущих версиях были кнопки сохранить\загрузить - теперь НЕТУ!!!!

 
keekkenen:


и вы считаете, что вы правы в том что написали ? это неприемлемо !

вот варианты

вот результаты

2014.03.04 18:14:37.565 debug GBPUSDX,H1: from 5023 2942 2142 3591 2177 2177 2177

предложите свои варианты реализации так, что бы отношение цены на поинт всегда давало именно то значение, которое человек вычисляет правильно, а код нет

зы. тут даже нормализация не спасает..


Разработчики правы. Сэмулируйте округление:

int value=0;
...
value=Close[i]/Point+0.5;
...
 
keekkenen:

мне все равно не понятно почему умножение на 0.1 не равно делению на 10 ?
https://www.mql5.com/ru/articles/1561
 
Mamed:

Как сохранить\загрузить сеттинг настроек для индикатора?
В предыдущих версиях были кнопки сохранить\загрузить - теперь НЕТУ!!!!

 
angevoyageur 04.03.2014 21:55 #
keekkenen:

мне все равно не понятно почему умножение на 0.1 не равно делению на 10 ?

https://www.mql5.com/ru/articles/1561


Вообще-то вижу две потенциальных причины.

1. Абсолютно точное в десятичном виде число 0.1 представляется в двоичном виде как бесконечная периодическая дробь 0.0(0011). Которая при любой разрядности формата двоичного числа неизбежно портится путем обрезания. Для двоичного представления чисел в компьютере 1/5 - такой же ужас, как для десятичного представления 1/3 = 0.(3). Эта беда - только для дробных чисел, без дробей все точно раскладывается на степени двойки: 3=1+2, 5=1+0+4, 10=0+2+0+8.

2. Это говорится в ссылке выше, результат деления двух целых будет целым. Независимо от того, куда потом его надо будет переписать в ходе операции присвоения, в целое или в double. Подсчет арифметических выражений требует места в памяти, куда заносится промежуточный результат. Место экономят. Также экономят время, преобразовывать всякий раз к длинному объединяющему все варианты виду некогда. Обычно размер отводимой для него памяти и формат хранения определяется по типам операндов. Если оба целые, то и формат для промежуточного результата целый.

По поводу неточности деления Close[i]/Point.

"keekkenen: предложите свои варианты реализации так, что бы отношение цены на поинт всегда давало именно то значение, которое человек вычисляет правильно, а код нет"

А что, разве взять MathRound от частного недостаточно?

value=(int)MathRound(Close[i]/Point);
if(MathAbs(value*Point-Close[i])>0.00000001) // Для курса достаточно совпадения первых цифр, до восьмой в дробной части, как мне представляется. double удерживает 16-17 значащих цифр, ста миллионов в целой части хватит