Sejak tahun 2007, gua mulai terlibat sebagai problem setter dan juga juri untuk lomba pemrograman tingkat SMA yang setiap tahun rutin diselenggarakan kampus gua. Dari sini gua belajar, problem setter itu work as a team.
Setiap soal yang diperlombakan harus memiliki deskripsi dan batasan yang jelas. Tentu saja testdata yang digunakan juri untuk menilai juga harus menyentuh batasan ini. Tidak masuk akal jika di soal ditulis N <= 1000 tetapi testdata hanya mengetes sampai 10, tentu saja akan ada algoritma yang berbeda untuk batasan yang berbeda. Tidak perlu memikirkan algoritma yang lebih efisien jika ada algoritma yang lebih sederhana untuk menyelesaikan suatu masalah. Testdata juga harus mengetes kasus kasus khusus, kasus sangat kecil dan juga kasus sangat besar. Intinya disamping testdata untuk mengetes kecepatan algoritma yang digunakan oleh peserta, harus juga mengetes dengan testdata yang memiliki karakteristik “berbeda”.
Selain masalah teknis seperti komputer, sistem grader, dll, tingkat kesulitan soal merupakan suatu hal penting dalam suatu kontes. Dengan asumsi bahwa sistem berjalan lancar dan semua prosedur diketahui peserta dengan baik, tingkat kesulitan soal menjadi penentu bagaimana “asik” nya suatu kontes bagi para peserta. Untuk melihat distribusi kesulitan soal, tidak cuma diliat per soal, tapi keseluruhan set soal yang diperlombakan. Soal yang diperlombakan sebaiknya memiliki tingkat kesulitan yang baik dan juga tidak condong ke suatu teknik algoritma tertentu, melainkan mencakup berbagai macam algoritma.
Beberapa orang cenderung ngebuat soal yang susah untuk peserta, hal ini bagus, tapi jangan terlalu berlebihan. Tingkat kesulitan soal yang diperlombakan kira kira baiknya memiliki kurva distribusi normal. Dari pertama gua mulai jadi problem setter, Suhendry pernah bilang kira kira gini, “kontes yang baik itu :
- tiap peserta solve minimal 1 soal
- tidak ada peserta yang solve semua soal
- semua soal di solve minimal oleh 1 tim
Enggak tau dia belajar dari mana, tapi kata – katanya make sense. Selama gua bantu arrange kontes di Binus, judge selalu mikirin tingkat kesulitannya, biasanya Suhendry bakal jadi penyeimbang kalo terlalu banyak soal yang susah, dia bakal bikin soal gampang atau malah soal bonus. Meskipun dalam setiap kontes ga selalu ketiga guideline diatas bisa dipenuhi, intinya adalah harus seimbang tingkat kesulitan soal – soal yang diperlombakan, jangan sampai semua soal terlalu susah sehingga ga ada yang solve dan juga jangan terlalu gampang.
Mengeluarkan set soal yang terlalu sulit semua sehingga peserta tidak bisa solve, tidak akan membuat anda merasa keren, melainkan akan menuai makian dari peserta. Selain itu membuat soal yang terlalu sulit semua rasanya tidak akan memicu peserta untuk menyelesaikan soal itu setelah perlombaan berakhir. Pengalaman mengatakan, soal yang terlalu sulit atau terlalu mudah tidak akan mengajarkan apapun. Shahriar Manzoor, seorang judge World Final ACM ICPC pernah berkomentar tentang hasil suatu kontes regional. Soal di kontes itu tidak jelas deskripsi dan batasannya, namun ada yang menyebut itu “decent” kontes.
Ahem!
A decent problemset do not have some ranges unspecified, or ranges not specified in the input specification (rather than hidden in the problem statement).
A decent problemset and the easiest problems not solved? then how can it be decent?
I have respect to all the teams that has done well in this problemset but don’t call a problemset decent just because u have done well. Many other teams might have ruined their contest on those easy problems (assuming that D and E was not solved).
Meskipun selalu berpegang pada guideline diatas, pernah juga terjadi kontes yang menurut gua kurang baik. Misalnya ada peserta solve semua soal sebelum waktu kelar, terlalu banyak soal menggunakan sorting dalam satu set soal. Hal ini pernah terjadi sebelumnya, dan kita belajar untuk tidak mengulangi hal ini lagi.
Dalam beberapa tahun terakhir ini, makin banyak kontes pemrograman di Indonesia yang umumnya diselenggarakan oleh institusi perguruan tinggi. Hal ini bagus, membuat popularitas kompetisi pemrograman meningkat dan juga membuat iklim kompetisi yang semakin kompetitif. Berita buruknya beberapa kontes masih kurang baik kualitasnya, dan tidak ada peningkatan setelah beberapa tahun.
Salah satu yang cukup banyak terjadi adalah “recycle soal”, yaitu mengambil soal dari internet dan dipakai sebagai soal di kontes pemrograman. Selama gua jadi problem setter hal ini sebisa mungkin dihindari. Namun terkadang soal yang memang orisinil dari pembuatnya, secara tidak sengaja bisa ditemukan di online judge. Gua pernah buat soal untuk BNPC-HS, dan setelah soal approved, gua secara ga sengaja menemukan soal yang sama di lebih dari 1 online judge. Tapi tetep, itu soal masih buatan gua, kebetulan aja sama.