HwangHub

🤔 Intuition 딱 봐도 단순 구현으로 보였다. 시간복잡도가 들어오는지 계산해봤는데, 시간제한이 2초인 데다가 1초 이내로도 충분히 끊어낼 것으로 봐서 단순 구현으로 풀었다. 🔎 Algorithm & Complexity * @algorithm implementation * @time O(N*M*K*R*C) : 노트북 위 탐색기준좌표 O(N*M) * 스티커 개수 O(K) * 스티커 크기만큼 탐색 O(R*C) -> 188ms * @memory O(N*M + R*C) : 노트북 배열 O(N*M) + 스티커 배열 (R*C) -> 16204 KB 👨🏻‍💻 Logic 하라는 대로 하면 된다. 1. 스티커를 입력받고 2. 노트북에 스티커를 붙일 수 있는지 체크하고 (조건에 따라 좌상부터 우하 방향으로 진행) 3..

🤔 Intuition 처음에 완탐인 줄 알았다. N과 M이 50 이하이고 시간제한이 2초 이내라서 거의 확신을 했다. 근데, 일단 TC만 맞고 나서, 제출하니까 3%에서 바로 틀렸다. (실전이였다면 맞았다고 착각해서 틀렸을 확률 99.9%) 진실을 아는 사람들이 있는 파티에 참여하는 사람들도 진실을 알게 되는데, 이게 1다리만 계산하면 되는 게 아니라 엮이는 사람 간의 관계 모양이 skewed tree가 될 경우에는 반복수를 감안할 수 없기 때문에 브루트포스로는 반복수의 기준이 명확하지 않다. 즉, 관계성을 계속 저장해둬야 하는 문제였던 거다. 이는 사람간의 그래프를 형성하는 문제라고 볼 수 있으므로, union find로 풀어낼 수 있다. 🔎 Algorithm & Complexity * @algorit..

🤔 Intuition 바라는 게 많은 시뮬레이션 문제. 길을 잃지 않도록 변수명을 잘 선언하고, 로직을 잘 구성한 뒤 코드를 작성해야 할듯. 탐색은 정직하게 달팽이탐색으로 구현할 것. pull 또는 stretch 과정에서 temp 배열 인덱스를 복잡하게 운영하는 것보다는 1차원으로 차곡차곡 쌓아두고, 이를 고대로 다시 달팽이탐색으로 복붙하는게 편할 듯 연속되는 구슬을 터뜨리기 위해 좌표를 저장하는 건, 나중에 길이를 체크하고 되돌아가서 하나하나 터뜨리는 논리이므로 stack 자료구조가 적절할 듯 🔎 Algorithm & Complexity Algorithm : 시뮬레이션 시간복잡도 : O(N^4) : N^2 탐색 X 최악의 경우 stack에 N*N개 채워진 상태로 뒤로감기 → 480 ms 공간복잡도 : ..

🤔 Intuition 첫 인상에서 그리디/Meeting-room-problem과 유사해보였습니다. 그리디로 선택을 한다고 할 때, 예외가 있는지 고민해봤는데 결국 널빤지를 최소한으로 깔아야 하니 최대한 길게 배치하는게 좋다는 건 자명하면서, 널빤지 영역을 빠짐없이 커버해야 하니까 결국 시작점을 기준으로 그리디하게 배치하면 문제 없겠다 싶었습니다. 다만, 하나의 널빤지로 두 웅덩이를 커버할 경우, 이를 체크할 수 있냐 없냐가 포인트였던 것 같고, 저는 이걸 마지막으로 널빤지를 두었던 좌표 +1 좌표(다음 널빤지를 놓기 시작할 위치) int lastIdx라는 변수로 저장하여 이를 기준으로 다음 웅덩이의 시작점 int s와 끝점 int e를 이용해 if 분기로 검사해 주었습니다. 이 과정에서 널빤지 개수가 좌..

🤔 INTUITION 그냥 중력 시뮬 문제로 이해했습니다. 다만, 합쳐진 숫자였는지 여부 체크를 곁들인... 중력 적용 중 숫자가 동일할 경우 merge 연산이 수행되어야 하는데, 이게 연속적으로 발생할 수 없다는 게 이 문제의 유일한 포인트로 보였습니다. merge 연산 여부를 체크하는 걸 어떻게 할까 하다가, 저는 int 범위 이상의 숫자를 merge 연산 결과에 더해줘서 그 이후로는 이 숫자가 그 어떤 숫자와도 일치하지 않도록 해서 중복 연산되지 않도록 처리해 줬습니다. 이는 다시 배열을 업데이트 할 때 mod 연산으로 제거해 줬습니다. ✅ ALGORITHM 시뮬레이션 map을 저장합니다. int[] temp 를 이용하여 한 줄 한 줄 중력을 적용해 줍니다. 만약, 숫자가 합쳐지는 경우에는 10^1..