모르기 쉬운 현대수학 44화 : 0!, 0^0, "아무것도 하지 않기" 하기

43화 : 적분의 종류

a^b는 a라는 숫자 b개를 전부 곱한 값을 가리킴. 오직 b가 자연수일 때만.

이 성질은 지수법칙을 통해 쉽게 b가 정수인 경우에 대해서 확장할 수 있고, 그 경우에 a^0 = 1이라는 결론을 쉽게 얻을 수 있음. a가 0이 아니라면

왜냐하면 0은 곱셈에 섞이면 항상 0을 만들기 때문임. 따라서 0^n은 항상 0이고, 이 규칙을 보면 0^0, 즉 0을 0번 곱한 수는 0이 되어야 하는가 싶기도 함.

이는 0!에서도 비슷한 얘기를 할 수 있음. n!은 1부터 n까지 총 n개의 수를 곱한 것인데, 그렇다면 0!, 즉 0개의 수를 곱한 것의 값은 무엇이 되어야 하는가? 1에서 0까지 1 * 0이 되어서 0이 되는 것이 맞는가? 하는 질문을 충분히 던질 수 있음.

결론부터 말하자면, 0!은 1이고, 0^0은 관점에 따라서,

집합론적인 관점의 경우, 정의에 의해서 1

이산적, 즉 대수적, 조합론적 관점의 경우 암묵적으로 1

해석학적 관점의 경우, 정의되지 않음

이라는 식으로 다르다고 하는 것이 정확할 것임. 즉 본질적으로 값을 준다면, 1을 주는 것이 적절함. 그리고 0!의 경우에는 해석학적 관점에서도 1 외의 값을 줄 방법이 따로 없기 때문에 모든 분야에서 1로 생각하고, 0^0은 여기서 차이가 발생하기 때문에 원칙적으로는 정의되지 않은 것으로 취급함.

우선 가장 명확한 집합론 적인 관점을 설명하자면, 모든 개수를 나타내는 수는 집합론 적으로는 집합이기도 함. 이 때, a^b이 원소 b개인 집합에서 a개인 집합으로 가는 함수의 개수 라는 것에 착안해서 일반적으로 임의의 집합 A, B에 대해서

A^B : 집합 B에서 A로 가는 함수들의 집합

으로 정의를 내림. 이는 철저하게 집합적인 관점이고 이를 수의 관점으로 다시 옮기면

수 A^B : 집합 B에서 A로 가는 함수들의 집합의 원소의 개수에 대응하는 수

가 됨. 그리고 여기서 0이란 수는 공집합으로 정의가 되므로, 0^0은 결국 공집합에서 공집합으로 가는 함수들의 집합의 원소의 개수가 되는데, 함수의 엄밀한 정의와, 공허한 진실 개념 (이것으로도 한 회차 잡아먹을 수 있는 내용일 것 같긴 한데)을 살펴보면, 공집합 자체가 공집합에서 공집합으로 가는 함수이기도 함.

따라서 공집합에서 공집합으로 가는 함수는 공집합 한 개 가 존재하고, 따라서 이 정의에 따라서 0^0은 1임. 특히 여기서, 현대 집합론에서 채택하는 자연수의 정의를 따르면 공집합 한 개를 원소로 가지는 집합은 집합론적으로 1이기도 함. 즉 0^0은 단순히 수의 관점에서만 1이 아니라 집합의 관점에서도 완전히 1이기 때문이 이견의 여지가 없을 정도로 1이라고 할 수 있음.

해석학적으로는 우선,

이 성립하기는 함. 그래프를 보면

이렇게 생겼음. 문제는, 극한이 0^0꼴이 항상 1이라는 값을 가지지는 않는다는 점임. 구체적으로 예시를 들자면

라는 식을 생각하면 0이 될 수도 있고, 임의의 1보다 작은 양수 c에 대해서

꼴을 생각하고, 1보다 큰 수에 대해서는

이 성립하며, 추가로

도 성립하게 할 수 있음. 즉, 밑이 0으로 가고, 지수가 0으로 간다고 해서 극한값을 예측할 수 있는 방법은 전혀 없고, 이런 이유로 해석학적으로는 0^0의 값을 정의되지 않은 부정형이라고 생각하는 경우가 대부분임.

마지막으로 대수적인 관점에 대해서는 이런 저런 설명이 있지만, 여기서는 "아무것도 하지 않는 행위를 하는 것"에 답이 있음.

가장 먼저, a^b을 a를 b개 곱하는 것이라는 설명은 사실 대수적으로 바람직하지는 않음. 왜냐하면 곱셈은 2항 연산이지만 이 설명은 마치 곱셈이 다항연산인 것처럼 설명하고 있기 때문임. 특히 곱셈이 2항 연산이라는 것이 굉장히 큰 발목을 잡는데, 왜냐하면,

a^b을 a를 b개 곱하는 것이라는 설명은 사실 a^1 = a 라는 것을 제대로 설명할 수 없기 때문

임. 이를 위해서는 결합법칙과 항등원을 이용해서 2항 연산에 더 적합한 설명으로 변환할 필요가 있는데, 즉

a^b은 1에 a를 b번 곱한 결과이다

라고 해석하는 것임. 우선 결합법칙과 항등원의 성질에 의해서 a * a * ... * a = 1 * ( a * a * a* ... a) = (...((1 * a) * a) * ... * a) 가 되기 때문에 이 두 설명은 완전히 동등한 설명임.

그리고 이 설명은 오직 2항 연산적으로 정의되어 있으며, a^1에 대한 문제도 전혀 존재하지 않고, 그리고 굉장히 자연스럽게 a^0이

1에 a를 0번 곱한 수

가 되기 때문에, 즉 1에 아무것도 곱하지 않은 수가 되고, 결국 이것은 1이 될 것임.

더 나아가서, "아무것도 곱하지 않은 수"는 항상 1이 되는 것이 적절하다고 할 수 있고, 이 관점에서 0! 또한 0개의 수를 곱한 것이므로 1이 되는 것이 역시 자연스러워짐. 프로그래밍 언어로 표현하자면 이 두 관점은

이렇게 정의된 함수와

이렇게 정의된 함수의 차이라고도 볼 수 있음. 함수형 프로그래밍 언어적으로는 foldl과 foldl1의 차이이기도 함. 위의 함수가 언어에 따라서는 더 최적화 될 수는 있겠지만 빈 리스트가 입력으로 들어오면 에러가 나고, 아래 함수는 어떤 유한 리스트에 대해서도 곱셈과 1이 정의만 되어 있다면 작동하게 정의되어 있음.

거기다가 위의 함수는 리스트의 첫 번째 원소를 특별 취급하는 반면, 아래 함수는 딱히 특별 취급하지 않고 동등하게 취급함으로서 좀 더 대칭적으로 깔끔하게 기술되어 있음. 물론 아래쪽 함수에 빈 리스트를 넣으면 1을 배출하는 것 또한 굉장히 자명함.

사실 이 설명은 a * 0 = 0이라는 것을 설명하는 것에도 완전히 동등하게 적용될 수 있음. 0에다가 a를 b번 더하는 것을 상상하면 됨. 이를 일반적으로 확장하면, 항등원과 결합법칙이 존재하는 2항 연산의 경우, 아무것도 적용하지 않는 경우는 항등원이 된다고 결론지을 수 있음.

그러나 사람들은 보통 a * 0 = 0이라는 것은 쉽게 받아들이지만, 0^0 = 1이라는 것은 이를 쉽사리 동일하게 이해하지 못함.

이는 a^b이 교환법칙이나 결합법칙이 성립하지 않는 연산이기 때문임. a^b에서 a와 b는 전혀 동등하지 않고, 명확한 우열 관계가 존재함. 즉,

1^0 = 2^0 = 3^0 = ... = 1

0^1 = 0^2 = 0^3 = ... = 0

이 충돌했을 때, 밑과 지수 사이에는 명확한 우열 관계가 있고, 따라서 둘 중 하나를 수학적으로 적합하게 채택할 수 있게 되는 것.

어떤 의미로는 a * 0 = 0이라는 논리로 접근하면 0^0 = 1이 되고, 0 * a = 0이라는 논리로 접근하면 0^0 = 0이 되는데, 이는 모순처럼 보일 수는 있고, 실제로 해석학적으로는 모순을 만들어낼 수 있지만, 대수적으로는 a * 0 = 0 * a = 0에서는 나오지 않은 비대칭성에서 비롯된 우열 관계로 인해 하나의 관점을 우선적으로 채택할 수 있다는 것임.

실제로도 여러모로 이론을 전개하는 데는 0^0 = 1로 취급하는 것이 편한데,

라는 테일러 전개를 생각할 때도, 이를 간편하게 나타내면

만약 여기서 x에 a를 대입하면 f(a) = f(a) * 0^0 / 0! 이 되고, 여기서 0!과 0^0이 모두 1이라면 깔끔하게 항등식이 되는 것을 관찰할 수 있음. 마찬가지로 이항전개를 생각해도

에서 b에 0을 대입하면 a^n = n! / (n! 0!) * a^n * 0^0 이 되고 이 또한 0!, 0^0이 1일 때 항등식이 됨. 이런 식으로 여러가지 이유가 있어서 0^0은 1이 되는 것이 일반적으로는 적합하다고 할 수 있음. 사실 해석학적으로도 극한에 있어서 "0^0 꼴" 이라는 것은 어디까지나 그 형태를 나타내는 이름일 뿐 값을 대표할 수는 없고, 숫자로 계산할 경우에는 1로 하는 것이 맞다는 관점도 존재할 정도.

1. 0^0은 꼭 값을 계산해야 한다면 1이라고 하는 것이 적절함.

2. 물론 극한 관점에서 0^0꼴이 나오면 포기하고 잘 계산해야함

3. pow(a,b)를 정의할 때 예외처리를 하고 싶으면 우선 b=0인 경우를 우선적으로 처리하고, 그 뒤에 a = 0, 1인 경우를 처리하는 것이 바람직하며, 딱히 예외 처리를 하지 않더라도 pow(a,0) = 1이 되는 식으로 코딩을 하는 것이 바람직함

4. 실제로 이런 수학적 관점이 실제로 코딩 스타일에 영향을 주기도 함

5. 긴 연휴가 끝났다