프로그래머스 팀에서는 기능 개선 작업을 수행 중입니다. 각 기능은 진도가 100%일 때 서비스에 반영할 수 있습니다.
또, 각 기능의 개발속도는 모두 다르기 때문에 뒤에 있는 기능이 앞에 있는 기능보다 먼저 개발될 수 있고, 이때 뒤에 있는 기능은 앞에 있는 기능이 배포될 때 함께 배포됩니다.
먼저 배포되어야 하는 순서대로 작업의 진도가 적힌 정수 배열 progresses와 각 작업의 개발 속도가 적힌 정수 배열 speeds가 주어질 때 각 배포마다 몇 개의 기능이 배포되는지를 return 하도록 solution 함수를 완성하세요.
테스트 케이스
progresses | speeds | return |
---|---|---|
[93, 30, 55] | [1, 30, 5] | [2, 1] |
[95, 90, 99, 99, 80, 99] | [1, 1, 1, 1, 1, 1] | [1, 3, 2] |
입출력 예 설명
입출력 예 #1
첫 번째 기능은 93% 완료되어 있고 하루에 1%씩 작업이 가능하므로 7일간 작업 후 배포가 가능합니다.
두 번째 기능은 30%가 완료되어 있고 하루에 30%씩 작업이 가능하므로 3일간 작업 후 배포가 가능합니다. 하지만 이전 첫 번째 기능이 아직 완성된 상태가 아니기 때문에 첫 번째 기능이 배포되는 7일째 배포됩니다.
세 번째 기능은 55%가 완료되어 있고 하루에 5%씩 작업이 가능하므로 9일간 작업 후 배포가 가능합니다.
따라서 7일째에 2개의 기능, 9일째에 1개의 기능이 배포됩니다.
입출력 예 #2
모든 기능이 하루에 1%씩 작업이 가능하므로, 작업이 끝나기까지 남은 일수는 각각 5일, 10일, 1일, 1일, 20일, 1일입니다. 어떤 기능이 먼저 완성되었더라도 앞에 있는 모든 기능이 완성되지 않으면 배포가 불가능합니다.
따라서 5일째에 1개의 기능, 10일째에 3개의 기능, 20일째에 2개의 기능이 배포됩니다.
※ 공지 - 2020년 7월 14일 테스트케이스가 추가되었습니다.
문제 풀이는 제 생각과 검색한 정보를 바탕으로 작성했습니다.
progresses[0] >= 100
일 때 progresses[0:] >= 100
중 연속적으로 만족하는 배열 갯수(배포 가능한 기능) 모두 출력progresses[0]
로 맞춤def solution(progresses, speeds):
Q=[] # 1
for p, s in zip(progresses, speeds): # 2
if not Q or Q[-1][0] < -((p-100) // s): # 3
Q.append([-((p-100) // s), 1]) # 4
else:
Q[-1][1] += 1 # 5
return [q[1] for q in Q] # 6
[출시일, 출시 가능한 기능 수]
를 할당할 변수 선언
progresses, speeds
를 p, s
에 할당
zip(progresses, speeds)
→[(93, 1), (30, 30), (55, 5)]
(리스트 변환 시)- loop마다
p, s
에 순서대로 대입
Q
에 값이 없거나(not Q
) 최근 입력된 값 Q[-1][(진도율 / 개발 속도)의 몫, 1회 배포 수]
중 Q[-1][0]
< -((p-100) // s
를 만족할 경우
- 1회:
-((진도율 - 100) // 개발 속도
→-((93 - 100) // 1 = 7
- 위 계산식은
p
가 배포 가능한 상태인진도율 >= 100
의 조건을 충족하기 위한진도율 + (개발 속도 * 작업 일)
의작업 일
을 구한 것이다.Q[-1][0]
보다p
의 작업 일이 크다는 의미는 먼저 개발되는 기능(Q[-1][0]
)보다 더 늦게 출시된다는 뜻이다.
#2를 만족할 시 값이 없거나 배포일이 늦다는 뜻이므로 appned
.
비교 중인 q, s
가 Q
의 최근 배포일보다 빠르거나 같으면 동시 배포
출시일 Q[:][1]
만 리스트로 return
출처: