level2 : 구현, 또는 동적 계획법을 사용하는 문제이다. 처음 풀이로는 빠르게 풀기 위해서 그냥 단순히 구현을 했다. 입력이 1000 x 1000 이라, 완전 탐색을 수행하더라도 로직을 최대한 덜 쓰도록 짜야된다는 생각을 하면서 짰다.
풀이 하라는 대로 구현했다. 이거 부캠 시험에서 나온것 같은 기분이.
level2 : SQL 사용 생각 간단하다. 예시를 보고 외우던가 나중에 찾아보자.
풀이 실패했다. 뭔가 감은 오는데 기존의 dp처럼 풀려고 하니 문제가 안잡히는 기분. 일단 접근 방법은 맞으니, 엑셀처럼 나열하면서 규칙을 찾는 것이 좋다.
풀이 문자열 정렬의 아이디어는 항상 갖고 있는게 좋을 것 같다. 약간 스킬 적인 측면으로 작용하는데(~~~이거 버그아닌데 스끼린데~~~) 음 일단 보자. 이 문제는 보면 특징이 있다. 일단 다 만드는 것은 잘못된 방법이다.
풀이 아. 시도를 총 세번했다. 해시맵으로 발생할 수 있는 모든 구간에서 시청하고 있는 사람을 저장 아이디어는 좋았으나, 실제 계산할 때 n^2을 피할 수 없음.
풀이 구현 문제라 풀만하긴 한데, 코드가 깔끔히 짠다그래도 아직 부족하다. 다시한번 꼭 짜보자. 리팩토링 연습이다.
풀이 트리 구현을 한번도 안해보다가 처음으로 했다. 첫 시도에서는 바로 구현을 못하고 다른 코드를 참고 했다. 반복적으로 연습하면서 체득을 해야 겠다.
풀이 정말 미쳐버리겠다. 왜 구현을 못하지. 왜 while문으로 구현을 못하는 걸까. 푸는 방법 다 알아놓고. 미쳐버리겠다.
풀이 시뮬레이션 문제이다. 시뮬레이션 문제는 순서를 명확하게 이해하고 이를 지켜주는 것이 매우 중요하다.
풀이 일단 DFS로 풀었다. 근데 풀이를 보니 다 BFS로 풀었더라. 그래서 다음날 다시 도전할 거다.
풀이 가장 최소인 녀석을 계속해서 뽑아야 하기 때문에 heap 구조를 사용했다. 이 때 python으로 코딩을 하려한다면 무조건적으로 heapq를 사용할 것. priorityQueue는 속도가 너무 느려서 효율성 통과를 하지 못한다.
풀이 deque, heap을 통해서 구할 생각을 했다. 그런데 구현을 하는 점에 있어서 어떠한 요소가 필요하겠다고 생각하는 능력이 좀 떨어진다. 몇개의 변수를 사용하면 쉽게 구할 수 있다와 같은 판단을 하는 것이 모자라다.
풀이 좀 어려울 수 있지만, 시간 초과가 나면 무언가 규칙이 있다는 생각을 해보자. 일단 찾을 수 있는 규칙은 다음과 같다. 최소공배수로 나눈 작은 모양이 반복되어 발생한다.
풀이 처음에는 각각의 order의 메뉴와 다음 메뉴와의 교집합을 사용해서 풀려고 했으나 문제는, 결국 몇번 시켰는지 알아내야 한다는 점에서 막혔다.
풀이 아니, 갑자기 딕셔너리 소트 안되는게 말이냐구. 왜 다 풀줄 아는데 꼭 저런거 때매 문제일까. 더 많이 풀어서 오류를 판단하는 눈을 길러야 한다. Code def solution(genres, plays): # 속한 노래가 많이 재생된 장르를 먼저 수록.
풀이 순열로 해결했다. n이 작아서 가능했다. 순열로 가능한 순서의 모든 banned를 나열하고, 각각에 대해 가능한지 확인하여 문제를 해결했다.
풀이 그냥 풀었다.
풀이 어떻게 해야 이런 문제를 풀 수 있을까. 일단 조합과 같은 생각은 n이 작을 때 한다. 완전 탐색 방법을 먼저 생각한다.
풀이 일단, 200,000이라서 n^2은 안된다. 그러면 한번에 가야하는데, 이 때, 잘 살펴보면, 해당 스테이지에서의 실패율은 stage잔존 수/stage 통과수로 정의된다.
level3 : join을 사용하는 문제이다. 생각 이 문제를 풀기 위해서는, join이라는 쿼리가 어떻게 돌아가는 지 알아야 한다. right join, left join등 다양한 join의 방법이 있지만, 일단 기본적으로 join을 하면 그냥 합쳐진다.
풀이 BFS로 풀었는데, 배열이 reference로 전달되어 애먹었다.
풀이 아무 생각 없이 재귀로 풀었다. 그냥 어느 위치에 있는지에 따라 값이 변하길래. 아마 최근에 정렬문제를 많이 푼 탓인가보다. 그래서 풀고나서 다른 분 코드를 보고 규칙을 나도 파악해 보기로 했다. 일단 사실 문제를 안읽었다.
level2 : limit을 사용하는 문제이다. 생각 가져온 table에 대해 제한을 걸어, 그 만큼의 행만 가져오게 하는 문제이다.
level3 : join을 사용하는 문제이다. 생각 이 문제를 풀기 위해서는, join이라는 쿼리가 어떻게 돌아가는 지 알아야 한다. right join, left join등 다양한 join의 방법이 있지만, 일단 기본적으로 join을 하면 그냥 합쳐진다.
level4 : table을 분리하는 방법을 사용해보자. 생각 문제가 잘 안풀리면, 제공해주는 table을 분리하고, 그 분리한 table로 부터 원하는 결과를 도출해보자. 즉 sub query를 사용해서 임의로 table을 만드는 것.
풀이 쉬워서 패스. 해시사용 문제이다.
풀이 일단 input보고 항상 판단하는 것이 중요하다. 방향만 잘 잡으면 어느정도 풀 수 있다. 이제. 이분 탐색의 핵심은 결국 값을 제안하고, 그 값이 맞는지 틀린지를 검증하는 로직을 찾을 수 있냐는 것이다.
level4 : 변수를 사용하는 문제이다. 생각 이 문제는 group by를 사용할 수 없다는 것이 핵심이다. group by 는 있는 값을 DISTINCT하게 판단하여 집합을 구성해주는 쿼리이다.
풀이1 이게 보면, 전화번호 개수가 백만개라 단순히 비교로 풀면 n^2이라 박살난다. 그렇기 떄문에 다른 방법을 고민해야한다. 이 문제의 핵심은 결국 특정 단어가 접두어로 있는지에 대한 문제이다. 그렇기 때문에 startswith를 생각하는 것이 편하다.
풀이 prices의 길이가 100,000이라 n^2으로 짜면 터질 것 같아 stack으로 구현했다. 그런데 이때, 특정 원소가 조사해야 하는 부분은 i+1부터 끝까지의 요소이다. 그 과정에서 중복이 발생하기 때문에 반대로 정렬한뒤 값을 구해주었다.
level2 : case when을 사용하는 문제이다. 생각 쿼리로 가져온 table에 대해서 추출을 진행할 때, 사용할 수 있는 테크닉이다. 이건 예제로 보는 것이 정확하다.
풀이 하라는 대로 구현했다. 일단, board에서는 빈칸을 찾아야 하고, table에서는 채워진 조각을 찾아야 한다. 각각에서 그 빈 구석을 모두 도려낸 뒤에, 그 조각들이 맞는지를 완전탐색했다.
level3 : join을 사용하는 문제이다. 생각 이 문제를 풀기 위해서는, join이라는 쿼리가 어떻게 돌아가는 지 알아야 한다. right join, left join등 다양한 join의 방법이 있지만, 일단 기본적으로 join을 하면 그냥 합쳐진다.
풀이 그냥 막 풀었다. 컨디션이 좋지 않다.
풀이 다익스트라로 한번에 성공했다. 그래도 발전이 있나보네. 스위프트로 플루이드 워셜로 다시 풀었다. Code # AB가 함께 모든 노드까지 가는데 걸리는 최단 거리를 구한다. # 그리고 그 거리 각각에서 출발하여 # 1.
풀이 그냥 막 풀었다. 컨디션이 좋지 않다. 이전에 풀었던게 더 깔끔하더라. 그리고 같은 부분에서 틀렸다. 멍청해.