Вопрос к мастерам MQL4. Опять про Double Compare. - страница 10

Новый комментарий
 
Simca:
SK. писал (а):

Приношу свои искренние соболезнования разработчикам, вынужденным по 1000 раз объяснять одно и то же каждому новому юзеру..



Это уже откровенный наезд...
Согласен. Хотя SK. авторитет на форуме, но "специфические компьютерные технологии" у меня тоже вызывают подозрение.
Про хранение вещественных чисел в памяти написано в учебниках и там ничего не сказано про то, что переменные могут сами по себе измениться. Хотя на этом форуме я слышал это не только от SK.
Поэтому, если Вы 1000 раз ввели в заблуждение каждого нового юзера, Вам надо теперь их найти и извениться за свои слова!

Я согласен с Simca . При выполнении арифметических операций возможны недочеты, а при хранении, записи или чтении они исключены!

Поэтому я и спрашивал алгоритм работы функции NormalizeDouble(), возможно,  в ней тоже есть арифметические операции, которые приводят к ошибке?
Как думаешь Simca?
 

ОК. Вы так уверенно об этом говорите, что я уже и засомневалсы в своих словах.

До некоторых пор мне приходилось работать на старом ПК с оперативкой 256Мб. При подгузке нескольких программ операционка выгружала часть данных на диск, а потом их снова загружала. С тех пор, как я переделал код (указание нормализации в операторе сравнения) ошибка перестала появляться. Но после ваших слов уже засомневался - а вдруг я и правда там что-то ещё наисправлял, да и не заметил.

Не знаю теперь - извиняться или нет.. Если я не прав, то пусть 1000 юзеров меня простят.

(но всё же нормализацию лучше производить непосредственно при вычислении операции сравнения:)

 
gravity001:
Про хранение вещественных чисел в памяти написано в учебниках и там ничего не сказано про то, что переменные могут сами по себе измениться. Хотя на этом форуме я слышал это не только от SK.
При хранении ничего само по себе не изменяется. А вот способ представления вещественных чисел в памяти компьютера влияет на точность (разрядность) хранимых значений. При арифметических операциях с вещественными числами результат зачастую бывает "недостаточно точным" (с человеческой точки зрения), поэтому иногда требуется нормализация результата операции. Однозначно надо нормализовывать результат операций при последующем сравнении на равенство (часто и на >, <). Также надо нормализовывать результат если оперируете значениями с необходимой жестко заданной разрядностью (например цены). Сами по себе промежуточные вычисления с вещественными числами как правило нормализации не требуют.
Но, все это относится к вычислениям, храниться же значения в памяти будут неизменными, что нормализованные они, что нет.
gravity001:
Поэтому я и спрашивал алгоритм работы функции NormalizeDouble(), возможно, в ней тоже есть арифметические операции, которые приводят к ошибке?
Как думаешь Simca?
Ну, об алгоритме работы функции NormalizeDouble надо спрашивать у разработчиков, к коим я не отношусь. :) Кроме того это не относится к предмету спора, ибо функция NormalizeDouble фигурировала в обоих фрагментах кода в абсолютно идентичном варианте применения. Вся разница заключалась только в непосредственном сравнении результатов двух нормализаций, против предварительной записи этих результатов в переменные с последующим сравнением значений переменных. На что я и заметил, что так как тип возвращаемого функцией NormalizeDouble значения совпадает с типом используемой для хранения переменной, то разницы между приведенными фрагментами не будет никакой. Вот если бы функция NormalizeDouble возвращала значение большей разрядности чем переменная в которую оно помещается, то тогда разница могла бы появиться и однозначно нельзя бы было говорить об идентичности. Но суда по HELP-у MetaEditor-а тип данных в обоих случаях double, следовательно разницы быть не должно, независимо от способа реализации функции NormalizeDouble.
 
SK. писал (а):

(но всё же нормализацию лучше производить непосредственно при вычислении операции сравнения:)

А вот с этим, в применении к каждому новому юзеру, я абсолютно согласен. Если нет четкого представления что и как функционирует, то наиболее разумно идти по более безопасному и надежному пути! Но это ж не к нам с Вами относится. :)
А со своей стороны (для тех кто не до конца понимает суть вопроса) тоже могу порекомендовать:

но всё же нормализацию лучше производить непосредственно при вычислении операции сравнения (с) SK.

 
SK. писал (а):

(но всё же нормализацию лучше производить непосредственно при
вычислении операции сравнения:)





Сорри, но с точки зрения эффективности есть гораздо более удачные реализации для сравнение данных, требующих нормализации. Вобщем, это стандарт (алгоритм сравнения). Нужно сравнивать разницу  с половиной размерности шкалы. О чем это я: для сравнения цен (отличаются или нет) нужно взять разницу и сравнить с величиной 0,5*Роинт ( ее можно вычислить  всего один раз при инициализации эксперта\скрипта\индикатора. Это значительно эффективнее вызова одной функции, а тем более двух, а если еще и в цикле).... И будет все равно как эти данные хранятся и до какого незначащего знака округляются.

Успехов.
 
РИЗОЛЬТАТЫ ИССЛЕДОВАНИЕВ СРАВНЕНИЯ ДАБЛОВ в mql4. Во-первых, работа с даблами - это чисто компильлерская фишка, поэтому требовать удобства от mql4, который по сути - скрыпт с интырпритатором, неумесна. Главная, разработчеки дали способ, ГАРАНТИРОВАННО правильного результата сравнения, мы его проверили ручками, он, конечно, грамостковат, но РАБОЧЕЙ!!! Хотя в докуминтацыи указано, что нормалезовать надо тока в случае "!=" или "==", нащы незовисимыя икспертныя испытания показали, что (a>b) НЕ ГОРАНТИРОВАИТ (!) корректный результат в случае, если a окажется равной b! Даже если вы ПРИДВОРИТИЛЬНО нормольлезовале и а и b, 1 хрен при равенстве чисел результат непредскозуем. А вот конструкцыя разработчиков::: NormalizeDouble(a-b, Digits)>0 работает надёжно! Не знаю, чем тута товарещам не понравилася ф-ция нормолезацыи... Можабыть она (ВНУТРИ) вполне семпотична зделана вот так: два дабла делятся на дабл точности, и округляются в меньшую (или большую сторону). А посли - сравнивайются целые беспроблемна.
 
.FG писал (а):
РИЗОЛЬТАТЫ ИССЛЕДОВАНИЕВ СРАВНЕНИЯ ДАБЛОВ в mql4. Во-первых, работа с даблами - это чисто компильлерская фишка, поэтому требовать удобства от mql4, который по сути - скрыпт с интырпритатором, неумесна. Главная, разработчеки дали способ, ГАРАНТИРОВАННО правильного результата сравнения, мы его проверили ручками, он, конечно, грамостковат, но РАБОЧЕЙ!!! Хотя в докуминтацыи указано, что нормалезовать надо тока в случае "!=" или "==", нащы незовисимыя икспертныя испытания показали, что (a>b) НЕ ГОРАНТИРОВАИТ (!) корректный результат в случае, если a окажется равной b! Даже если вы ПРИДВОРИТИЛЬНО нормольлезовале и а и b, 1 хрен при равенстве чисел результат непредскозуем. А вот конструкцыя разработчиков::: NormalizeDouble(a-b, Digits)>0 работает надёжно! Не знаю, чем тута товарещам не понравилася ф-ция нормолезацыи... Можабыть она (ВНУТРИ) вполне семпотична зделана вот так: два дабла делятся на дабл точности, и округляются в меньшую (или большую сторону). А посли - сравнивайются целые беспроблемна.

Прошу Вас писать на правильном русском языке.

 
Дайти мне ссылку на сайт розработчека (русского языка), и, обещаю, что буду испоьзовать ТОЛЬКО ОПРЕДЕЛЕНИЯ АВТОРА. :) Ваш изык, на мой взглят, не более правилен, чем мой, но если ВАМ ЛИЧНО чижыло понемать, то я буду делоть перивод "спицыально для Rosh", ежоли вы не могити отлечить бла-бла от експертной аценке. Потому как я не вам писал, а 1001-ому новичку. :)
 
.FG писал (а):
Дайти мне ссылку на сайт розработчека (русского языка), и, обещаю, что буду испоьзовать ТОЛЬКО ОПРЕДЕЛЕНИЯ АВТОРА. :) Ваш изык, на мой взглят, не более правилен, чем мой, но если ВАМ ЛИЧНО чижыло понемать, то я буду делоть перивод "спицыально для Rosh", ежоли вы не могити отлечить бла-бла от експертной аценке. Потому как я не вам писал, а 1001-ому новичку. :)

Например, www.gramota.ru

У нас нет олбанского раздела форума. Тем не менее, после следующего же сообщения не по-русски Вы будете отправлены именно туда. Пожалуйста, не надо коверкать великий и могучий.

 
В таком случае, шли бы вы, stringo, к Кириллу и Мефодию с Почётной Грамотой за успехи в программировании! :) Фиксишь косяки товаресчей, а они есчо и не довольны. Все эти проблемы с нормализацыей я встречал ишо в досовских компилерах бесплатных, которые уже давно реализованы по-удобному в текущих версиях. Поэтому некоторым программистам и не понять, зачем такая допотопная проверка даблов. Когда они перепишут свои коды, громоздя всюду сравниваемый с нулём нормолайз, то удивятся, обнаружив отсутствие ошибок в собственной "С-логике", и недостаточно ГРАМОТНЫМ комментам отцов-реализаторов. Потому что можно до посинения тут постить об оптимизации и пр. второстепенных весщах, тренируясь в формалезации никому не нужных статистических приёмов, но вопросы, касаемые РЕЗУЛЬТАТОВ базовых вычислений - останутся краеугольными, требующими первостепенного освещения. А будете мне ищо грозить отправлением, мы уйдём на какуюнить CME, вазмём у их документатцыю и напищым прогу с FIX'ом и пр. наворотами НА ОЛБАНСКОМ. :) И вы останетеся без работы. Сделоете mq6 и будити сидеть воденочестве, и захотите, чтобва хоть ктота потестил вашы изделия, ну хоть по-албанске, ан нет, нас уже не будит... Потому что вы сами нас забанели втихую... :)))))))))))))))))))))))000
1...34567891011
Новый комментарий
Причина обращения: