실무랑 연관지으신 부분에 대해서만 의견을 좀 말씀드리겠습니다.
문제 풀이를 실무에 빗대자면 채점은 프로그램을 실제로 서비스로 내놓는 단계에 해당할 것입니다. 얼마나 다양하고 예상할 수 없던 케이스가 있을지 모르는 상태로, 프로그램에 버그가 얼마나 있는지 체크해보는 과정을 거치지 않고 무작정 서비스를 시작한 뒤 발생한 문제점을 바탕으로 디버깅을 하는 것이 좋지는 않을 것입니다.
실무에서는 누군가가 예제를 대신 만들어 주지도 않습니다. 실제로 이 프로그램을 다양한 상황에 넣어보았을 때 항상 잘 동작하게 할 수 있는지를 테스트하기 위한 케이스는 대부분 직접 만들어보아야 합니다. 그런 점에서 보면 오히려 예제를 거의 제공하지 않는 편이 실무에 가깝다고 할 수 있고, 직접 그러한 상황들을 시뮬레이션해볼 수 있는 케이스들을 손수 만들어보는 것이 실력에 큰 비중을 차지한다고 할 수 있겠습니다.
실무를 생각하면서 많은 예제가 제공되기를 바란다는 것은 결국 프로그램의 정당성을 확인하기 위한 절차를 먼저 거쳐보지 않고, 누군가가 버그를 대신 제보해줄 때까지 기다리겠다는 뜻이라고 생각합니다.
chun75 3년 전
인터넷 풀이 같은거 참조 안하고 혼자서 풀었는데
8%에서 틀렸습니다.
여기서 검색한 데이터와 제가 생각한 데이터는 다 맞게 나와서 막혔습니다.
이 문제 관련 몇 개의 다른 예제 좀 부탁드립니다.
혹 소스 코드 버그 잡아 주시는 분이 있을지도 몰라 소스 이야기를 하자면
(솔직히 코드 이쁘게 정리안해서 민망하긴 합니다. C++ 17도 가장 컴파일 에러 없을거 같아서 선택했습니다.)
처음에는 무방향성 그래프로 brute force스타일로 구현하였습니다.
하지만 시간 초과가 나와 LCA 스타일로 다시 구현하였습니다.
소스에 흔적을 남겨놓느라 solve관련 함수가 2개입니다.
알고리즘은 LCA Tree 만들고 두 개의 데이터 모두 Root인 1번까지 찾아가게 만들었습니다.
그 이후 2개의 path에서 처음 나오는 공통부모에서 멈추고 출력하게 하였습니다.
여기 글 읽어보면 데이터를 공개안하는게 좋다고 하는거 같은데
개인적으로는 실무하다보면 버그 잡으려면 버그 상황을 보는게 제일 좋기 때문에
현실적으로는 풍부한 예제를 바탕으로 만드는게 좋다고 생각합니다.
그럼 잘 부탁드립니다. __;