[GangBean] Week 5 #846
[GangBean] Week 5 #846
Conversation
| if (i == 0) { | ||
| prices[i] = 0; | ||
| } else { | ||
| prices[i] = Math.max(prices[i-1], prices[i] - minPrice); |
There was a problem hiding this comment.
넵 이 문제는 추가 공간 할당 없이 처리 가능하더라구요 😀
| // System.out.println(groups); | ||
| List<List<String>> ret = new ArrayList<>(); | ||
| ret.addAll(groups.values()); | ||
| return ret; |
There was a problem hiding this comment.
요렇게 하시면 좀 더 깔끔할 것 같습니다.
| // System.out.println(groups); | |
| List<List<String>> ret = new ArrayList<>(); | |
| ret.addAll(groups.values()); | |
| return ret; | |
| return new ArrayList<>(groups.values()); |
There was a problem hiding this comment.
감사합니다 말씀해주신대로 입력파라미터 생성자로 처리하는게 코드 가독성이 좋을것 같네요
| - insert: O(1) | ||
| - search: O(L * N), where L is the length of list, N is the length of each words. | ||
| - startsWith: O(L * N) |
There was a problem hiding this comment.
insert()의 성능을 희생해서 search()와 startsWith() 성능을 올릴 수 있는 길은 없을까요?
There was a problem hiding this comment.
안녕하세요, @GangBean 님! 공유주신 코드 잘 보았습니다. 저도 몇 가지 궁금한 부분들 코멘트 달아두었어요! :)
|
|
||
| private List<String> words; | ||
| public Trie() { | ||
| words = new ArrayList<>(); |
There was a problem hiding this comment.
현재 구현해 주신 방식으로 기준으로 보았을 때 words 를 배열보다는 Dictionary 형태가 더 효율적일 수도 있을 것이라 생각이 들었어요. 즉, Array 에서 search 를 진행할 때 특정 word 를 찾기 위해서는 O(n) 이 걸리지만, Dictionary 로 관리하면 O(1) 이 걸리기 때문인데요, 혹시 Array 를 사용해주신 이유가 있으실까요?
There was a problem hiding this comment.
맞습니다!
풀이 관점에서 list를 사용한 기술적인 이유는 없구, 말씀해주신대로 hashtable 형태의 자료구조를 사용하는게 search 시 성능이 더 좋을거라는데 동의합니다!
다만, 가장 먼저 떠오른 자료구조였고, 더 나은 알고리즘(시간, 공간복잡도 관점)으로 나아가기 위한 문제점을 찾아 정의하고 개선해나가는 연습을 하기 위해서 굳이 list를 사용해 풀이를 진행했습니다 😄
| // Decodes a single string to a list of strings. | ||
| public List<String> decode(String s) { | ||
| List<String> ret = new ArrayList<>(); | ||
| int delimeterIdx = s.lastIndexOf(";"); // O(N * L) |
There was a problem hiding this comment.
한가지 궁금한점이 있습니다. 현재 encode 함수의 return 값은 다음과 같을 것 같아요.
["hello", "world"] // Input
"helloworld;(0,5)/(5,5)" // Output
따라서 decode 과정에서 s 의 뒤에서 부터 ; 를 찾는 과정이 있는 것으로 보입니다. 이 때문에 단어의 길이에 비례하여 ; 를 찾는 시간이 길어질 것 같아요. 물론 전체 시간 복잡도에는 영향이 없지만, 만약 중간중간에 단어의 meta 정보를 넣는다면 이 과정이 생략될 수도 있을 것 같아서요, 혹시 meta 정보를 아예 뒤로 분리하신 이유가 있으실까요?
There was a problem hiding this comment.
음 일단 meta 정보를 뒤로 분리한 이유는, 본문과 meta 정보를 구분하는데에 위치 정보(처음 혹은 마지막)가 필수라고 생각해서였습니다!
메타 정보와 본문을 분리하기 위해선 구분자, 혹은 공통된 format의 메세지 구조를 정의해야, 이를 통해 각 본문과 메타정보 페어를 각각 분리해 처리할 수 있을텐데, 어떤 형태로 format을 정의해도 본문에 동일한 구조의 문자가 나올 수 있기 때문에, 이 정보들만으론 알맞은 페어 단위로 분리할 수 없다고 생각했습니다.
위치 정보를 추가한다면 명확한 구분 기준을 부여할 수 있을거라 생각해 뒤쪽으로 메타정보를 몰아두는 방식으로 구현했습니다.
말씀해주신대로 메타정보를 각 본문과 연결해 구현하는 방식이 가능하다면, 제가 구현한 방법이 메타 정보 문자열의 길이 만큼의 탐색이 추가로 필요한 비효율이 있는 것 같습니다!
답안 제출 문제
체크 리스트
In Review로 설정해주세요.