문제
https://programmers.co.kr/learn/courses/30/lessons/42891#
평소 식욕이 왕성한 무지는 자신의 재능을 뽐내고 싶어 졌고 고민 끝에 카카오 TV 라이브로 방송을 하기로 마음먹었다.
그냥 먹방을 하면 다른 방송과 차별성이 없기 때문에 무지는 아래와 같이 독특한 방식을 생각해냈다.
회전판에 먹어야 할 N 개의 음식이 있다.
각 음식에는 1부터 N 까지 번호가 붙어있으며, 각 음식을 섭취하는데 일정 시간이 소요된다.
무지는 다음과 같은 방법으로 음식을 섭취한다.
무지는 1번 음식부터 먹기 시작하며, 회전판은 번호가 증가하는 순서대로 음식을 무지 앞으로 가져다 놓는다.
마지막 번호의 음식을 섭취한 후에는 회전판에 의해 다시 1번 음식이 무지 앞으로 온다.
무지는 음식 하나를 1초 동안 섭취한 후 남은 음식은 그대로 두고, 다음 음식을 섭취한다.
다음 음식이란, 아직 남은 음식 중 다음으로 섭취해야 할 가장 가까운 번호의 음식을 말한다.
회전판이 다음 음식을 무지 앞으로 가져오는데 걸리는 시간은 없다고 가정한다.
무지가 먹방을 시작한 지 K 초 후에 네트워크 장애로 인해 방송이 잠시 중단되었다.
무지는 네트워크 정상화 후 다시 방송을 이어갈 때, 몇 번 음식부터 섭취해야 하는지를 알고자 한다.
각 음식을 모두 먹는데 필요한 시간이 담겨있는 배열 food_times, 네트워크 장애가 발생한 시간 K 초가 매개변수로 주어질 때 몇 번 음식부터 다시 섭취하면 되는지 return 하도록 solution 함수를 완성하라.
제한사항
- food_times 는 각 음식을 모두 먹는데 필요한 시간이 음식의 번호 순서대로 들어있는 배열이다.
- k 는 방송이 중단된 시간을 나타낸다.
- 만약 더 섭취해야 할 음식이 없다면 -1을 반환하면 된다.
정확성 테스트 제한 사항
- food_times 의 길이는 1 이상 2,000 이하이다.
- food_times 의 원소는 1 이상 1,000 이하의 자연수이다.
- k는 1 이상 2,000,000 이하의 자연수이다.
효율성 테스트 제한 사항
- food_times 의 길이는 1 이상 200,000 이하이다.
- food_times 의 원소는 1 이상 100,000,000 이하의 자연수이다.
- k는 1 이상 2 x 10^13 이하의 자연수이다.
입출력 예
| food_times | k | result |
|---|---|---|
| [3, 1, 2] | 5 | 1 |
입출력 예 설명
입출력 예 #1
- 0~1초 동안에 1번 음식을 섭취한다. 남은 시간은 [2,1,2] 이다.
- 1~2초 동안 2번 음식을 섭취한다. 남은 시간은 [2,0,2] 이다.
- 2~3초 동안 3번 음식을 섭취한다. 남은 시간은 [2,0,1] 이다.
- 3~4초 동안 1번 음식을 섭취한다. 남은 시간은 [1,0,1] 이다.
- 4~5초 동안 (2번 음식은 다 먹었으므로) 3번 음식을 섭취한다. 남은 시간은 [1,0,0] 이다.
- 5초에서 네트워크 장애가 발생했다. 1번 음식을 섭취해야 할 때 중단되었으므로, 장애 복구 후에 1번 음식부터 다시 먹기 시작하면 된다
풀이 코드
def solution(food_times, k):
from collections import deque
if sum(food_times) <= k:
return -1
food_times = [(i+1, v) for i, v in enumerate(food_times)]
food_times = deque(sorted(food_times, key=lambda x: x[1]))
past_time = 0
while k:
temp_v = food_times[0][1] - past_time
amount = temp_v * len(food_times)
if amount <= k and len(food_times) > 1:
k -= amount
past_time += temp_v
food_times.popleft()
else:
k = k%len(food_times)
break
food_times = sorted(list(food_times), key=lambda x: x[0])
return food_times[k][0]해설
1.
문제를 읽었을 때 제일 먼저 큐를 이용해서 푸는 방법을 떠올렸다.
- 처음 음식의 번호와 그 음식을 섭취하는데 소요되는 시간을 튜플로 만들어 큐에 저장하고
- 네트워크 장애가 발생하기 전 매 초마다 음식을 꺼내서 남은 시간을 차감하고, 아직 남아있다면 다시 큐에 넣는다.
- 네트워크 장애가 끝난 후(for문의 종료)에도 큐에 남아 있는 원소가 있다면 음식을 다 먹지 못한 것이므로 제일 앞의 원소를 뽑아서 인덱스를 반환한다.
코드로 구현한 바는 다음과 같다.
def solution(food_times, k):
from collections import deque
q = deque()
answer = -1
for i, v in enumerate(food_times):
q.append((i+1, v))
for i in range(1, k+1):
if not q:
break
now_i, now_v = q.popleft()
if now_v-1 > 0:
q.append((now_i, now_v-1))
if q:
answer = q.popleft()[0]
return answer인덱스를 수정하면서 런타임 에러를 잡고나니 정확도 100%는 어렵지 않게 달성할 수 있었다.
하지만 이렇게 풀게 되면 k의 값만큼 for 문을 돌게 되므로 k의 값이 최대 2x10^13인 효율성 테스트는 당연히 통과하지 못한다.
2.
효율성 테스트를 통과하기 위해서는 수학적으로 계산할 방법을 찾아야 하는 듯 싶었다.
한동안 생각한 후에 k의 값을 줄이면 되지 않을까 생각했다.
key point:
음식의 수가 n개라고 했을 때, n초 후에는 food_times 리스트에 있는 모든 음식의 섭취 시간이 1씩 줄어들게 되고, 다시 첫번째 음식을 먹을 차례가 된다.
이를 활용하여 다음과 같은 로직을 생각했다.
- 먼저 모든 음식을 섭취하는데 소요하는 시간이 k보다 작거나 같을 경우에는 네트워크 장애 이후 시점에서 더이상 먹을 음식이 없다는 것을 의미하므로 바로 -1을 리턴하고 함수를 끝낸다.
- food_times 리스트를 인덱스를 포함한 튜플의 리스트로 재할당하고, 시간을 기준으로 정렬한다.
- 가장 섭취 소요 시간이 적은 (첫번째 원소의 시간 * 남은 음식의 갯수)을 계산하고, 이 값을 amount라고 한다.
- amount가 k보다 작아지는 시점이 되면, 더 이상 food_lists의 요소를 삭제할 수 없게 된다. 따라서 남은 음식의 소요 시간을 고려하지 않고 바로 k의 값을 간략화 시켜주면 된다. 이를 위해 k를 food_times의 길이로 모듈러 연산을 해주고, 남은 리스트에서 계산된 값의 인덱스를 갖는 음식이 최종적으로 네트워크 장애 이후 먹어야 할 음식이 된다.
코드로 구현한 바는 다음과 같다.
def solution(food_times, k):
if sum(food_times) <= k:
return -1
food_times = [(i+1, v) for i, v in enumerate(food_times)]
food_times.sort(key=lambda x : x[1])
while k:
temp_v = food_times[0][1]
amount = temp_v * len(food_times)
if amount <= k and len(food_times) > 1:
k -= amount
food_times = [(i, v-temp_v) for i, v in food_times][1:]
else:
k = k%len(food_times)
break
return food_times[k][0]테스트 케이스를 돌려보니 효율성 테스트 이전에 정확도 테스트에서 일부를 제외하곤 대부분의 결과가 실패였다.
원인을 알 수 없어 로직도 살펴보고, 실패하는 테스트 케이스를 만들어보면서 왜 틀릴까 수도 없이 점검하다가 결국 원인을 찾았다!
바로 return 부분이 문제였다. 나는 food_times 리스트를 그대로 정렬하여 사용하다보니 음식의 순서가 뒤죽박죽 섞여서, 충분히 작아진 k의 값을 이용하여 다음 차례가 될 음식을 리턴해야 하는 부분에서 잘못된 음식을 리턴하고 있던 것이다.
따라서 return 문 이전에 food_times 리스트 안에 있는 각 요소의 첫번째 원소(음식의 번호)를 기준으로 정렬하는 코드를 추가했더니 정확도 테스트를 통과했다.
def solution(food_times, k):
if sum(food_times) <= k:
return -1
food_times = [(i+1, v) for i, v in enumerate(food_times)]
food_times.sort(key=lambda x : x[1])
while k:
temp_v = food_times[0][1]
amount = temp_v * len(food_times)
if amount <= k and len(food_times) > 1:
k -= amount
food_times = [(i, v-temp_v) for i, v in food_times[1:]]
else:
k = k%len(food_times)
break
food_times.sort(key=lambda x: x[0])
return food_times[k][0]하지만 한 경우를 제외하고 효율성 테스트에서 모두 시간초과가 떠버렸다..
k의 값을 많이 줄였다고 생각했으나 인풋이 200,000개이고 각각의 값이 1~200,000인 극단적인 케이스에서는 while 문이 20만번 돌고 그 안에서 food_times의 값을 재할당하면서 for문이 돌기 때문에 얼추 20만+(20만-1)/2번, 약 200억 번의 루프가 돌게 되는 셈이다.
결국, 핵심은 amount를 계산하는데 필요한 음식을 얻기 위해 for문이 아닌 다른 방식을 사용하는 것이었다. 이를 위해 매 번 가장 적은 소요 시간을 가진 음식을 트래킹해주어야 했고, 동시에 이미 소요된 시간을 함께 고려해주어야 했다.
이를 해결하기 위해 내가 짠 코드는 다음과 같다.
def solution(food_times, k):
if sum(food_times) <= k:
return -1
food_times = [(i+1, v) for i, v in enumerate(food_times)]
food_times.sort(key=lambda x : x[1])
past_time = 0
while k:
temp_v = food_times[0][1] - past_time
amount = temp_v * len(food_times)
if amount <= k and len(food_times) > 1:
k -= amount
past_time += temp_v
del food_times[0]
else:
k = k%len(food_times)
break
food_times.sort(key=lambda x: x[0])
return food_times[k][0]하지만 효율성 테스트 케이스 하나만 더 통과될 뿐 여전히 시간초과가 발생했다.
코드를 한참을 들여다보다가 리스트의 0번째 요소를 삭제하는 비용이 무척 크다는 생각이 들었다. 파이썬에서는 리스트가 '배열 + 링크드 리스트'의 구조라고 알고 있는데, pop() 연산이 배열에서 원소를 삭제하는 것처럼 진행될 수도 있다는 생각이 들어 deque를 사용했다.
def solution(food_times, k):
from collections import deque
if sum(food_times) <= k:
return -1
food_times = [(i+1, v) for i, v in enumerate(food_times)]
food_times = deque(sorted(food_times, key=lambda x: x[1]))
past_time = 0
while k:
temp_v = food_times[0][1] - past_time
amount = temp_v * len(food_times)
if amount <= k and len(food_times) > 1:
k -= amount
past_time += temp_v
food_times.popleft()
else:
k = k%len(food_times)
break
food_times = sorted(list(food_times), key=lambda x: x[0])
return food_times[k][0]최종적으로 해당 코드로 문제를 풀 수 있었다. 더 깔끔하게 코드를 줄일 수 있겠지만 너무 지쳐서 여기까지 하기로 했다. 내일 다른 사람들의 풀이를 찾아봐야지.
배열보다 queue에서 원소 삭제의 비용이 훨씬 적다는 것을 이미 너무 잘 알고 있었는데, 문제에서 해당 개념을 떠올리고 적용하기까지 너무 오랜 시간이 걸렸던 문제였다.
