經典演算法不一定就是效能最好的演算法
阿新 • • 發佈:2021-02-02
最近在學習go語言,碰到了一個例子,就動手做一做了。
題目:實現一個fibonacci
函式,它返回一個函式(閉包),該閉包返回一個斐波納契數列`(0, 1, 1, 2, 3, 5, ...)`。
也許對於熟悉演算法的小夥伴來說,這個題很簡單,但是我這個沒怎麼學過的人還是花了大半個小時才琢磨出一個演算法的實現:
package main import "fmt" func fibonacci() func() int { var x, y , z = 0, 0, 0 return func() int { var sun int if z < 2 { sun = x + y + z x = y y = sun } else { sun = x + y x = y y = sun } z++ return sun } } func main() { f := fibonacci() for i := 0; i < 10; i++ { fmt.Println(f()) } }
我知道網上有現成的演算法,所以上網搜一下到底是怎麼實現的,然後我就知道自己有多low了
看完就想起來以前看過類似的演算法了,對比自己寫的演算法,感覺真的有點low。
重新對照這個定義寫了一個:
package main import "fmt" func fibonacci() func() int { var index int return func() int { result := count(index) index ++ return result } } func count(num int) int{ var sun int switch num { case 0: sun = 0 case 1: sun = 1 default: sun = count(num - 1) + count(num -2) } return sun } func main() { f := fibonacci2() for i := 0; i < 10; i++ { fmt.Println(f()) } }
也許寫得不完美,但是畢竟剛開始學習go嗎,所以原諒自己了。
然後習慣性的把main函式中的i改成100,測試一下,發現竟然沒有想象的那樣直接一堆結果出來,越到後面,結果出來的越慢。
然後我切換到自己寫的演算法,測試這種情況,結果一執行就出來了。
為什麼會發生這樣的事呢?其實遞迴呼叫,如果次數越多消耗的效能是越大的;而我的演算法由於儲存了前兩步的結果,所以計算速度並不會因為資料的“增大”而影響效能。
突然意識到,原來所謂的那些“標準”演算法,對於計算機應用來說並不一定是效能最佳的。
記錄下來這次的“意外”,以此警示自己。