Taking baby-developer steps

- 기능 도출 1. 출력 메서드(파라미터 : 문자열 / return : X) - 파라미터로 전달받은 문자열을 터미널에 출력한다. - (게임 시작, 피드백, 재시작혹은 종료 시 사용자에게 알리기 위함) 2. 랜덤 수 선택 메서드(파라미터 : X / return : int(3자리 정수)) - 랜덤한 3자리 숫자 정수를 반환한다. - camp.nextstep.edu.missionutils.Randoms의 pickNumberInRange()를 활용 - 각 자리 숫자는 중복을 허용하지 않는다. 3. 입력 유효성 검사 메서드 (파라미터 : 문자열 / return : null 혹은 exception) - 사용자가 입력한 값의 유효성을 검사한다. - 2종류의 입력이 유효하다. (게임 도중 : 3자리 숫자 정수로 변환가..

먼저 대략적인 구상을 주석으로 달아두고, 각 기능을 수행하기 위해 구현을 하면서 기능이 잘 작동하는지 테스트 해보기로 했다. 0. 서버 프로그램이 실행되면 해당 프로세스의 PID값을 출력해야한다. -> getpid()함수 호출 1. 사용할 시그널을 sigset_t 자료형에 추가. -> sigaddset()함수 호출 -> sigismember()함수 호출로 추가되었는지 확인.

push_swap과제가 끝난 후 벌써 1주일이 되었다. 길고 길었던 디버깅과 최적화 과정을 버티고 버텨 오기로 끝까지 완성했지만, 아직 구현력이 매우 딸리는 나로서는, 인터넷에 공개된 다른 코드들을 빨리 빨리 받아들이고 이해하는 것이 더욱 중요하다는 깨달음을 얻었다. push_swap은 2달이나 소모할 과제는 아니였던것 같다. 물론 이것도 경험을 하고서야 깨달은 것이지만..! 지금은 '나만의', '새로운 것'을 창조하려고 하는것 보다는 효율적인 방법을 잘 찾아보고 습득하는 것에 더 익숙해지는게 더 알맞은 방법인것 같다. 기본적인 방법들을 사용할 수 있어야 응용이 있는거고, 그 응용에서 더 나아가 새로운 방법을 창출해내는 능력이 길러지는 것이니...! 짠내 폴폴 나던 나의 push_swap은 또 이렇게 나..

sort_a_mid가 이상이 있는 부분은 i가 바닥에 가까워, rra 연산을 사용할 때 였고, 해당 부분을 수정해서 a_stack에 있는 ㄹ구간을 정렬시켰다.(도중에 ㅁ구간을 a_stack에서 정렬한 뒤 다시 b스택으로 옮겼다가, ㄹ구간을 a_stack으로 옮겨서 정렬하는것이 효율적이지 못하다고 생각해, 정렬되지 않은 구간이 ㄹ, ㅁ 뿐일때, ㄹ구간을 먼저 a스택으로 옮겨 정렬하고, b스택에서 최소값을 a로 넘기는 방법으로 변경했다.) => ㄹ구간 정렬까지 사용한 명령어의 갯수는 총 5347개이다. => ㄹ 구간 정렬 이후, b_stack에서 바로 최소값을 하나하나 찾아서 a_stack으로 넘기니, 명령어의 수가 급격히 증가해버렸다. 다시 ㅁ구간을 따로 정렬하도록한다. 이미 구현한 함수들의 재사용성을 높..

지난 포스팅에서 deapart_chunk 함수를 만들어, ㄷ 구간을 a_stack으로 분리해내었다. depart하는 함수 내에서 대략적으로 ㄷ을 정렬할 때 나눌 구간을 미리 나눠두면 명령어를 더 절약할 수도 있을 것 같다는 생각이 들었지만, 일단 sort_a_chunk 함수를 재활용 하기 위해 해당 작업은 하지 않았다. 후에 명령어를 다시 줄여야 한다면 그때 작업하기로 한다. 일단 depart까지 사용된 명령어는 3270개 이다. (이 단계에서 301개 명령어 소요)-------- 다시 한번 sort_a_chunk 함수로 a_stack에 있는 ㄷ 구간을 정렬했다. a_top이 201인것을 의도 했으나 의도한 바대로 가진 않았다. 일단은 정렬의 효율성을 보는것이 중요하므로 해당 부분을 체크해두고 넘어가도록..

새로 알게된 사실이 있다! 5개 이하의 input 기준에서는 과제에서 요구하는 최소 기준이 또 다르다는 것이다. 3개 이하의 input이 들어온 경우, 3개 이하의 명령어를 사용하고, 5개 이하인 경우엔 12개 이하를 사용해야한다. 따라서 이 경우에는 a_stack에서만 정렬하는 sort_a_stack만을 호출하게 했고 결과는 다음과 같다. 본래 b_stack으로 옮기고 시작하던 sort_stacks()함수를 호출하는 것보다 명령어가 적어졌지만, Input이 3이하인 경우에 좀 더 최적화 해야하는 필요성이 생겼다.=>후에 sort_small 함수를 만들어 따로 최적화를 하기로 한다. 지난 포스팅에 이어 계속해서 sort_big에서 300개 이상의 input이 들어오는 경우를 최적화한다. 현재 상태에서 a..

100개의 청크를 또 다시 구간을 나눠 정렬하는 것이 최적화에 도움이 되는 지를 보기 위해 sort_a_chunk함수(하나의 청크를 다시 구간 나누어 정렬하는 함수)를 구현하고 있다. 먼저, 100개(100이상 200미만) 중 절반을 b스택의 top과 bottom으로 구간을 나누어 보냈다. 위 상태에서, sort_a_stack 함수를 이용해 a_stack에 있는 150~200까지를 오름차순으로 정렬했다. sort_mid()함수를 변형해, 125~149까지를 b_stack에서 a_stack으로 가져오면서 정렬했다. 다시한번 sort_mid()변형 함수(앞으로 sort_mid_1이라고 하겠다.)로 101~124까지를 a_stack에 정렬했다. ㄴ구간을 a_stack에 정렬 하기까지 1478개의 명령어를 사용..

현재 300개 이상의 Input에서 명령어 사용 수가 5500을 넘고, 500개 이하의 정렬에서 5500개 이하의 명령어를 사용해 stack을 정렬하는것이 목표이므로, 먼저 500개의 input을 넣고 sort_big() 함수의 단계별로 사용되는 명령어의 수를 출력해봤다. 생각보다 두개가 섞여있는 구간에서 한 구간을 빼내고, 이 구간을 a스택에서 정렬하는 부분에서 명령어 소요가 많았다. 단계별로 제일 명령어가 적었던 구간은, a_stack에 ㅁ구간을 빼놓은 다음에 그곳에서 정렬하는 부분이이었다. 내 알고리즘은 특성상 명령어를 합칠 수 있는 구간이 발생하지 않기 때문에, 명령어를 합치는 과정을 통해 최적화를 하는 효과는 기대할 수가 없다. 먼저, 현재 내 push_swap 프로그램에서는 이미 정렬된 inp..

현재 300개 이상의 인풋이 들어올 경우, 5500개 이하의 명령어 사용을 위해 정렬 알고리즘을 최적화를 해야 한다. 현재 300개 이하의 인풋에서는 구간의 갯수가 60개일 때가 70개일 때 보다 사용하는 명령어의 갯수가 적음을 확인했고, 360개 이상의 경우에는 70개인 경우가 60개일 때보다 사용하는 명령어의 갯수가 적었다. 또, 500개의 경우엔 각 구간의 갯수가 70개일 때보다 100개일 경우가 명령어 사용량이 훨씬 적었다. 이 결과를 미루어 볼때, 정렬시 구간이 5개 일때 명령어를 최소한으로 쓸 수 있다고 예측했고, 이를 통해 다음과 같이 각 구간의 크기를 변화시켜 output을 얻어보았다. 각 구간을 최적화하기 위해 여러 테스트 케이스들을 만들었다. 300개 까지만 구간 60으로 결정하고, 나..

236 line을 조금 수정해서, 초기상태에서 ㄹ구간만 a_stack에 남겼다. 그런데, 스택 출력을 통해, b스택의 바닥쪽 부분이 현재 ㄴ구간이 아니라는 것을 발견했고, 다시 239 line을 수정해, 다음과 같이 스택의 구간을 다시 나눴다. a_stack에 모아둔 ㄹ구간을 기존의 정렬 함수로 정렬해 봤다. a_stack 내 14개의 input을 정렬하는데 104개의 명령어가 소요되었다. 현재 정렬함수는, 정렬이 이미 된 부분을 b_stack에 잠시 보관했다가 다시 a_stack으로 가져오는 부분이 있는데, 이 부분에서 명령어의 소모가 심하다고 생각이 되었다. 현재 sort_a_stack() 함수가 정렬완료된 부분을 계속해서 b_stack에 옮겼다가 다시 계속 a_stack으로 가져오기 때문에 명령어의..