[forest000014] Week 09 #994
Conversation
| } | ||
|
|
||
| while (l <= r) { | ||
| int m = (r - l) / 2 + l; // 만약 문제 조건상 l, r의 합이 int 범위를 넘어가서 overflow가 생길 수 있는 경우에, 이런 식으로 overflow를 방지할 수 있다고 알고 있습니다. 이 문제는 overflow 걱정은 없지만, 나중에 실전에서 나오면 잊지 않으려고 이렇게 구현해보았습니다. |
| } | ||
| } | ||
|
|
||
| return -1; |
| if (m > 0 && nums[m - 1] > nums[m]) { | ||
| return nums[m]; | ||
| } else if (m < nums.length - 1 && nums[m] > nums[m + 1]) { | ||
| return nums[m + 1]; | ||
| } else if (nums[m] > nums[l]) { | ||
| l = m + 1; | ||
| } else { | ||
| r = m - 1; | ||
| } | ||
| } |
There was a problem hiding this comment.
조건문을 세 부분으로 줄일 수는 없을까 고민해봤습니다 :)
return하는 조건r를 옮기는 조건l를 옮기는 조건
| if (m > 0 && nums[m - 1] > nums[m]) { | |
| return nums[m]; | |
| } else if (m < nums.length - 1 && nums[m] > nums[m + 1]) { | |
| return nums[m + 1]; | |
| } else if (nums[m] > nums[l]) { | |
| l = m + 1; | |
| } else { | |
| r = m - 1; | |
| } | |
| } | |
| // 문제 조건상 입력 배열은 무조건 1 이상의 rotation이 적용되어 있습니다. | |
| // 그리고 line19에서 우리는 가지런히 정렬된 입력 배열에 대해서는 바로 return할 수 있는 조건문을 작성하였습니다 | |
| // 따라서 우리가 m == 0인 nums[m]을 return할 일은 없으므로 m > 0이라는 조건은 생략할 수 있습니다 | |
| // 기존의 두번째 조건문은 제가 보기엔 불필요한 것 같습니다 | |
| if (nums[m - 1] > nums[m]) { | |
| return nums[m]; | |
| // nums[m]이 입력 배열 중 'rotation되지 않은 부분'에 속하는 경우입니다 | |
| // 이 경우엔 r을 줄여야 합니다 | |
| } else if (nums[m] < nums[nums.length - 1]) { | |
| r = m - 1; | |
| } else { | |
| l = m + 1; | |
| } | |
| } |
| */ | ||
| public class Solution { | ||
| private final int VISITED = -999999; | ||
| public boolean hasCycle(ListNode head) { |
There was a problem hiding this comment.
좋은 접근인 것 같습니다 :)
하지만 만약 문제 조건이 이렇게 주어졌다면 어땠을까요?
"입력으로 주어진 ListNode에는 변경을 가하지 마시오"
리스트노드의 acyclic 여부를 판명하는 잘 알려진 알고리즘이 있으니 소개드립니다, 참고 바랍니다 :)
https://en.wikipedia.org/wiki/Cycle_detection#Floyd's_tortoise_and_hare
There was a problem hiding this comment.
그동안 forest님 풀이를 봐오면서 느낀건데, 문제를 작은 단위로 쪼개어서 해결하는 능력과 끝까지 문제를 해결해내는 능력이 훌륭하십니다 :)
절대 이 풀이가 나쁘다는 건 아니구요, 리뷰어 입장에서 느꼈던 피드백 사항이 몇가지 있어 조심스레 남기고자 합니다
- 로직이 복잡합니다. 복잡한 로직이 나쁜 건 아니지만, 알고리즘 테스트를 실시간으로 (혹은 면접관 앞에서) 진행하는 상황이라면 이렇게 긴 풀이는 버그 발생 가능성이 높습니다. 최악의 경우엔 많이 꼬여서 시간 안배가 불가능하게 됩니다. (제가 그랬어요)
- 로직이 복잡하다는 건, 리뷰어가 해당 코드를 읽기 힘들다는 뜻이기도 합니다. 그리고 본인께서도 면접관께 설명드리기 더 어려우실 겁니다.
좀 더 간단한 로직을 사용하는 풀이를 하나 소개드리니, 참고 바랍니다 :)
https://github.com/DaleStudy/leetcode-study/blob/main/maximum-product-subarray/obzva.cpp
There was a problem hiding this comment.
@obzva
감사합니다! 사실 저도 매번 풀 때마다 막연하게 느끼던 부분이었는데, 정확하게 짚어주신 것 같습니다.
제가 주말 전후로 몸살을 심하게 앓아서 이제서야 코멘트를 봤네요. 오늘은 육아하고 잠깐 들어와봤는데, 다시 야근하러 가야 할 것 같아서 내일 마저 읽어보겠습니다 🙇
답안 제출 문제
Week 8
Week 9
체크 리스트
In Review로 설정해주세요.