[AMDBulldozer]

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

Iska: он просто хотел, чтобы Вы поставили точку после единицы (или после тройки). Иначе производится целочисленное деление и уже его результат преобразуется в вещественное число. При этом сам он опубликовал какой-то глупый код с непонятной функцией "abs", которая при наличии #include <stdlib.h> и отсутствии #include <cmath> будет целочисленной и стало быть все числа различающиеся не более, чем на 1 окажутся равны. А при наличии <cmath> код просто не скомпиллируется, поскольку не указана область видимости. Должно быть либо std::abs, либо явная отсылка к пространству имен в "using std::abs". Но такие "мелочи" его явно не волнуют.

Можете задать ему простой вопрос: написать программу вычисяющую машинный эпсилон (котогрый он вслед за Вики безграмотно называет "машинным нулем"). Интересно, как он это сделает без операции сравнения...

[Iska]

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 , а не вашу программу. »

Я ничего не «подменял» и не «сужал». Коллега Tau_0 высказал утверждение. Вы этот категоричный императив поддержали. Я его опроверг.

Понятно, что человек хочет спорить просто ради самого факта спора. Безграмотные статьи из Вики и столь же безграмотные примеры какого-то Васи Пупкина для него пример абсолютной истины. На этом заканчиваю, не буду кормить тролля. »

Да, Вы правы. Поступлю так же.

[Tau_0]

Я его опроверг. »

Прежде,чем опровергать малость прочитайте... --- На эти грабли обычно студенты наступают или специалисты по логическому программированию, но не вычислители...

На уровне ликбеза и для уточнения посмотрите, что я имел в виду… Просто навскидку нашёл. Более каверзные случаи мне пока придумывать лениво, да и не по теме оно будет…

сравнение на равенство вещественных чисел, в последний раз, надеюсь
О сравнении действительных чисел.

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

Неправильнгое сравнение двух чисел типа double

[Iska]

Tau_0, Вас тоже «кормить» не буду. Я полагал, мы с Вами разобрались. Оказывается нет. Повторять в пятый раз одно и то же я не стану. Всё, что изложено коллеге mrcnn, считайте теперь адресованным и Вам. На сим закончим.

[AMDBulldozer]

Ну не бывает одинаковых вещественных чисел »

Код:

#include <stdio.h>
main()
{
  float x=1.,e=1.;
  while( !( x+e == x ) ) e /= 2;
  printf("%g\n",e);
}

Конструкция !( a == b ) использована вместо a != b исключительно с целью подчеркнуть равенство чисел как условие выхода из цикла.

[Drongo]

To All:

1. Помогите автору темы решить его вопросы и спорьте до посинения.
2. Если будет замечен переход на личности или троллинг опонента, такой пост будет выпиливаться.

[mrcnn]

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

Она является ошибочной, так как в языке С нет дробей вида p/q. Не производит оперирование конструкциями вида 1/3. В K&R есть пример насчет перевода градусов по Фаренгейту в градусы по Цельсию, и там объясняется насчет деления чисел.
Помимо этого она является ошибочной, так как вы сравниваете вещественные числа в машинном представлении напрямую. Нельзя сравнивать вещественные a и b оператором ==.

[winston07]

вот как получилось

[Tau_0]

с целью подчеркнуть равенство чисел как условие выхода из цикла. »

Вот вы какие настырные… --- а читать и думать ленитесь…
Вот мой последний аргумент в виде цитаты…

Побереги печень Не все так смертельно... temp и sum - задаются ручками (типа sum=20.0 и temp=20.0), или это результат вычисления чего-либо? Судя по названию переменной temp - видимо результат вычисления... Классика - с переменными действительного типа надо крайне осторожно проводить такие сравнения при вычислениях. Результат 1/3 и 3/9 может быть разным где-нибудь "в последнем знаке" и его не увидеть никогда... Может привести к определенной точности (ну например до 6 знака) а потом уж и сравнивать...

Тема: Неправильнгое сравнение двух чисел типа double (Прочитано 12390 раз)

Это я о том, что результат IF может быть как false, так и true --- сиё зависит от реализации… Только и всего.

Маленький вопрс на подумать --- чему равно с точностью до восьми знаков
1.0/3.0 + 1.0/3.0 + 1.0/3.0 =…???...
Пусть для простоты арифметика десятичная (на самом деле в машине она двоичная и от этого дополнительные фокусы,…)

PS Видимо оставанемся при своих и не будем напрягать недотыкомки…

[AMDBulldozer]

winston07, как-то не совсем понятно. По первой Вашей блок-схеме:
Какой смысл производить проверку значения X дважды? В первый раз Вы прерываете выполнение по равенству нулю, во -второй - по меньше или равно.
Очевидно, что если второе сравнение ложно, то и первое тоже ложно. Тем более, что второе сравнение Вы производите для определения существования вещественного корня, а в таких целях оно должно быть не "меньше или рано нулю", а просто "меньше".
С другой стороны, Вы не проверяете X на равенство B. Но если они равны, то разность |B-X| (у Вас ошибочно написано |B+X|) станет равна 0, а логарифм нуля это минус бесконечность.
На Вашем месте я сначала бы произвел обе эти проверки, а потом вычислил бы Y одной формулой. В противном случае, у Вас Y оказывается равен не всей дроби, а только её числителю.

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

Я могу пояснить, почему в Ваших рассуждениях имеется дефект. Только что автор темы опубликовал блок-схему, в которой не проверил X на равенство B перед вычислением выражения lg|b-x|. По Вашей логике, он поступил правильно - если считать, что обе величины являются действительными числами, как Вы предположили, то они, по Вашему утверждению, не могут быть равны (Вы это не смогли доказать, но упорно этой точки зрения ипридерживаетесь) и стало быть логарифм будет существовать в области действительных чисел. То есть и проверять незачем. Точка.
Послушавшийся Вас человек напишет заведомо неверную блок-схему. Во-первых, потому, что числа могут быть равны и это было наглядно продемонстрировано в программе вычисления "машиннного эпсилон". А во-вторых, если они даже окажутся НЕ равны, они могут быть настолько близки, что логарифм выйдет за пределы представления числа. Тогда надо проверять не только равенство чисел, но еще и переполнение/потерю значимости в процессе вычисления. И не только логарифма, но после любого действия. И т.д. и т.п.
В результате получается, что сделав акцент на одном аспекте, Вы полностью упускаете из вида сопутствующие. Вы скажете, что добавите все необходимые проверки в момент написания программы и что это не имеет отношения к собственно алгоритму? И будете правы. Именно об этом и речь - человек долже сначала сформулировать для себя основную идею, а детали реализации, к которым относятся и ошибки округления, оставить на потом.
Поймите, что говоря об ошибках округления Вы ни для кого Америку не открыли. Может быть это мы откроем её для Вас, когда расскажем, что с этими ошибками научились бороться несколько десятилетий назад.