오라클 11g는 -> Oracle 데이터 클라이언트 -> 프로 * C 프로그램 배정도 표현

Question

11 세대 R2 오라클 DB 인스턴스의 NUMBER (12,3) 필드 번호를 기억 271.448

그것으로 커서로부터 페치 은 Pro * C (버전 11.1.0.6)의 32 비트 변수입니다. .c 파일을 컴파일하는 데 Visual Studio 2010을 사용하는 사전 처리 된 C 프로그램이 사용되었습니다.

는 인쇄하기는 271.448가 fprintf를하고 "%의 3.14f"의 형식 지정자와의 이중 변수로 인출 된 후 즉시 (표준 출력) 제공합니다 271.44800000000004

다음 작업을 수행 할 경우 반면 :

1. to_char (cast (271.448 as binary_double), '999.99999999999999')를 선택하십시오. from dual;

2. 마찬가지로 1.하지만, 숫자 리터럴이 아닌 해당 행/필드를 참조하십시오.

3. to_char (to_binary_double (271.448), '999.99999999999999')를 선택하십시오. from dual;

4. 마찬가지로 3. 그러나 숫자 행 리터 이 아닌 해당 행/필드를 참조하십시오.

   은 % 3.14f로 표준 출력이 아닌 프로 * C를 테스트 C 프로그램 및 인쇄에 두 번 직접

5. 지정 271.448

"지정

6. 사용 http://www.binaryconvert.com/convert_double.html 전환을 할 수.

6> 5) 2.71447999999999979081621859223E2)

-

나는 1 271.44799999999998) 도착

오라클 DB와 Pro * C/C의 불일치는 아니지만 다소 부정확 한 표현을 기대했습니다.

Google과 몇 시간 만에 좀 더 지식이 많았지 만 내 특정 문제는 현명하지 않았습니다. 누군가 내가 무엇을 놓치고 있는지 또는 무슨 일이 일어 났는지에 대해 가르 칠 수 있습니까?

Answer 1

질문에 대한 답이 확실하지 않습니다. "대답이 모두 271.4480000000000000000000000 인 이유는 무엇입니까?"

하지만 당신은 몇 가지 표현으로 다루고 :

• Oracle's internal NUMBER과 strange storage details (N.B.를: 일반적으로 OCI가 뒷받침 프로 *의 C)
• C language double :
• 64-bit IEEE754 double

그리고 여러 변환 및/또는 포맷 단계 :

• TO_CHAR (캐스트 (271.448로 BINARY_DOUBLE), '999.99999999999999 ')
• to_char (to_binary_double (271.448),'999.99999999999999 ')
• double d = 271.448; printf ("% 3.14f \ n", d);
• 은 "바이너리 변환"사이트

내가 여기 중요한 차이가 있으므로 핵심 질문 일반적인 C 표현 대 오라클의 내부 번호 형식입니다 생각 (또는 어쩌면 당신의 형식 문자열로 "%의 3.27f"를 사용) 실제로 "이 모든 형식이 271 + 56/125를 정확히 저장하지 않는 이유는 무엇입니까?"

Why aren't rational numbers implemented and stored as fractions with zero loss of information?

또는

Floating point numbers are a leaky abstraction