16-miniron-v

[miniron-v]

🔗 문제 링크

https://www.acmicpc.net/problem/1081
1081번: 합
분류: 수학

✔️ 소요된 시간

2시간 (이거 풀고 성불함)

✨ 수도 코드

우선 삽질의 근원이었던 것부터 제거하고 가겠다.
이 문제는 다른 연속합 문제 처럼, 1부터 U까지의 정답 - 1부터 (L - 1)까지의 정답으로 답을 구할 수 있다.

14와 53을 넣는다면, function(1, 53) - function(1, 13)로 답을 구해낼 수 있다. 우린 이 방식을 사용할 것이다.

---

자릿수의 특징은 다음과 같다.

k의 자릿수 합이 a일 때, k + 1의 자릿수 합은 a + 1이다. (예외 있음)

예외 있음이 뭔 소린가 싶겠지만, 쉽게 말하면 18의 자릿수 합이 9고, 19의 자릿수 합은 9 + 1 = 10이라는 것.

이를 통해 우린 다음과 같이 추론할 수 있다.

그렇다면 0부터 N까지의 합은 어떻게 구할 수 있을까?
(왜 1이 아니라 0이라면, 둘의 결과는 같기 때문이다.)

단순하게 1부터 N까지의 합이 됨을 알 수 있다. 등차수열의 합 공식(또는 가우스 합)을 쓰면 이렇게 나타낼 수 있다.

자주 썼고, 또 익숙한 그 공식. 그러니 이를 먼저 구현해보자.

long long gaussSum(int k) {

}

(PR 작성 후 발견했는데, 위처럼 int k를 매개변수로 줬더니 장렬한 에러를 일으키며 틀렸습니다를 띄웠다. 이유는 마지막에)

k의 최댓값이 2,000,000,000(20억)이므로, 곱셈 후 나눗셈을 하는 건 위험 부담이 크다. 곱셈 후 변수의 범위를 벗어나버리면, 이상한 값이 들어가게 되니까.

그러니 k가 짝수인지, 홀수인지에 따라 경우를 나눠, 다음과 같이 채워줬다.

long long gaussSum(long long k) {
	if (k % 2 == 0) {
		return (k / 2) * (k + 1);
	}

	return ((k + 1) / 2) * k;
}

자, 그럼 가우스 합은 구했겠다. 하지만 이게 정답이면 골드 문제일 리 없다.
앞서 우린 이렇게 자릿수 합의 합을 구하는데 예외가 있다고 했다. 그게 바로 이 부분이다.

올림이 발생하면, 자릿수의 합이 9만큼 줄어드는 부분.
왜 8이 아니고 9냐면, 우리가 앞서 세웠던 논리에 따르면 20자리엔 11이 들어갔어야 했기 때문이다.

이처럼, 우리가 구한 방식에서 -9되는 값들이 있다.

0부터 표를 그렸을 때, 우리가 구한 값과 실제 값의 차이를 나타내면 위와 같다.

16은 올림이 한 번 발생했고(9 -> 10, 9를 한 번 빼야 하고)
27은 올림이 두 번 발생했다(9 -> 10, 19 -> 20, 9를 두 번 빼야 한다)

이는 또한 100의 자리에서도 같은 현상이 일어나는데, 99 -> 100으로 넘어갈 때 또다시 9가 줄어든다.
얼핏 보면 9가 두 번 줄어든 거 아냐?라고 생각할 수 있다. 하지만, 10의 자리에서 줄어든 부분은 앞서 위 방식으로 이미 계산했기에, 100의 자리가 일으키는 뺄셈은 한 번이 맞다.

이를 추상화해 수도 코드를 작성해보면

1부터 N까지의 자릿수 합의 합을 구하는 과정
1. answer = gaussSum(N)
2. 10의 자리에 대해 answer -= 9 * count;
3. 100의 자리에 대해 answer -= 9 * count;
...
자릿수를 모두 비교하면 종료

가 된다.

여기까지 코드로 작성해보자.

long long gaussSum(long long k) {
	if (k % 2 == 0) {
		return (k / 2) * (k + 1);
	}

	return ((k + 1) / 2) * k;
}

long long getSumOfPlace(long long n) {
	if (n < 1) {
		return 0;
	}

	long long answer = gaussSum(n);

	long long d = 10;
	while ((n / d) > 0) {
		long long q = n / d;
		long long r = n % d;

		answer -= 9 * (gaussSum(q - 1) * d + q * (r + 1));

		d *= 10;
	}

	return answer;
}

d의 자리를 비교할 때도 가우스 합이 쓰였다. 왜냐하면
10의 자리가 1이면 1 * 9만큼 빼고
10의 자리가 2면 2 * 9만큼 빼고
10의 자리가 3이면 3 * 9만큼 빼고
...
10의 자리가 33이면 33 * 9만큼 빼고
(엄밀히 말하면 10의 자리로 표현할 순 없지만, 337은 실제로 10의 자리 올림이 33번 발생하니, 그런 뜻으로 봐주시면 감사하겠다.)
이처럼 빼는 9의 개수도 가우스 합의 형태를 띄기 때문이다.

그리고 N = 53이라면, 50, 51, 52, 53 4개의 수만 5개의 9를 빼야 하기에, 이는 따로 q * (r + 1)로 계산해주었다.

이제 마지막으로, getSumOfPlace(U)에서 getSumOfPlace(L - 1)을 빼주면 끝이다.

이때 getSumOfPlace(-1)이 들어갔을 때 에러를 일으켰기에, getSumOfPlace의 내부에 예외 처리가 들어갔다.

📚 전체 코드

#include <iostream>

long long gaussSum(long long k) {
	if (k % 2 == 0) {
		return (k / 2) * (k + 1);
	}

	return ((k + 1) / 2) * k;
}

long long getSumOfPlace(long long n) {
	if (n < 1) {
		return 0;
	}

	long long answer = gaussSum(n);

	long long d = 10;
	while ((n / d) > 0) {
		long long q = n / d;
		long long r = n % d;

		answer -= 9 * (gaussSum(q - 1) * d + q * (r + 1));

		d *= 10;
	}

	return answer;
}

int main() {
	long long l, u;
	std::cin >> l >> u;

	std::cout << getSumOfPlace(u) - getSumOfPlace(l - 1);
}

📚 새롭게 알게된 내용

가장 많은 시간을 잡아먹은 함수는 바로 이 부분이다.

long long gaussSum(int k) {
	if (k % 2 == 0) {
		return (k / 2) * (k + 1);
	}

	return ((k + 1) / 2) * k;
}

코드 상, 로직 상 아무 문제도 없는데, 도대체 왜? 라고 생각했고, 그렇기에 이게 문제일 줄 상상도 못 했었다.

결론부터 말하자면, 매개 변수가 int 형인 게 만악의 근원이었다.

C/C++에서 연산은, 정확하겐 아래의 플로우를 따른다.

int k = 2,000,000,000;
long long sum = k / 2 * k;

이와 같은 식이 있다면
1. k를 2로 나눈다. (int형 임시 변수에 1,000,000,000이 입력된다.)
2. 여기에 k를 곱한다. (int형 임시 변수에 2,000,000,000,000,000,000이 입력된다 -> overflow!)
2-1. 이때 int형 범위를 초과했으므로, 여기엔 (거의) 쓰레기 값이 들어간다.
4. 이를 sum에 저장한다.
5. int형에서 long long형으로, 암시적 형 변환이 일어난다.

위 과정에 따라, 반환값과 변수가 전부 long long이라 해도, k가 int형이기 때문에 실제로는 int 범위 내에서의 연산만 이뤄졌던 것이다.

이걸 어디서 발견했냐면... 0 2000000000의 답으로 난 18,446,744,073,709,551,615가 나왔는데, 질문 게시판에선 82,000,000,002가 답이라고 한 부분이었다.

여기서 디버깅으로 역추적하며 들어가보니, 가우스 함수가 문제임을 알 수 있었다.

---

불행인지 다행인지 참고한 블로그가 없다. (그 대신 몇 배로 고통받았다.)

큰 수를 다룰 땐... 변수의 자료형, 반환값, 매개 변수까지 꼼꼼히 확인할 것
그리고 수학 문제는 피할 것

문빈갓의 꿀팁

1. 백준의 long은 long long과 같다.
2. #define int int64_t를 선언해두면 고통받지 않는다.

다음에 꼭 써먹어보겠습니다... 문멘

https://www.acmicpc.net/source/2655996
이 코드도 분석해보고 싶었는데, 너무 싱싱미역 상태라 글자가 눈에 안 들어와요... 해석해주실 분 계신가요?

전체 사고 과정: https://autumncat.tistory.com/62

[2secondag]

n의 자릿수를 하나씩 처리하기 위한 while문인가요....?!

[miniron-v]

네 맞습니다. 일반적으론 /= 연산만 실행하며 n > 0을 조건으로 걸지만, 이번엔 원본 값을 보존해야 했기에 자릿수 변수 d를 기준으로 했습니다.

[bomik0221]

싱싱미역..맛있겠다
민철님이 고생하신 만큼 저한테도 이해하기 쉽지 않은 코드였던 것 같습니다. 고생하셨어요!
가우스까지 보고 오~ 나도 이해하기 쉬운데~ 했다가 밑의 표부터는 저도 싱싱미역 상태가 되었습니다...

[miniron-v]

싱싱미역..맛있겠다 민철님이 고생하신 만큼 저한테도 이해하기 쉽지 않은 코드였던 것 같습니다. 고생하셨어요! 가우스까지 보고 오~ 나도 이해하기 쉬운데~ 했다가 밑의 표부터는 저도 싱싱미역 상태가 되었습니다...

우린 모두 흐물거리는 미역일 뿐...