Умный калькулятор

[Geniepro]

Код: [Выделить]

main = do
    putStr "x: "; x<-readLn
    putStr "y: "; y<-readLn
    let xy=x/y
    putStr "z: "; z<-readLn
    putStrLn $ show x  ++ "/" ++ show y ++ " = " ++ show xy
    putStrLn $ show xy ++ "*" ++ show z ++ " = " ++ show (xy * z)
Main> :main
x: 10
y: 3
z: 3
10.0/3.0 = 3.33333333333333
3.33333333333333*3.0 = 10.0

[valexey_u]

Код: [Выделить]

main = do
    putStr "x: "; x<-readLn
    putStr "y: "; y<-readLn
    let xy=x/y
    putStr "z: "; z<-readLn
    putStrLn $ show x  ++ "/" ++ show y ++ " = " ++ show xy
    putStrLn $ show xy ++ "*" ++ show z ++ " = " ++ show (xy * z)
Main> :main
x: 10
y: 3
z: 3
10.0/3.0 = 3.33333333333333
3.33333333333333*3.0 = 10.0

Именно.

[Geniepro]

Код: [Выделить]

import Data.Ratio

r = 1%3 + 4%3 - 5%3
Main> r
0 % 1

Работайте, господа, с рациональными дробями! )))

[valexey_u]

Н да... В Real точность только на иррациональных числах теряется (в калькуляторе аналогично)
Мне почему-то казалось что в бесконечных дробях тоже...

Про "бесконечные" дроби есть пример интересней:

Код: [Выделить]

printf ("%1.70lf\n", 0.3);выдает:

Код: [Выделить]

0.2999999999999999888977697537484345957636833190917968750000000000000000Как думаешь, почему? ;-)

А вот такое:

Код: [Выделить]

printf ("%1.70lf\n", 0.3f);выдает такое:

Код: [Выделить]

0.3000000119209289550781250000000000000000000000000000000000000000000000
Жить страшно, не правда ли?

Что выбираешь, тайд или кипячение? ;-)

[ilovb]

Если бы я еще шарил в кракозябрах этих "printf ("%1.70lf\n", 0.3);" 
Это типа вывод числа 0.3 с большим числом знаков после запятой?

[valexey_u]

Если бы я еще шарил в кракозябрах этих "printf ("%1.70lf\n", 0.3);" 
Это типа вывод числа 0.3 с большим числом знаков после запятой?

Да. Это ("%1.70lf\n") называется - форматный вывод. И это то самое место, которое в Си сделано удобней чем в стандартной плюсовой либе. Да и во многих других языках тоже (если они не копируют это у Сей).

[ilovb]

То что не все числа представимы в формате IEEE754 для меня не новость.
Смущает больше что точность не теряется при вычислении 10/3.

Я предпочитаю ожидать погрешность в этом случае. И считаю что это правильно.

виндозный калькулятор же всегда сохраняет точность на рациональных числах (по крайней мере не замечал обратного)

Соответственно я предположил что он хранит таки рациональные числа.
Но скорее всего ты прав. В нем наверно просто формат IEEE754 128 бит.

[valexey_u]

То что не все числа представимы в формате IEEE754 для меня не новость.
Смущает больше что точность не теряется при вычислении 10/3.

Я предпочитаю ожидать погрешность в этом случае. И считаю что это правильно.

Окэй, не хочешь подумать/повикипедить, скажу ответ: представление чисел у компьютера не десятичное, а таки двоичное. Следовательно конечные десятичные дроби могут быть бесконечными двоичными (замечу, что конечная двоичная дробь это всегда конечная же десятичная). Поэтому 0.3 - это бесконечная периодическая дробь в двоичном представлении.

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

[valexey_u]

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

Да, либо, что вероятно, там просто фиксированная точка. Эксперименты показали, что больше чем 10^10000 и меньше чем 10^-10000 оно не обрабатывает. Так что разумнее всего сделать было именно фиксированную точку.

[ilovb]

Окэй, не хочешь подумать/повикипедить, скажу ответ: представление чисел у компьютера не десятичное, а таки двоичное. Следовательно конечные десятичные дроби могут быть бесконечными двоичными (замечу, что конечная двоичная дробь это всегда конечная же десятичная). Поэтому 0.3 - это бесконечная периодическая дробь в двоичном представлении.

Ну так это и означает что:

... не все числа представимы в формате IEEE754

Т.е. конечную десятичную дробь 0.3 в этом формате представить нельзя

А "точность" того, что выводит мелкомягкий калькулятор скорее всего связана с тем, что на экранчике мало циферек и он просто округляет (форматный вывод, ага). Ну и длинные числа.

Там вообще странно...
Вот результат вычисления в калькуляторе:
sqrt(2) * sqrt(2) - 2 = -1,588200079154339e-19

однако
sqrt(2) * sqrt(2) = 2

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

Ну в 1С длинные числа. И ведут они себя не так.
Собственно они себя предсказуемо ведут в противоположность IEEE754.
Погрешность всегда ровно там, где ее ожидаешь.

[valexey_u]

Ну так это и означает что:

... не все числа представимы в формате IEEE754

Т.е. конечную десятичную дробь 0.3 в этом формате представить нельзя

Можно, при условии что пользователь будет смотреть на нее через узкую амбразуру форматного вывода :-)

Там вообще странно...
Вот результат вычисления в калькуляторе:
sqrt(2) * sqrt(2) - 2 = -1,588200079154339e-19

однако
sqrt(2) * sqrt(2) = 2

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

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

[Geniepro]

... именно реально длинные числа (по крайней мере для целочисленнки там точно они, советую поэкспериментировать с факториалом, оценить время работы на больших числах). ...

Win7 64-bit, calc.exe
1000! = 4,02387260077093773543702433923e+2567

ну и де тут длинные целые? о_О

[Geniepro]

... именно реально длинные числа (по крайней мере для целочисленнки там точно они, советую поэкспериментировать с факториалом, оценить время работы на больших числах). ...

Win7 64-bit, calc.exe
1000! = 4,02387260077093773543702433923e+2567

ну и де тут длинные целые? о_О

Хотя, похоже, там есть длинные числа: 1000! - (1000! - 1) = 1 (делал вычисления через его память по кнопкам M+ M- MR)

[valexey_u]

... именно реально длинные числа (по крайней мере для целочисленнки там точно они, советую поэкспериментировать с факториалом, оценить время работы на больших числах). ...

Win7 64-bit, calc.exe
1000! = 4,02387260077093773543702433923e+2567

ну и де тут длинные целые? о_О

Дык это ж афигенно длинное целое! Или тебя предствление этого числа смучает (форматный вывод то есть)? ;-)

[ilovb]

Это как раз укладывается в 128 бит формат

Число четверной точности

0x 7ffe ffff ffff ffff ffff ffff ffff ffff  ≈  1.189731495357231765085759326628007 × 10^4932 (Максимальное число четверной точности)