저는 IEEE-754위원회의 일원이었습니다. 일을 좀 더 명확하게하려고 노력할 것입니다.
먼저 부동 소수점 숫자는 실수가 아니며 부동 소수점 산술은 실제 산술의 공리를 만족시키지 않습니다. Trichotomy는 수레뿐만 아니라 가장 중요하지 않은 실제 산술의 유일한 속성은 아닙니다. 예를 들면 다음과 같습니다.
- 덧셈은 연관성이 없습니다.
- 분배 법은 유지하지 않습니다.
- 역수가없는 부동 소수점 숫자가 있습니다.
계속할 수있었습니다. 우리가 알고 사랑하는 실제 산술의 모든 속성 을 만족시키는 고정 크기 산술 유형을 지정할 수 없습니다 . 754위원회는 그들 중 일부를 구부리거나 파기로 결정해야합니다. 이것은 매우 간단한 원칙에 의해 안내됩니다.
- 우리가 할 수있을 때, 우리는 실제 산술 행동과 일치합니다.
- 우리가 할 수 없을 때, 우리는 위반을 예측 가능하고 진단하기 쉬운 것으로 만들려고 노력합니다.
"정답이 거짓이라는 의미는 아닙니다"라는 귀하의 의견과 관련하여 이것은 잘못된 것입니다. 술어 가보다 작은 (y < x)
지 묻습니다 . 경우 NaN이입니다, 다음은 하지 부동 소수점 값보다 적은 답은 반드시 거짓 있도록.y
x
y
x
나는 trichotomy가 부동 소수점 값을 유지하지 않는다고 언급했습니다. 그러나 유사한 속성이 있습니다. 754-2008 표준의 조항 5.11, 단락 2 :
4 가지 상호 배타적 인 관계가 가능합니다. 마지막 경우는 하나 이상의 피연산자가 NaN 일 때 발생합니다. 모든 NaN은 비 순차적 자체를 포함하여 모든 것을 비 교해야한다.
NaN을 처리하기 위해 추가 코드를 작성하는 한 NaN이 제대로 빠져 나가는 방식으로 코드를 구성하는 것이 가능하지만 항상 쉬운 것은 아니지만 항상 그런 것은 아닙니다. 그렇지 않은 경우 일부 추가 코드가 필요할 수 있지만 대수 종결이 부동 소수점 산술에 가져온 편의성을 지불하는 것은 작은 가격입니다.
부록 : 많은 의견 제시 자들은 NaN! = NaN을 채택하는 것이 친숙한 공리를 보존하지 않는 근거로 평등과 삼분 절의 반사성을 유지하는 것이 더 유용 할 것이라고 주장했다. 나는이 견해에 대해 동정심을 가지고 있다고 고백했다. 그래서 나는이 답변을 다시 방문하고 좀 더 많은 맥락을 제공 할 것이라고 생각했다.
Kahan과의 대화에서 NaN! = NaN은 두 가지 실용적인 고려 사항에서 비롯된 것입니다.
즉 x == y
동등해야한다 x - y == 0
이것은 X의 위반, 그러나, 참고 -이 표준이 개발되었을 때 가장 중요했다 비해 더 많은 공간 효율의 하드웨어 구현한다 가능하면 (실제 연산의 정리되고 넘어 = y = 무한대이므로, 그 자체로는 큰 이유가 아닙니다 (x - y == 0) or (x and y are both NaN)
.
더 중요한 isnan( )
것은 NaN이 8087 산술로 공식화 될 당시에는 술어 가 없었다는 것입니다. isnan( )
수년이 걸릴 수 있는 프로그래밍 언어에 의존하지 않는 NaN 값을 감지하는 편리하고 효율적인 수단을 프로그래머에게 제공 해야했습니다. 이 주제에 대한 Kahan의 글을 인용하겠습니다.
NaN을 제거 할 수있는 방법이 없었다면 CRAY에서 무기한만큼 쓸모가 없을 것입니다. 하나가 발생하자마자 무기한 결론을 내릴 때까지 무한정 계속되는 것이 아니라 계산을 중단하는 것이 가장 좋습니다. 그렇기 때문에 NaN에 대한 일부 작업은 NaN 이외의 결과를 제공해야합니다. 어떤 작업? … 예외는 C 술어 "x == x"및 "x! = x"이며, 이는 모든 무한 또는 유한 수 x에 대해 각각 1과 0이지만 x가 숫자가 아님 (NaN)이면 역전됩니다. 이것들은 NaN에 대한 단어와 술어 IsNaN (x)가없는 언어의 NaN과 숫자 사이의 단순한 예외없는 구별을 제공합니다.
이것은 "부울이 아님"과 같은 것을 반환하지 않는 논리이기도합니다. 어쩌면이 실용주의가 잘못 배치되어 표준이 필요 isnan( )
했을 것입니다. 그러나 NaN은 몇 년 동안 효율적이고 편리하게 사용하기가 거의 불가능 해졌지만 세계는 프로그래밍 언어 채택을 기다렸습니다. 나는 합리적인 트레이드 오프가 될 것이라고 확신하지 않습니다.
둔감하게 : NaN == NaN의 결과는 지금 바뀌지 않을 것입니다. 인터넷에서 불평하는 것보다 함께 사는 법을 배우는 것이 좋습니다. 컨테이너에 적합한 주문 관계 도 존재 해야한다고 주장하려면 선호하는 프로그래밍 언어 totalOrder
가 IEEE-754 (2008)에 표준화 된 술어를 구현하도록 권장합니다 . 그것이 현재 상황에 동기를 부여한 Kahan의 우려의 타당성을 아직 밝히지 않았다는 사실.
while (fabs(x - oldX) > threshold)
수렴이 발생하거나 NaN이 계산에 들어가면 루프를 종료하는 것과 같이 됩니다. NaN의 탐지 및 적절한 해결책은 루프 외부에서 발생합니다.