Written

https://school.programmers.co.kr/learn/courses/30/lessons/43165 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 어렵지 않은 DFS 문제였습니다. 주어진 vector의 현재 위치의 값을 더하는경우와 빼는경우를 체크해서 모든 경우를 탐색해보고 마지막 인덱스까지 갔을때, 그 값이 문제에서 주어진 타겟과 같으면 경우의 수를 하나 늘려주면 간단하게 답을 구할 수 있었습니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 3..

https://school.programmers.co.kr/learn/courses/30/lessons/64065 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 문제를 끝까지 읽고나면 규칙이 하나 보이게 됩니다. 제일 앞에 위치하는 숫자가 튜플의 size만큼 등장하고 그 뒤로는 한번씩 덜나옵니다. 즉 만약 [2,1,4,3]이 정답이라면 2가 4번 1이 3번 4가 2번 3이 1번 등장하는 구조입니다. 이렇게 어떤 숫자가 몇번 등장하는지를 체크하기에 가장 좋은 자료구조는 map이기 때문에, map을 사용하면 쉽게 풀 수 있습니다. map로 map을 하나 생성..

https://school.programmers.co.kr/learn/courses/30/lessons/67257 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 사실 문제를 처음 읽으면서 못풀것같다라는 생각이 들었습니다. 연산자 & 문자열이 믹스된 문제들은 항상 어려웠던 기억이 있어서 시작부터 사실 쫄고 들어갔습니다. 근데 막상 끝까지 읽어보니 풀만한 문제라는 생각이 들었습니다. 그래도 지금까지 이런 문제 유형을 풀어보려고 노력했던게 도움이 되었던 것 같습니다. 연산자 우선순위와 문자열이 가미된 문제들은 풀어 볼 만한 것이 많기 때문에 많이 풀어보시면 충..

https://school.programmers.co.kr/learn/courses/30/lessons/68645 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 결국 문제에 조건이 주어져 있는것처럼, 구현을 하는 문제라고 생각을 했습니다. 특별한 알고리즘을 사용하는 것은 아니고 구현 문제라고 생각하여, 일단 3가지의 케이스가 있으니 각 케이스에 맞게 함수를 구현해봤습니다. 그리고 모든 테스트케이스가 위에서 왼쪽 아래로 -> 오른쪽으로 -> 왼쪽위로 계속 돌다가 끝나는 구조입니다. 다만, 어떤 케이스에서 끝날지는 모르고, 그 대신 총 횟수는 Input값인 ..

완전탐색 혹은 백트래킹 문제를 많이 풀어봤다면 쉬운 문제였다고 생각합니다. 현재 피로도가 입장할 던전의 최소 피로도보다 크거나 같다면 방문처리 및 피로도 감소 처리를 하면서 다시 Search를 호출하는 형태로 진행했습니다. 더이상 들어갈 던전이 없으면 지금까지 들어온 던전의 갯수를 ans에 넣어주고 마지막에 ans를 sort를 이용해 정렬해주면 됩니다. 입력 역시 시간초과에 걸릴만한 크기가 아니기 때문에 비교적 쉽게 정답처리를 받았습니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 #include #include #include using namesp..

처음 제출을 하고 테스트케이스 1번은 실패 그리고 11번과 30번대에서 시간초과를 하나씩 받았습니다. 시간초과기 때문에 while문을 유심히 살펴봤습니다. 결국 종료 조건을 통과하지 않는 경우의 수가 존재하는건데, 그 케이스를 처리하지 못하기 때문이라 생각하고 반례를 생각해봤습니다. 그리고 처음 든 생각은 [2,2,2,2] [2,2,2]과 같은 경우에는, 코드대로 큰 큐에서 작은큐로 이동할 것이기 때문에 2 하나가 무한으로 왔다갔다 하면서 cnt만 올라가니 cnt를 제한해야 한다고 생각했습니다. 그래서 cnt의 제한을 어떻게 두어야 하나 고민하다가, 큐1과 큐2의 사이즈를 더한거보다 커지면 두 큐의 합을 같게 만들지 못하는걸로 결론내리고 제출했습니다. 그리고 1번은 그대로 실패. 11번과 30번의 시간초..

discount의 구간을 앞에서 부터 10개씩 잘라가면서 각 구간에서 내가 사려고 하는 물품들을 전부 살수 있으면 카운트를 하나씩 늘려주는게 가장 먼저 떠오른 풀이방법이었습니다. 완전탐색의 방식이기 때문에 시간복잡도를 반드시 확인 해봐야죠. 만약 입력값이 크다면 완전탐색이 아닌 다른 방식의 풀이로 풀라는 의미입니다. 이 문제는 최대 입력값이 100,000이고 각 구간마다 10번씩 탐색하기에 시간초과에는 걸리지 않을거라 판단하고 완전탐색으로 돌렸습니다. 내가 사려고 하는 물품들에 대한 정보는 map로 저장해두고 하나씩 줄이면서 모든 탐색이 끝나고 사려고하는 모든 물품의 갯수가 0보다 작거나 같으면 카운트를 ++해줬습니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19..

정답을 만들어낼 수 있는 모든 조건의 경우의 수를 다 탐색해보는 문제였습니다. 문제가 길긴 하지만 어려운 부분은 딱히 없고 그대로 구현만 하면되는데, SoloGame 함수의 인자로 cards를 넘길 때 참조로 넘기게 되면 cards의 변화가 계속 반영되기 때문에 참조가 아닌 일반적인 복사 형태로 넘겨야합니다. 그래야 경우의 수마다 서로 다른 cards를 참조해서 정확한 답을 도출할 수 있습니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 #include #inc..