다음과 같은 다항식을 생각하자.
이때 a=77617.0, b=33096.0일때 f(a,b)를 구해보자
이걸 IBM 370이라는 틀딱컴에서 돌리면, single precision에서는 1.172603, double 에서는 1.1726039400531,
extended에서는 1.172603940053178이라는 값이 나온다고한다.
근데 정답은 -0.827396059946821부호조차 다른 값이라고 한다.
얘의 더 웃긴점은 뭐냐면, 운영체제와 cpu에 따라서 변한다는 것이다.
구글에서 찾다 발견한건데 Handbook of Floating-Point Arithmetic(Jean-Michel Muller, et al)에 의하면
펜티엄 4, 리눅스, GCC 컴파일러 C로 돌리면 single은 2.0317 e+29, double은 5.960604 e+20, extended에서는 -9.38724 e-323이 나온다고 한다.
내 컴에서 돌릴때도(C++, g++) single은 -3.53675933115810770 e+029, double은 -1.18059162071741130 e+21, extended는 3.17286586244148490 e-317이 나온다.
그러니까 유리수를 쓸 수 있다면 유리수를 쓰자
왜 저런결과가 나오는 데스웅?
ㄴ 제목에 써있잖아 round off error때문이라고. 특히 절대값 크기의 차이가 많이 나는 부동소수점 숫자를 더하거나 빼면 에러가 엄청나게 커진다는거 수치해석시간에 다 가르쳐줘.
현대수학의 모순인가
round off error도 있는데, 컴파일러나 아키텍쳐에 따라서 연산을 하는 방식이나 순서가 달라지기 때문에도 아닌가 싶음.
이게 념글이다~
아 원래는 정답을 위에놨다가 아래로 옮긴거라서... 수정해야지
힐베르트 행렬 디터미넌트도 cpu 컴파일러에 따라서 플로트로 계산할라 하면 계산값 폭주하잖어
꽤 재밌는 이야기네 ㅋㅋㅋ 신기하당 - dc App
a=77617.0, b=33096.0 도 유리수 아님???
ㄴ 그걸 float로 계산하면 exact한 연산이 아님. floating arithmetic 찾아보고 유리수는 분모 분자 저장해놓는 그런식임