Спасибо!

У меня, выходит, что 0.5 * 0.5 == 0.25, и потому, в C++ с полной поддержкой IEEE754, мы можем писать так: float a = 0.5; if(a*a == 0.25).....

кто что скажет против такого сравнения и САМОЕ ГЛАВНОЕ - ПОЧЕМУ?

Тебе непонятно почему подобное слегка недопустимо?

Потому что типа представление не вмещается в 4 байта

да и в 8 байт

там всегда будет погрешность

Ты.. эмм....понимаешь что в моем примере

в МОЕМ примере, все вмещается и речь не о общем случае?

лучше if(a*a == .5*.5)

А чем лучше

Я его вопрос вообще не понял

лучше if(a*a == .5*.5)

Лично я проблем не вижу. Должно быть 100% true

.1 + .2 = 0.3000000000000000004 знакомо?

.1 + .2 = 0.3000000000000000004 знакомо?

другой случай

Прочитайте внимательно что пишет человек

.1 + .2 = 0.3000000000000000004 знакомо?

Здесь, да. Знакомо. Крис верно пишет, что это другой случай. Ну хоть кто то, умеет читать.

У меня, выходит, что 0.5 * 0.5 == 0.25, и потому, в C++ с полной поддержкой IEEE754, мы можем писать так: float a = 0.5; if(a*a == 0.25).....

чисто в этом примере да

2^-1 ^2 = 2^-2

чисто в этом примере да

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

2^-1 ^2 = 2^-2

Так вот, мой вопрос предпосылка к тому, что. Утверждение: Если есть два числа полностью представимые в бинарном виде double(т. е имеют конечную запись в битах, без округлений) , то результат умножения этих чисел - число, которое бы мы получили если бы напрямую посчитали результат ручками и записали в бинарном виде. Т.е bin(a) * bin(b) ==bin( a * b), где а и b полностью представимы double ом. Имеют конечную запись, в десятичной системе и при переводе в двоичную, имеют также конечную бинарную форму, которая полностью укладывается в битовую запись дабла.

Кто крякнет это утверждение? Пишите внимательно прочитав вопрос. Не пишите про случаи, когда число не представимо в двоичной записи. Типа 0.1 + 0.2 e. t. c

Например: 10. + 40. == 50. - true всегда, исходя из моего утверждения.

Исходники кодеров из гоогл - согласны со мной, как и комментарии в оных. Но может у них, какие то свои допущения.

Так вот, мой вопрос предпосылка к тому, что. Утверждение: Если есть два числа полностью представимые в бинарном виде double(т. е имеют конечную запись в битах, без округлений) , то результат умножения этих чисел - число, которое бы мы получили если бы напрямую посчитали результат ручками и записали в бинарном виде. Т.е bin(a) * bin(b) ==bin( a * b), где а и b полностью представимы double ом. Имеют конечную запись, в десятичной системе и при переводе в двоичную, имеют также конечную бинарную форму, которая полностью укладывается в битовую запись дабла.

Количество значащих знаков в a * b может быть рано количеству знаков в a + количество знаков в b. Как ты a * b собираешься записать в double без округления?

Может потому что бинарный вариант не способен полностью представить именно десятичные числа?

Вот утверждение и верно

Просто попытка типа запутать, не более

Количество значащих знаков в a * b может быть рано количеству знаков в a + количество знаков в b. Как ты a * b собираешься записать в double без округления?

случаи округления, сюда тоже входят, но именно округления результата. А не начальных чисел. Начальные числа точно представимы в сетке. Используется один тип округления.

случаи округления, сюда тоже входят, но именно округления результата. А не начальных чисел. Начальные числа точно представимы в сетке. Используется один тип округления.

Если результат округлится процессором в правильную сторону и сохранится точность то в теории да. На практике есть разные режимы округления и точности вычислений.

У меня, выходит, что 0.5 * 0.5 == 0.25, и потому, в C++ с полной поддержкой IEEE754, мы можем писать так: float a = 0.5; if(a*a == 0.25).....

if (fabs(a*a - 0.25) < DBL_EPSILON)

if (fabs(a*a - 0.25) < DBL_EPSILON)

в том примере можно точно на рвенство сравнивать

Если результат округлится процессором в правильную сторону и сохранится точность то в теории да. На практике есть разные режимы округления и точности вычислений.

ну при полной поддержке ieee754 вроде теория должна быть явью.

а я все равно перестрахуюсь!

Если полной поддержки нету, то и бояться о погрешностях из за криворукости не нужно.

в том примере можно точно на рвенство сравнивать

Еще раз повторю - есть разные режимы. Есть rounding mode (http://www.gnu.org/software/libc/manual/html_node/Rounding.html), есть разные режимы точности (например /fp:fast у MSVC, https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/).

я знаю про это. Так а чем мешает это, если при округлении числа слева используется тот же мод, что и для справа?

т.е round(c) == round(a * b), где a * b == c, в условиях ручной записи.

а, б, ц полностью представимы в сетке дабла.

:?!

я знаю про это. Так а чем мешает это, если при округлении числа слева используется тот же мод, что и для справа?

Что за ручная запись? Лучше может про проблему расскажешь которую ты пытаешься решить, а то уже третий день вокруг да около.

мне кажеца шо гцц умеет оптимизировать

А мне кажется, что будут проблемы

Что за ручная запись? Лучше может про проблему расскажешь которую ты пытаешься решить, а то уже третий день вокруг да около.

Ну вот, с чего вдруг вокруг да около. Я уже сюда кидал код. Google в своих исходниках пишет: что переводя строку "123.23", мы имеем право сделать вот так: 12323./100. и это будет OK - т. е получим представление строки выше, числом дабл что в ней описано И про вокург да около, следовательно, ты говоришь бездумно.Так как проблему я уже описывал? И не третий день, а второй. Но это уже чем то женским пахнет.

Ну вот, с чего вдруг вокруг да около. Я уже сюда кидал код. Google в своих исходниках пишет: что переводя строку "123.23", мы имеем право сделать вот так: 12323./100. и это будет OK - т. е получим представление строки выше, числом дабл что в ней описано И про вокург да около, следовательно, ты говоришь бездумно.Так как проблему я уже описывал? И не третий день, а второй. Но это уже чем то женским пахнет.

Тебя беспокоит проблема не наврал ли гугл? Если 123.23 точно представимо в double то имеем право. Если нет то нет. Теперь сердце спокойно?

123.23 точно там не представимо, поэтому беспокоит не наврал ли.

Вообще это все слабо к C++ относится.

так, давай без каких либо предвзятостей. Я тебя не пытался задеть, если что.

Вот сорцы гугла, читай комментарий.

Но именно так, они у себя в v8 переводят строки в числа. А по их спеке - это все, ieee754 true.

так, давай без каких либо предвзятостей. Я тебя не пытался задеть, если что.

Если в v8 они контролируют режим fpu, то представление должно совпадать. Если не контролируют - то не обязательно.

#include <iostream> #include <float.h> int main() { unsigned int current; _controlfp_s(&current, _MCW_RC, _RC_DOWN); double a = 12323.; double b = 100; if (a / b == 123.23) std::cout << "Hello World!\n"; }

тут ничего не выведется

А что значит контролировать режим fpu?

А что значит контролировать режим fpu?

Выставлять флаги fpu при заходе в v8, у fpu несколько флагов и режим округления один из них - https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/controlfp-s?view=vs-2017.

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

Кто крякнет это утверждение? Пишите внимательно прочитав вопрос. Не пишите про случаи, когда число не представимо в двоичной записи. Типа 0.1 + 0.2 e. t. c

Самое главное: а нафига? Нафига тебе именно строгое равенство? В мире чисел с плавающей точкой такое просто не нужно

Ну вот, с чего вдруг вокруг да около. Я уже сюда кидал код. Google в своих исходниках пишет: что переводя строку "123.23", мы имеем право сделать вот так: 12323./100. и это будет OK - т. е получим представление строки выше, числом дабл что в ней описано И про вокург да около, следовательно, ты говоришь бездумно.Так как проблему я уже описывал? И не третий день, а второй. Но это уже чем то женским пахнет.

Так что ж тебе надо-то?

А что тебя выручать, NP-complete task....

Прошу обосновать данное утверждение.

Блин ну ты вытащил...

Самое главное: а нафига? Нафига тебе именно строгое равенство? В мире чисел с плавающей точкой такое просто не нужно

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

Самое главное: а нафига? Нафига тебе именно строгое равенство? В мире чисел с плавающей точкой такое просто не нужно

Например, вот это. У меня сейчас перед глазами программа, которая вполне себе выигрывает от наличия строго равенства между флоатами. Т.е. такое БЫВАЕТ НУЖНО.

Прошу обосновать данное утверждение.

Так это надо обосновать что есть алгоритм быстрее чем NP, а не наоборот.

Например, вот это. У меня сейчас перед глазами программа, которая вполне себе выигрывает от наличия строго равенства между флоатами. Т.е. такое БЫВАЕТ НУЖНО.

Извините, а в чем выигрыш-то?

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

Ты может обосновать и доказать алгоритм, будешь ещё умнее.

Например, вот это. У меня сейчас перед глазами программа, которая вполне себе выигрывает от наличия строго равенства между флоатами. Т.е. такое БЫВАЕТ НУЖНО.

Ну расскажи нам...

Например, вот это. У меня сейчас перед глазами программа, которая вполне себе выигрывает от наличия строго равенства между флоатами. Т.е. такое БЫВАЕТ НУЖНО.

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

Извините, а в чем выигрыш-то?

Вот у меня есть шейдер анимации. Ему на вход даются коэффициенты блендинга, от нуля до единицы. Флоаты, очевидно. Ну и по ним он сэмплит геометрию, очень хитрым образом. В процессе профайлинга выяснилось, что в 50% случаев один из коэффициентов строго равен единице. Достигается это тем, что blendFactor = std::min(blendFactor + frameIncrement, 1.0f). В шейдер добавили строгое сравнение с единицей, которое игнорирует ветку логики. Получили ускорение. По-другому не сделать - uniform bool передать дороже, переключить шейдер дороже и т.д.

Вот у меня есть шейдер анимации. Ему на вход даются коэффициенты блендинга, от нуля до единицы. Флоаты, очевидно. Ну и по ним он сэмплит геометрию, очень хитрым образом. В процессе профайлинга выяснилось, что в 50% случаев один из коэффициентов строго равен единице. Достигается это тем, что blendFactor = std::min(blendFactor + frameIncrement, 1.0f). В шейдер добавили строгое сравнение с единицей, которое игнорирует ветку логики. Получили ускорение. По-другому не сделать - uniform bool передать дороже, переключить шейдер дороже и т.д.

А не секрет, какой прирост дало строгое сравнение? Интересную штуку задвинули...

Порядка 15%.

Немало, хотел бы я понять почему же так :)

Вот у меня есть шейдер анимации. Ему на вход даются коэффициенты блендинга, от нуля до единицы. Флоаты, очевидно. Ну и по ним он сэмплит геометрию, очень хитрым образом. В процессе профайлинга выяснилось, что в 50% случаев один из коэффициентов строго равен единице. Достигается это тем, что blendFactor = std::min(blendFactor + frameIncrement, 1.0f). В шейдер добавили строгое сравнение с единицей, которое игнорирует ветку логики. Получили ускорение. По-другому не сделать - uniform bool передать дороже, переключить шейдер дороже и т.д.

Ну такое объяснение я понимаю. Иван пятый же ничего не объясняет...

Вот у меня есть шейдер анимации. Ему на вход даются коэффициенты блендинга, от нуля до единицы. Флоаты, очевидно. Ну и по ним он сэмплит геометрию, очень хитрым образом. В процессе профайлинга выяснилось, что в 50% случаев один из коэффициентов строго равен единице. Достигается это тем, что blendFactor = std::min(blendFactor + frameIncrement, 1.0f). В шейдер добавили строгое сравнение с единицей, которое игнорирует ветку логики. Получили ускорение. По-другому не сделать - uniform bool передать дороже, переключить шейдер дороже и т.д.

Но тебе же и >= 1 подошло бы, разве нет,?

Ну такое объяснение я понимаю. Иван пятый же ничего не объясняет...

Я, если честно, не читал :) Я увидел безапелляционное заявление, что "В мире чисел с плавающей точкой такое просто не нужно" и стриггерился, прошу прощения :)

Но тебе же и >= 1 подошло бы, разве нет,?

Конкретно в этом случае нет. Там есть НЕКОТОРЫЕ объекты, которые используют тот же шейдер, но им разрешено выходить за 1.

Ну, странно...

Немало, хотел бы я понять почему же так :)

Там половина шейдера не выполняется в этом случае.

Там половина шейдера не выполняется в этом случае.

Не, не. Я про то, что замена проверки равенства с точностью до епсилон на строгое так сильно все изменила

А, нет. Илья правильно сказал, проверка типа abs(1.0 - x) < 0.001 дала бы такой же визуальный результат. Но зачем, если x == 1.0 и читабельнее, и точнее?

А, нет. Илья правильно сказал, проверка типа abs(1.0 - x) < 0.001 дала бы такой же визуальный результат. Но зачем, если x == 1.0 и читабельнее, и точнее?

Ну вы же указали что как раз замена abs(1.0 - x) < 0.001 на x == 1.0 и дала перформанс буст, или я не так понял?