oj上演算法題思路正確,程序也跑的起來,但是為了ac搞幾個小時,這樣有意義嗎?
小弟我並不打算搞acm,只是想提高一下編程能力和演算法思想。為了AC搞了幾個小時真的有意義嗎?
如果一道題你半小時就能AC,說明它對你來說太簡單了。
如果一道題你好幾天都AC不了,說明它對你來說太難了。
需要花幾個小時來AC的題,正是你「跳起來夠得著」的題,做這種題的提高才最大。我一直認為,如果一個題20分鐘就AC了,那這20分鐘就真的算是浪費掉了,因為除了AC時候那一點點快感外,你根本沒有從這20分鐘里得到任何的收穫。
反而,一個題你確定思路是正確的,但是得到的卻不是AC,那麼在幾個小時里你會不停的去調試你的程序,想辦法驗證演算法的正確性,去排查出問題的地方,這個過程對於思維和debug能力都是極大的鍛煉。至少下次碰到類似的問題的時候,你能更加熟練的找到問題的源頭。
工作以後,等老闆跟你說你寫的不對的時候,你總不能回他「不知道解決這種要花幾個小時去查的問題有什麼意義?」。所以啊,反正這個坑遲早要踩下去的,早點踩,這樣真正碰到的時候才能拿出讓人滿意的表現。把代碼寫對根本不算能力,能解決問題才是我現在的感覺是必要的練習是有價值的。
很多人會把理論和實踐割裂起來,認為說看懂了一個書上的證明,對提高自己的「思想」很有幫助,而自己動手切個題,只是讓自己的「碼農熟練度」提升一點。
但是我覺得沒那麼簡單:數學夠「思想」了吧,有時候還是得做一點題才能確保自己理解了書上在講什麼,順暢地把正文從頭過到尾有時候反而並不讓人印象深刻。
自己覺得自己思路正確,程序也跑得起來,卻不能AC,也不能迅速地找個反例把程序調好,這是很可怕的事情。這意味著你對題目的理解,你對演算法的理解,你對自己演算法的正確性的證明(論證本演算法確實能解決本問題),三者很可能掛了一個。
三者掛了任何一個,而自己不能察覺,說明你離你想獲得的「思想」還有不少距離。
如果三者都沒掛,但是你調試就是很沒頭緒的話,也許你需要一些測試和調試的技巧……我就從來不思考這種問題,我都是:
「總算AC了……卧槽,怎麼花了這麼長時間,我還以為只弄了十幾分鐘呢」
「但是我覺得好充實啊!」編寫可以運行的程序和編寫可以正確運行的程序之間的差別在於將來能不能拿編程當飯吃。如果你的程序不能 AC ,何以見得它「思路正確」,編寫這樣的程序何以「提高編程能力和演算法思想」?
有意義。表面上看,花了幾個小時只AC了一道題效率很低,這是由於思路不夠嚴謹,編程能力差導致的。在通往AC的過程中,你的思維水平和編程能力是在逐步提高的,時間短效果不明顯,但如果能持之以恆,堅持下來,編程水平是能夠大幅度提高的。以後寫相對簡單程序的時候,會有如履平地般的輕鬆感。
有一種偶爾可以看見的論調是說,演算法競賽中出現的問題本意就是讓人在數小時內解決的(當然,全場通過的人數可能上百也可能一隻手數的過來),因此必然不會難到哪裡去。這種說法很大程度上當然是有道理的,如果把時間以及其他一些成本放寬(比如放鬆到兩三天)你能很好地比較獨立地解決這些問題的話,這樣想確實沒有大問題。如果不能,別人讓你閉嘴也很正常。
你以為真的是一步之遙?工程上從來沒有一步之遙,只有做到了,或者沒做到。
只驗證題目所給樣例正確,就覺得思路正確,宛如井底之蛙。測評機給您返回結果的意義如下:
TLE 你的演算法在時間複雜度上還有優化的地步WA 你的演算法還存在考慮不周到之處RE 你的演算法存在一定缺陷,導致某些測試數據會使你的程序崩潰MLE 你的演算法在空間複雜度上還有優化的地步能指出您的不足之處,告訴您能比現在做的更好,不算是意義嗎?幾個小時能寫個一兩百行可運行無錯的代碼,還可能用到巧妙的演算法,怎麼會浪費時間呢。debug 比寫出 代碼來難,話說你沒有 debug 的能力,你寫出的代碼又有何用…
簡單題思路正確應該很快就能AC,一直A不了肯定是思路(演算法)有問題,能過樣例只是巧合吧
那種刻意卡常數,卡各種奇怪地方,題目像小說一樣的題,不如看答案.反正下次遇到類似的還是不會(太弱(???︿???)思路也對,程序也跑得起來,但就是AC不了,總是錯幾個點
這不就是說明基本功不過關嗎,還不趕快去練
這幾個小時你可能做的事情:
- 檢查演算法設計思路是否正確,是否可以通過常規的一些測試用例,如何去證明這種解題思路是正確的
- 自己多設計一些測試用例,考慮到各種邊界值情況,比如整型溢出
- 評估演算法的時間複雜度、空間複雜度,並對此進行優化
- 如果程序運行會崩潰,那就要檢查崩潰的原因,是否有數組越界,內存分配不足等情況
- 查閱書籍,搜索相關資料
這些都是編程的硬實力,花費時間去磨練這些技能,我是覺得非常值得的。做什麼就專註去做,尤其做技術,一段時間專攻一個方向是很有必要的。不要老想著有沒有用,能不能用上,不然之後學其他技術你經常會給自己暗示:這個沒用,可學可不學。當這種思想延伸到:數據結構都封裝好了,沒用。jvm平時寫程序也不用,遇到問題就只能懵逼等待別人的尷尬境地。
————————
說了這麼多形而上的,就問題本身來說,比如你努力ac的時候可能是邊界的case不過,這個對你思維有用的,比如很多校招面試喜歡讓人寫:字元串轉數字,思維縝密的人顯然更容易寫出健壯性更好的程序來。如果演算法問題,思考的方向不對,那認識到人和人的差距比人和狗的差距大也是很有收穫的嘛。(抖個機靈)沒有AC的題目你跟我說思路正確,代碼可以跑?我覺得你僅僅只是要個借口罷了!ヽ(#`Д′)ノ
數年前我看到道題幾天前我AC了有沒有意義...別人說了不算,只有我說了算
思路正確,程序能跑卻不AC。你猜你的程序和AC的差在哪?
換到工程上就是,給你一個任務,你發現你思路正確,編譯運行和最簡單用例可以跑通,但是上線發現,誒,性能為啥有問題,誒,為啥其他模塊加了你代碼突然老coredump。
你不是做研究的,你是寫代碼的
說真的,,,理論上正確的演算法並沒有非要去碼出來的必要,可以證明就好了。。。
但是,你不覺得,無論用多久,AC之後,,,真的很爽喵?推薦閱讀:
※n鐵球稱重問題(12個鐵球3次找出壞的擴展)?
※存在不失真圖片放大演算法嗎?
※如何提升自己的編程能力(特指演算法等方面)?
※現今人工智慧,機器學習領域研究的困難主要有哪些?