일단 씻고 나가자

워~ 쉽다 이거이 다 쉽워~ 문자열의 수정이나 삭제는 문법적인 주의도 요해야 함과 동시에 논리적인 흐름도 신경 써야 해서 어지러운 것 같다. 따라서 문자열의 수정 관련 클래스와 규칙성만 발견한다면 잘 해낼 수 있었던 문제. 물론 코딩 끈이 짧지만, 개인적인 철학으로는 '내가 이 문제를 푸는 방법을 그대로 코딩에 적용하자'라는 마인드가 있다. 다만 사람이 푸는 건 시각적으로 슥 보는 순간 뇌에서 여러 논리적인 흐름을 거쳐 답을 도출하므로, 내가 어떤 논리적은 흐름을 거쳐서 답을 도출해낼 수 있었는지에 대한 성찰과 설명이 필요하다. 다만 순간적인 판단으로 답을 내리는 건 적용해서도 안 되고 적용할 수도 없다. 예제 3번의 경우는 문자열의 크기가 워낙 작기 때문에 보기만 해도 직관적으로 답을 낼 수 있지만, ..

뉴진스의 하Heap보이요. 수많은 시간초과에 진짜 이를 바득바득 갈며 멘탈이 수없이 나갔던 문제. 구현만 완료하면 문제 자체 내용은 어렵지 않았으나, 시간초과에 컴파일 에러에.. 그만큼 입력과 출력에서 시간을 줄이는 방법에 대해 크나큰 깨달음을 얻은 문제다. 다시는 시간초과로 고통 받고 싶지 않아 정말.. (수도 코드(pseudo code)가 한국말로 의사 코드란 걸 처음 알게 됐다.) 서두에서 말했던 것처럼 의사 코드만 잘 구현하고 추가적인 요구사항만 조금 넣어주면 쉽게 풀 수 있으므로, 의사 코드 자체를 해석하는 시간을 가져보자. 그러려면 Heap이란 무엇인가를 알아야 한다!! 대충만 알아보자!! 힙이란 완전 이진 트리를 베이스로 한 자료구조이며, 완전 이진 트리란 모든 층이 꽉 차 있어야 하진 않지..

링크드 리스트 리스트 리스트 리스트리스트.. 리스트리스트리스트리 스트리 스트리 스트리 스토리 티스토리...!!!! 내 티스토리 흥하자!!!!!!!!!!!!!!!!! 진짜 도저히 드립 생각이 안 났다. 링크드 리스트의 활용법과 출력부를 고민해야 하는 짬뽕 문제였다. 생각보다 출력부의 포맷을 맞추느라 고민을 좀 했었던.. 쓰이는 빈도수가 아주 높은 링크드 리스트와, 다른 문제에서도 나올 수 있는 출력 형태에 대한 경험이 생긴 것 같아서 앞으로의 코딩에 좋은 도움을 얻을 듯한 문제! 생각보다 이해는 어렵지 않은 문제다. 당신이 도넛을 먹는데, 왜곡된 섭취 패티쉬에 감염되어 일정 구간을 두고 베어 먹고 싶어졌다. 한 입 베어문 이후 3센치를 지나서 베어 먹는 것을 반복하며 도넛을 다 먹고 싶은데, 그러다 보면 ..

해시가 웃으면? key key key.. 아 이 드립 너무 value인가..? 전형적인 해시와 상관 없는 수학문제. 꽤나 고생했다. 규칙성은 찾았으나 확신도 없고 구현하는 데에 애를 먹어 컨닝을 좀 했따.. 잘 하는 사람이 정말 너무 많다.. 자괴감이 든다.. 일단 어마어마한 문제 설명을 보고 아무 생각이 들지 않았으나, 차근차근히 보고 이해..를 해보려고 노력했다. 진짜 해시 함수 구현해서 숫자 하나하나씩 계산하고 해시맵에 넣어?라는 못된 생각을 하기도 했지만.. 수의 범위와 1000000007 로 나눈 나머지를 출력하라는 걸 보고 컴퓨터가 터질 수도 있겠구나 해서 이를 갈며 공책을 꺼냈다. 대놓고 이런 복잡한 문제는 수능 수학문제처럼 규칙을 찾아내라고 말 하는 것 같다. 두드리면 열리리라.. 대략적인..

배열은 별거 아니다. 별이 배열거 아닌 이유가 뭐냐면, 우선 별은 배열로 어렵지 않는 데다가 나는 남들보다 몇 배열 심히 별의배열 문제를 매열배일 풀고 있기 때문배열.replaceAll("배열", "별"); 이번 문제는 그냥 아이디어만 있으면 2분만에 콧등 벅벅 긁으며 풀 수 있는 문제였지만, 메모리와 시간 비교를 위해 여러가지 시행착오를 겪었던 문제였다. 이번 문제로 깨달은 것으로 이번 문제 뿐 아니라 앞으로의 코테에 여러가지 도움을 받을 수 있을 거 같다. 문제 풀이의 아이디어와 여러가지 시행착오를 공개하겠다. 1. 정렬로 풀기 문제 보자마자 Arrays.sort() 안 떠오른 흑우 없제~~ 간단한 아이디어로, input 받은 값들을 배열에 넣어서 정렬하면 맨 처음 index엔 가장 작은 수가, 맨 ..

형편 없는 메모리와 시간 ㅋㅋ큐ㅠㅠ 그래도 큐 클래스를 사용하지 않고 문제 해석과 논리성만을 이용해서 풀었다는 거에 의의를 두자.. 문제 해석과 규칙성 발견에만 엄청난 시간을 쏟았던 문제. ㅋㅋ큐ㅠㅠ ㅋㅋ큐ㅠㅠ ㅋㅋQueueㅠㅠ 처음 틀렸을 때 for문의 length를 잘못 설정해서 틀렸었는데, 고치고 IDE에서 돌려 보니 논리적인 문제도 있었다. 조금 더 세심하게 보자. 역시 자바는 Queue 클래스를 가지고 있고 그걸 알고 있었으나, 걍 개인적인 고집으로 쓰지 않고 논리적으로 풀려고 했던 것 같다. 결과는 시간과 메모리의 아작. 괜히 Queue 클래스 한 번도 안 써봐서 두려웠던 점도 있었다. 앞으로 또 그런 생각으로 안일하게 문제를 푼다면 걍 뒤질 것이다. 이번에도 역시 문제 이해만 해도 힘들었다...

너무 오랜만에 백준을 썼더니 클래스명에서 컴파일 에러를 내버렸다.. BJ_25556_FourStack 은 왜 클래스명에 맞지 않는 걸까? 간지나는 클래스명 짓기야말로 내 코딩 인생 우선 순위에서 pop() 할 관심사인데.. 기본적인 스택의 개념을 묻는 문제인 것 같다. 자바는 또 Stack이라는 클래스를 가지고 있어서 활용하기 알맞게 떠먹여 주고 있다. 우선 뭔 소린가 문제를 한참 봤다. 스택이니까 스택 개념은 관련이 있을 텐데.. 한참 보고 예제를 손수 해보니까 뭔 소린지 그제야 이해가 가더라. 문제를 다 이해하고 보니, 굳이 이게 스택 관련..? 수학적인 이해만 있으면 되는 거 아닌가..? 그래서 굳이 스택 클래스를 쓰진 않았다. 우선 킹모장에 첫 번째 예제를 써보고 순서대로 적어보았다. 오름차순 정..