如上，但風險自負。
所謂風險，包含：
1. 少數題目曾加強測資，因為測資修改時不會對已經 AC 的 code 進行重測，如果您的程式沒有考慮完整，有可能重測後變錯誤。
2. 早期(2007年底之前)送出的程式碼重測後，執行時間會縮短，是因為早期時間計算方式不同。若是近期送出的程式碼，就不見得會變快，還可能變慢，因為部分測資增加，系統的負載也升高，都會增加執行時間。
如上，但風險自負。
所謂風險，包含：
1. 少數題目曾加強測資，因為測資修改時不會對已經 AC 的 code 進行重測，如果您的程式沒有考慮完整，有可能重測後變錯誤。
2. 早期(2007年底之前)送出的程式碼重測後，執行時間會縮短，是因為早期時間計算方式不同。若是近期送出的程式碼，就不見得會變快，還可能變慢，因為部分測資增加，系統的負載也升高，都會增加執行時間。
如上，但風險自負。
所謂風險，包含：
1. 少數題目曾加強測資，因為測資修改時不會對已經 AC 的 code 進行重測，如果您的程式沒有考慮完整，有可能重測後變錯誤。
2. 早期(2007年底之前)送出的程式碼重測後，執行時間會縮短，是因為早期時間計算方式不同。若是近期送出的程式碼，就不見得會變快，還可能變慢，因為部分測資增加，系統的負載也升高，都會增加執行時間。
嗯.... 不好意思，暫時沒有這樣的規劃 :)
這部分考慮到所有的 judge 都是在 queue 裡排隊
如果有這樣的功能，很可能一瞬間會有上百個 judge 進入排隊(如果你解了上百個題目)
這時如果有人送出了一個 code 那得等很久才會 judge 到...所以我認為不妥... :)