[mrcnn]

А ведь предупреждали: не сравнивайте вещественные числа между собой. Нет же, пока САМ не обожжется - должен попробовать. // http://forum.pascalnet.ru/lofiversio...hp/t24610.html

ВОТ ПРИМЕР КАК ОБЖИГАЮТСЯ

select * from table_name where val=1.7
Значение 1.5 остается как было, значение 1.7 меняется на 1.70000004768372. // http://www.sql.ru/forum/958491/strannyy-kosyak-s-float

ГДЕ ТА БЕСКОНЕЧНОСТЬ, КОТОРУЮ ВЫ ТУТ МНЕ ПЫТАЕТЕСЬ ДОКАЗАТЬ?

А число 1.7 в двоичной системе имеет бесконечный хвост, который сохранить полностью не представляется возможным. // http://www.sql.ru/forum/958491/strannyy-kosyak-s-float

Это, кстати, касается и случая, когда Вы сравниваете вещественные числа, не учитывая точность представления чисел. Посмотрев в отладчике, что числа, вроде как одинаковые, но сравнение срабатывает так, как будто они разные, Вы не задумались бы, что именно в сравнении содержится ошибка. // http://popoff.donetsk.ua/text/work/prg/debug.html

У вещественных чисел есть погрешность. Сравнивайте не "равно", а больше/меньше, с учетом этой погрешности. // http://linuxforum.ru/viewtopic.php?id=4076

Не сравнивайте на равенство вещественные числа. // http://www.intuit.ru/studies/courses...?page=2‎

Уж сколько раз твердили миру: не сравнивайте вещественные числа на равентство. // www.forum.mista.ru/topic.php?id=620586

Не сравнивайте вещественные числа оператором = (равно). Это не проблема Delphi, а свойство их представления. // http://rfpro.ru/?step=search&mode=an...=5&from=110280

[Iska]

Это в этой программе может сравнение и работать. Но можно нарваться на ситуацию, когда она не сработает. »

Ага. Есть сдвиги. Уже «работает, но можно нарваться», вместо «никогда». Тогда приведите пример про «нарваться», когда «1/3» не будет равна «1/3».

Ваше рассуждение индуктивное. Вы пытаетесь ОДНИМ примером доказать правильность перевода вывода на весь класс предметов, и в данном случае это ошибочно. »

Это утверждение коллеги Tau_0:

ибо никогда в лоб на плавающей точке равенства не будет...

ошибочно, а вслед за ним и Ваше. Я его опровергаю «ОДНИМ» простым незатейливым примером.

Проблему неполной индукции еще никто не отменял. Это у вас сейчас работает, но в целом оно неправильно даже несмотря на то, что временно работает или работает в каких отдельных ситуациях. Ваш пример работает, потому что это временное исключение.»

Ну, ну. Повторяю уже в третьем сообщении: приведите исключение, когда «1/3» не будет равна «1/3».

Я сталкивался с ситуациями, когда 0 не был равен 0 в простых программах из-за того, что нет бесконечности. »

Эко Вас понесло. Оставим пока в покое два представления машинного нуля и т.п.

Компьютер всегда работает с приближением, поэтому разрабатываются численные методы дифференцирования, интегрирования, решения уравнений и т.д. »

Напротив.

читать дальше »

Компьютер всегда работает точно. И потому может терять представление порядка в ту или иную сторону вследствие ограниченности его (порядка) представления. И вот потому-то, что он работает точно, и разрабатываются различные методы округления для компенсации ошибок вычислений при (повторяю в третий раз) переполнении и исчезновении порядка. Но это не имеет ни малейшего отношения к тому, что два числа будут равны или не равны между собой, независимо от того, был ли потерян порядок их представления или нет, ибо порядок будет потерян равнозначно у обоих сравниваемых чисел.

читать дальше »

Компьютеры являются дискретными устройствами, поэтому вам даже в информации о процессоре Intel i7 пишут, что видеокадаптер встроенный в процессор является дискретным. В комьютере реализуются дискретные функции, потому что нельзя реализовать непрерывные. Нельзя реальный физический мир повторить в комьютере. Есть специальный курс дискретной математики в профессиональных ВУЗах для программистов и инженеров. Реализуя компьютерный алгоритм в программе, вы всегда переводите с непрерывного класса функций на дискретный. Бесконечности вещественных чисел в компьютере нет. Поэтому на плавающей точке в лоб равенства может не быть. В электронике на физическом уровне инженерами реализована ТОЧНОСТЬ ДО определенного ЭПСИЛОН, а не бесконечность. Я имею в виду инженеров компаний типа Intel, AMD и т.д., которые занимаются созданием чипов. 1/3 переводится к конечному представлению в компьютерах. »

А ведь предупреждали: не сравнивайте вещественные числа между собой. Нет же, пока САМ не обожжется - должен попробовать. // http://forum.pascalnet.ru/lofiversio...hp/t24610.html ВОТ ПРИМЕР КАК ОБЖИГАЮТСЯ select * from table_name where val=1.7 Значение 1.5 остается как было, значение 1.7 меняется на 1.70000004768372. // http://www.sql.ru/forum/958491/strannyy-kosyak-s-float ГДЕ ТА БЕСКОНЕЧНОСТЬ, КОТОРУЮ ВЫ ТУТ МНЕ ПЫТАЕТЕСЬ ДОКАЗАТЬ? А число 1.7 в двоичной системе имеет бесконечный хвост, который сохранить полностью не представляется возможным. // http://www.sql.ru/forum/958491/strannyy-kosyak-s-float Это, кстати, касается и случая, когда Вы сравниваете вещественные числа, не учитывая точность представления чисел. Посмотрев в отладчике, что числа, вроде как одинаковые, но сравнение срабатывает так, как будто они разные, Вы не задумались бы, что именно в сравнении содержится ошибка. // http://popoff.donetsk.ua/text/work/prg/debug.html У вещественных чисел есть погрешность. Сравнивайте не "равно", а больше/меньше, с учетом этой погрешности. // http://linuxforum.ru/viewtopic.php?id=4076 Не сравнивайте на равенство вещественные числа. // http://www.intuit.ru/studies/courses...?page=2‎ Уж сколько раз твердили миру: не сравнивайте вещественные числа на равентство. // www.forum.mista.ru/topic.php?id=620586 Не сравнивайте вещественные числа оператором = (равно). Это не проблема Delphi, а свойство их представления. // http://rfpro.ru/?step=search&mode=an...=5&from=110280 »

Зачем Вы мне это доказываете? Я об этом давно уже написал в этой теме, поднимите глаза долу на пост #5. Но всё это никак не отменяет того факта, что утверждение

ибо никогда в лоб на плавающей точке равенства не будет...

ложно. Можно утверждать лишь о том, что «В результате потери или исчезновения порядка при вычислениях результаты сравнения а) могут б) в некоторых случаях оказаться некорректными», а вовсе не тот тезис, из-за которого разгорелся весь сыр-бор. И плавающая точка тут совершенно не при чём. Ровно та же логика будет, к примеру, на целых числах и целочисленных вычислениях.

[mrcnn]

ЭВМ оперирует структурами конечного типа. 1/3 не является в компьютере бесконечным. Выше приведен пример с числом 1.7, которое было преобразовано в 1.70000004768372 В 1/3 тоже добавляется в конец "мусор".. Вы проверяете на платформе i386 а на других платформах, например встроенных систем, мобильных устройств и т.п. ваш пример может не сработать. ВАША ПРОГРАММА БЫЛА ПРОВЕРЕНА ЛИШЬ НА ВАШЕМ КОМПЬЮТЕРЕ, но не проверялась на других платформах. Докажите сперва, что ваша программа работает вообще ? Если она на вашем компьютере работает, это не значит, что она правильная. С чего вы решили, что у вас правильный код? Может быть, его и не всякий компилятор скомпилирует? 1/3 вообще в языке C нет, и об этом написано у K&R, что нельзя в программе на языке С писать 1/3, это ошибка. Вы впариваете тут бред и чушь, и еще и спорите, понимая, что не правы.. Ваша программа на языке С ошибочная вообще. Помимо i386 есть еще и платформы ARM, Itanium, а помимо процессоров Intel и AMD есть еще много разных процессоров. Докажите сперва, что ваша программа, которая является как пример, является верной. где ваша выборка и результаты тестирования программы на парке, скажем из тысячи машине? и вообще вы кто такой по жизни, если спорите о простых вещах? Вы не программист вообще, а хз кто.

страница 184 Математический энциклопедический словарь
ДИСКРЕТНАЯ МАТЕМАТИКА - область математики, занимающаяся изучением свойств дискретных структур, к-рые возникают как внутри математики, так и в ее приложениях. К числу таких структур могут быть отнесены, напр. конечные группы, конечные графы, а также не-рые математич. модели преобразователей информации, конечные автоматы, машины Тьюринга и т.п. Это примеры структур финитного (конечного) характера.

страница 281 Математический энциклопедический словарь
КОНЕЧНЫЙ АВТОМАТ - матемтическая модель устройства с конечной памятью, преобразующего дискретную информацию.

страница 360
МАШИНА - абстрактное устройство, осуществляющее переработку информации. <...> Возникновение их связано с анализом понятия алгоритма, начавшегося в сер. 30-ч гг. 20 в., с развитием ЭВМ <...> Наибольшее распространение получили М., перерабатывающие дискретную информацию, типичными представителями к-рых являются конечный автомат и Тьюринга машина.

страница 597
ТЬЮРИНГА МАШИНА - название, закрепившееся за абстрактными вычислительными машинами некоторого точно охарактеризованного типа.

[AMDBulldozer]

mrcnn, обсуждали уже. Я привел шесть разных примеров, где равенство возможно и даже необходимо. Но потом удалил сообщения, чтобы не разводить флейм. Повторю еще раз: полностью согласен с уважаемым Iska. Перестаньте мыслить категориями 20-тилетнй давности. Воспринимайте "a" и "b" из задачи не как числа, а как объекты, между которыми определено отношение эквивалентности.
А уж что именно это за объекты - неважно. Я приводил пример и с вещественными числами для которых оператор == был переопределен и с матрицами и с вещественными для которых требовалось именно побитовое совпадение и даже с виртуальными машиными в которых такие числа как 1/3 или корень из двух представлены без какой-либо потери точности...
Сущность этих объектов не имеет никакого значения для контекста задачи.
Конечно, если Вы хотите сказать, что никакие объекты не могут быть эквивалентными.... Тогда Вам на философский форум.

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

[pva]

winston07,
В примере №2 у тебя из условия идут 3 стрелочки. Должно быть 2 ("да" и "нет").
Не все пути программы приводят к концу (на выводе заканчиваются стрелки).

В принципе примеры №1 и №3 могут пройти по прямой, без ветвлений (т..е. рисовать одним блоком). Но можно предусмотреть деление на ноль. Тогда появятся варианты.

Код:

                      (Начало)
                          |
                     / Дано:x,a,b /
                          |
          нет----------< x!=0? >----да
          |                          |
          |                  [ Часть1=a+(b/x) ]
          |                          |
/ Часть1 нельзя вычислить /          |
          |                          |
          |              нет-----< 0<=x? >---------да
          |              |                          |
          |   / Часть2 нельзя вычислить /    [ Часть2=sqrt(a+sqrt(x)) ]
          |              |                          |
          |              |               [ y=(a+lg|b-x|)^2/(Часть1*Часть2) ]
          |              |                          |
          |              |                   / Результат: y /
          |              |                          |
           -----------------------------------------
                          |
                       (Конец)

Забыл проверить в схеме (Часть1*Часть2)!=0. Обратите внимание, что есть 2 условия, разделённые блоком прямого прохода, причём результат вычисления в блоке может не использоваться (когда второй раз пойдём по ветке "нет". Можно оптимизировать условие в < 0<x? >


Добавлю к общему флуду:
Блок-схема предназначения для того, чтобы объяснить ход/особенности алгоритма (не вдаваясь в подробности реализации). Например, я лично рисовал блок-схемы узлов, которые программировал, чтобы объяснить их работу заказчику (при этом обучать его программированию не входило в планы). Блок-схемы надо уметь читать и писать. Для этого нужно решать "тупые" задачки в большом количестве. Ровно как обучение письму начинается с рисований "никому не нужных" закорючек.

Кстати, я заметил что компиляторы используют представление кода (3-adress-code) очень похожее на блок-схемы.

[mrcnn]

Машинный нуль (англ. Machine epsilon) — числовое значение, меньше которого невозможно задавать точность для любого алгоритма, возвращающего вещественные числа. Абсолютное значение "машинного нуля" зависит от разрядности сетки применяемой ЭВМ, от принятой в конкретном трансляторе точности представления вещественных чисел и от значений, используемых для оценки точности. [1] В языке Си существуют предельные константы FLT_EPSILON и DBL_EPSILON называемые "машинными нулями" относительно вещественного значения 1.0. FLT_EPSILON - максимальное значение типа float и имеет значение 1E-5, DBL_EPSILON - максимальное значение типа double и имеет значение 1E-16. Сумма каждого из этих значений со значением 1.0 не отличается от -1.0. Проблема машинного нуля в том, что два числа считаются одинаковыми, если они отличаются на величину, меньшую по модулю, чем машинный ноль.[источник не указан 1101 день] При представлении чисел со знаком в обратных двоичных кодах существуют проблема[уточнить] наличия двух обратных кодов числа 0: «положительный нуль» и «отрицательный нуль». http://ru.wikipedia.org/wiki/%D0%9C%...BE%D0%BB%D1%8C

Константы определены в заголовочном файле float.h

Код:

#define FLT_EPSILON     1.192092896e-07F        /* smallest such that наименьшее, такое что 1.0+FLT_EPSILON != 1.0 */
#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that наименьшее, такое что 1.0+DBL_EPSILON != 1.0 */

[Iska]

ЭВМ оперирует структурами конечного типа. »

Подтверждаю.

1/3 не является в компьютере бесконечным. »

Согласен.

Выше приведен пример с числом 1.7, которое было преобразовано в 1.70000004768372 В 1/3 тоже добавляется в конец "мусор".. »

Не добавляется. Говоря Вашими словами, происходит отсечение «невмещающихся» цифр мантиссы.

Вы проверяете на платформе i386 а на других платформах, например встроенных систем, мобильных устройств и т.п. ваш пример может не сработать. ВАША ПРОГРАММА БЫЛА ПРОВЕРЕНА ЛИШЬ НА ВАШЕМ КОМПЬЮТЕРЕ, но не проверялась на других платформах. Докажите сперва, что ваша программа работает вообще ? Если она на вашем компьютере работает, это не значит, что она правильная. С чего вы решили, что у вас правильный код? Может быть, его и не всякий компилятор скомпилирует? »

1. Видите ли, язык C, коль уж о нём заговорили, создавался именно как переносимый язык, зависящий от платформы только библиотеками (другое дело, что на практике предпочли принести переносимость в жертву производительности).
2. «Докажите сперва, что ваша программа работает вообще ?» — если Вам недостаточно исходного кода, могу выложить бинарный файл, но, боюсь, Вас и это не убедит, что «программа работает».
3. Поищите у «не всякого компилятора» параметр, включающий поддержку стандарта ANSI.

Ваша программа на языке С ошибочная вообще. »

Чем именно «ошибочная вообще»?

1/3 вообще в языке C нет, и об этом написано у K&R, что нельзя в программе на языке С писать 1/3, это ошибка. »

На какой странице [Iska задумчиво мусолит второе издание K&R]?

Помимо i386 есть еще и платформы ARM, Itanium, а помимо процессоров Intel и AMD есть еще много разных процессоров. Докажите сперва, что ваша программа, которая является как пример, является верной. где ваша выборка и результаты тестирования программы на парке, скажем из тысячи машине? »

У Вас хромает логика: не требуется доказывать корректность работы приведённого приложения для всех мыслимых платформ. Для подтверждения факта ложности категоричного императива:

ибо никогда в лоб на плавающей точке равенства не будет...

достаточно найти одно опровержение. Я этот факт продемонстрировал.

Вы впариваете тут бред и чушь, и еще и спорите, понимая, что не правы.. »

Я знаю, что я прав. А Вам не хватает корректных аргументов, посему Вы судорожно хватаетесь то за одно, то за другое, то вовсе:

читать дальше »

и вообще вы кто такой по жизни, если спорите о простых вещах?»

Зовут меня У, сам я вроде как отшельник… Человек я. Обычный человек.

Вы не программист вообще, а хз кто. »

Я и не утверждал нигде здесь, что я программист. Я уже лет двадцать как не программист.

Машинный нуль … Константы определены в заголовочном файле float.h »

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

ибо никогда в лоб на плавающей точке равенства не будет...

[mrcnn]

У Вас хромает логика: не требуется доказывать корректность работы приведённого приложения для всех мыслимых платформ.

Хромает логика у вас, так как при полной индукции доказывается корректность для любого возможного случая. Но так как это является невозможным (нельзя физически проверить), для упрощения считают верным, если оно является корректным до некоторого заданного n. Но на самом деле оно является неверным. Нельзя считать что-то верным пока не произведена полная индукция.
В итоге пользователи начинают обращаться в тех поддержку из-за того, что у них программа не работает. Потому что программист не предусмотрел некоторые ситуации. Поэтому, для ПО постоянно выпускают обновления, заделывающие ошибки программистов.

Не добавляется. Говоря Вашими словами, происходит отсечение «невмещающихся» цифр мантиссы.

Иногда на калькуляторе (Citizen) при вычислениях 1.0 превращается в 0.99999(9), что является ошибочным, так как равенство на 1.0 точное, а не приближенное. У компьютера та же самая проблема. При точном равенстве компьютер оперирует приближенным представлениям в рамках эпсилон. В той теме на которую была дана ссылка задано точное равенство, а компьютер потерял точность, в итоге возникла ошибка, так как потерялся результат выборки из базы данных. Запрос на языке SQL был задан в следующем виде select * from table_name where val=1.7 а компьютер к точном 1.7. добавил "мусор" и начал оперировать не точным 1.7 а 1.70000004768372. Никакой мантиссы не было. Причем это все эмпирически, а не на словах. Возникла ошибка.

достаточно найти одно опровержение. Я этот факт продемонстрировал. »

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

[mrcnn]

Iska
В начале речь шла не о равенстве 1/3 и 1/3 а о сравнении a и b, а вы начали исходить из сравнения a и b при их равенстве сведя в итоге и a и b к 1/3. Конкретно, смотрите изображение IMG_20131130_121057.jpg топик стартера о блок схеме. Вы перевели рассуждение к ситуации, когда a и b аксиоматически являются одинаковы (и равными 1/3), что является неверным для IMG_20131130_121057.jpg Таким образом, вы подменили начальный тезис, сузив его. Причем Tau_0 прокомментировал изображение IMG_20131130_121057.jpg , а не вашу программу.

Последовательность событий:
1. 02:10, Вчера IMG_20131130_121057.jpg топик стартера о блок схеме к программе.
X = {
a / b + 1, если a > b,
a + 25, если a = b,
(a*b - 2) / a, если a < b;
}
2. 05:02, Вчера Tau_0 написал в "См. второй пример на ветвление, если a = b Он совсем не так прост..., ибо никогда в лоб на плавающей точке равенства не будет..."

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

В этой теме: http://www.rsdn.ru/forum/cpp.applied/1187492.flat в сообщении от 24.05.05 14:53 написано, что сравнивать вещественные числа нужно в некой окрестности и приведен код

Код:

bool isEq(double a, double b)
{
   return abs(a-b)<epsilon.
}

[Iska]

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

Я опроверг конкретное утверждение. И попытки приплести сюда индуктивный вывод для его подтверждения уже ни к чему. Вы придумали себе нечто, и теперь с этим, Вами же придуманным, спорите.

Было сказано: «Для любых X верно Y». Я привёл опровержение, что Y верно отнюдь не для любых X. Но Вы с какого-то перепугу придумали себе и упорно требуете от меня доказательства «Для каждого X не верно Y».

Иногда на калькуляторе (Citizen) при вычислениях 1.0 превращается в 0.99999(9), что является ошибочным, »

читать дальше »

О! Давайте ещё на счётах проверим, там уж точно приложение на C откажется работать. Вот будет доказательство так доказательство!

Первое ключевое слово — «при вычислениях». Второе — «при различных». Но, повторяю вновь: это никак не подтверждает, либо опровергает сделанного утверждения:

ибо никогда в лоб на плавающей точке равенства не будет...

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

Вы опять забыли сказать чем именно она «является неправильной, ошибочной».

читать дальше »

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

Вы мне выше рекомендовали кое-что почитать. Я Вам тоже порекомендую.

читать дальше »

Есть такая книга: Программирование арифметических операций в микропроцессорах. Злобин В.К., Григорьев В.Л. Ещё советского издания. И вот там на трёхстах страницах подробным образом изложены теория и, главное, практика программирования арифметических операций в двух наиболее известных микропроцессорах. С картинками, с блок-схемами. И рабочими листингами на ассемблере.

Сколько раз мне Вам повторять две вещи:
1. Я это знаю.
2. Это никак не доказывает истинности или ложности утверждения.