Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
вы создайте значение типа 1,3333333333333333333 и выведите его в Comment("Point value= ",DoubleToStr(.....,5));
также и для 1,33(3):
преобразовать в строку, убрать точку, преобразовать в инт )))
умный как утка, а плаваешь как утюг :)
может каждому свой интерпретатор языка mql писать, давайте каждый заниматься своим делом..
Я написал про то, как работает FPU (часть процессора CPU - железо) и это приемлемо во всём мире, например в компиляторах от MS, Intel, gcc.
Надо быть очень внимательным, когда работаете с числами с плавающей точкой, особенно, когда имеет место преобразование результата вычисления.
Вот об такой код, чистый с точки зрения школьной математики, ломают копья мужи:
В обоих случаях должна получиться 7, но во втором получится 6.
Дело тут, как я уже писал, в том, что нет точного представления числа 0.7 и при преобразовании из double в int не происходит округления.
Что бы избежать ошибки используйте функцию MathRound.
мне все равно не понятно почему умножение на 0.1 не равно делению на 10 ?
может каждому свой интерпретатор языка mql писать, давайте каждый заниматься своим делом..
При чем тут mql? Лет 20 назад писал на paradox-е программульку одну для процессингового центра счета-фактуры печатать для банков. И вот тоже, думал глюк какой-то: то в одну сторону округлит, то в другую... А банки ить за копейку удавятся ))). А оказалось, что это так и задумано: округлять в сторону нечетного числа - чтобы ошибка округления не накапливалась при длинной цепочке вычислений. RTFM, короче ))
При чем тут mql? Лет 20 назад писал на paradox-е программульку одну для процессингового центра счета-фактуры печатать для банков. И вот тоже, думал глюк какой-то: то в одну сторону округлит, то в другую... А банки ить за копейку удавятся ))). А оказалось, что это так и задумано: округлять в сторону нечетного числа - чтобы ошибка округления не накапливалась при длинной цепочке вычислений. RTFM, короче ))
да, в общем-то понятно что ртфм
Как сохранить\загрузить сеттинг настроек для индикатора?
В предыдущих версиях были кнопки сохранить\загрузить - теперь НЕТУ!!!!
и вы считаете, что вы правы в том что написали ? это неприемлемо !
вот варианты
вот результаты
2014.03.04 18:14:37.565 debug GBPUSDX,H1: from 5023 2942 2142 3591 2177 2177 2177
предложите свои варианты реализации так, что бы отношение цены на поинт всегда давало именно то значение, которое человек вычисляет правильно, а код нет
зы. тут даже нормализация не спасает..
Разработчики правы. Сэмулируйте округление:
мне все равно не понятно почему умножение на 0.1 не равно делению на 10 ?
Как сохранить\загрузить сеттинг настроек для индикатора?
В предыдущих версиях были кнопки сохранить\загрузить - теперь НЕТУ!!!!
мне все равно не понятно почему умножение на 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 от частного недостаточно?