LVV>>Нет. Даже (со)процессор делает округление.
KP>А вычислить дополнительную поправку к с, чтобы, например (b + c + correction) == a?
Надо хорошо разбираться в теории погрешностей — есть такая теория...

Здравствуйте, Vzhyk2, Вы писали:

M>>Нет. double умеет не больше 15ти значащих десятичных знаков хранить, а у тебя — 17. А тут a и b сразу уже хранят не те значения, которые ты им задаёшь. По идее, компилятор должен предупредить об этом, но не факт
V>А еще в советской школе рассказывали про погрешности округления и что с ними происходит при вычислениях.

И? Можешь развить свою мысль?

Здравствуйте, Vzhyk2, Вы писали:

KP>>Можно ли без округления вычислить c, чтобы гарантировать (b+c) == a? Спасибо.
V>Можно, но для начала тебе нужно открыть любой учебник по вычислениям на компьютерах и внимательно прочитать и всё поймешь, что можно, что нельзя. Раньше в школе основы оного преподавали. "Значашие цифры", "системы счисления", "периодические и не периодические дроби", "целые, рациональные и иррациональные числа" — это, например, из тех основ.

Не совсем понятно, как ты увязал школьную программу и вычисления на компьютерах. Перечисленное — это основы алгебры, скорее. А системы счисления — если и давали, то в конечных классах

Здравствуйте, Vzhyk2, Вы писали:

V>Здравствуйте, Kazmerchuk Pavel, Вы писали:

KP>>Можно ли без округления вычислить c, чтобы гарантировать (b+c) == a? Спасибо.
V>Можно...
Покажи или топик не засоряй

Здравствуйте, Marty, Вы писали:

R>>long double

M>Который в MSVC, внезапно, тот же double

И который в ICC (который, в свою очередь, совместим с MSVC) таки long double (80 bit).

Здравствуйте, flаt, Вы писали:

R>>>long double

M>>Который в MSVC, внезапно, тот же double

F>И который в ICC (который, в свою очередь, совместим с MSVC) таки long double (80 bit).

Как совместим? По ключам командной строки?

В итоге-то что? В MSVC long double как-то не превращается в double, или что?

Я еще с борманом наелся этого в прошлом веке, теперь только double и float.

Здравствуйте, Marty, Вы писали:

M>Как совместим? По ключам командной строки?

По сорцам (всякие прагмы и прочее) и по ключам командной строки (он как clang, имеет режимы совместимости с GCC и MSVC).

M>В итоге-то что? В MSVC long double как-то не превращается в double, или что?
В ICC — нет, не превращается (но, кажется, там есть ключик и long double может быть как 64, так и 80 бит).

Здравствуйте, flаt, Вы писали:

M>>Как совместим? По ключам командной строки?

F>По сорцам (всякие прагмы и прочее) и по ключам командной строки (он как clang, имеет режимы совместимости с GCC и MSVC).

Отлично. Мы разобрались, что ICC совместим с MSVC в командной строке и по сорцам.

Как это отменяет то, что MSVC не умеет в double больше 64х бит?

Здравствуйте, Marty, Вы писали:


M>Отлично. Мы разобрались, что ICC совместим с MSVC в командной строке и по сорцам.

M>Как это отменяет то, что MSVC не умеет в double больше 64х бит?

А речь не об отмене. Человек предложил long double, в ответ было сказано, что под MSVC long double не работает (хотя топикстартер платформу не указывал). Но если под MSVC не работает, то есть ещё ICC, который совместим с MSVC.

Здравствуйте, flаt, Вы писали:

M>>Отлично. Мы разобрались, что ICC совместим с MSVC в командной строке и по сорцам.

M>>Как это отменяет то, что MSVC не умеет в double больше 64х бит?

F>А речь не об отмене. Человек предложил long double, в ответ было сказано, что под MSVC long double не работает (хотя топикстартер платформу не указывал). Но если под MSVC не работает, то есть ещё ICC, который совместим с MSVC.

Ну и после ICC с другим компилятором у него все поломается. Годный рецепт.

Здравствуйте, Kazmerchuk Pavel, Вы писали:

V>>Можно...
KP>Покажи или топик не засоряй
0001+0001 == 0010.

Здравствуйте, Marty, Вы писали:


M>Ну и после ICC с другим компилятором у него все поломается. Годный рецепт.

Это конечно занятно, про long double, MSVC, ICC и всех, всех, всех... только что это в принципе меняет? Да ничего, ну получится больше значащих цифр, но на них все равно проявятся особенности представления чисел с плавающей точкой.
Ответ другой и очень простой, его Homunculus уже написал.

Здравствуйте, Marty, Вы писали:

M>У меня — можно — https://github.com/al-martyn1/marty_decimal
У тебя на порядок, два, три медленней, оно того не стоит.

И как у тебя сработает?
int main()
{
MartyNumber a = 1.0;
MartyNumber b = a/3;

assert((b+b+b) == a);
}

Здравствуйте, Kazmerchuk Pavel, Вы писали:

KP>А вычислить дополнительную поправку к с, чтобы, например (b + c + correction) == a?
А цель какая?

Здравствуйте, pagid, Вы писали:

P>Здравствуйте, Kazmerchuk Pavel, Вы писали:

KP>>А вычислить дополнительную поправку к с, чтобы, например (b + c + correction) == a?
P>А цель какая?

Решение уже привели. Задача шагать по сеточной функции, точно попадая в узлы. Узлы подвижны.

Здравствуйте, pagid, Вы писали:

M>>У меня — можно — https://github.com/al-martyn1/marty_decimal
P>У тебя на порядок, два, три медленней, оно того не стоит.


Ну, смотря где и как. Домашнюю бухгалтерию вести очень удобно

Медленнее, да — сравнение в 5, сложение и вычитание — в 20, умножение — в 50, про деление вообще не говорю — раз медленнее, чем встроенный double. Но по сравнению с тем же cpp_dec_float из буста — уже не на порядки, а в разы отстаю. И там опять же используется двоичная арифметика.

Но таки очень удобно оказалось. Где скорость не критична, а важна точность — уже перехожу на свой велосипед


P>И как у тебя сработает?
P>int main()
P>{
P> MartyNumber a = 1.0;
P> MartyNumber b = a/3;

P> assert((b+b+b) == a);
P>}

Понятно, что не сработает. У меня для оператора деления используется static поле, содержащее точность. По умолчанию — 18 знаков после точки (при этом не важно, сколько до). Отдельно есть метод div, там точность можно явно задать.

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

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

А по поводу правильного сравнения машинных floating point чисел — ну, на диссер конечно тема недотягивает, но там одним эпсилон не отделаешься

Здравствуйте, pagid, Вы писали:

P>Ответ другой и очень простой, его Homunculus уже написал.

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

Здравствуйте, Vzhyk2, Вы писали:

V>>>Можно...
KP>>Покажи или топик не засоряй
V>0001+0001 == 0010.

А теперь тоже самое для крайне правой десятичной цифры. например, 0.1 + 0.2 = ?

Здравствуйте, Kazmerchuk Pavel, Вы писали:

KP>Решение уже привели. Задача шагать по сеточной функции, точно попадая в узлы. Узлы подвижны.
Решение с эпсилон проще и эффективнее. Еще можно целочисленную сетку взять. Тоже проще будет.

Здравствуйте, Marty, Вы писали:

M>Слишком простой, тема сравнения плавающих чисел поширше будет. В универе по этим делам вообще два семестра выч мата было, как раз на тему, как считать на double и прочем плавающем
В вопросе ТС нет на два семестра.