作業要求：https://edu.cnblogs.com/campus/ustc/InnovatingLeadersClass/homework/2231

原始碼地址：https://github.com/YueshangGu/golden-number

黃金點遊戲簡單介紹

假設有M個人參與黃金點遊戲，每輪遊戲每個人提兩個(0, 100)間的有理數，共2M個數，求這2M個數的平均數再將這個平均數乘以0.618得到這一輪的黃金點，提出離黃金點最近的數的人得2M分（同樣近的人一起得分），離黃金點最遠的人扣兩分。

在本次實驗中，我們需要寫一個bot來在每輪遊戲中自動提出兩個數，每次遊戲前，bot能拿到之前所有輪次遊戲的每個人提的兩個數和黃金點，每場遊戲共進行400輪，共有上半場和下半場兩場遊戲，累計得分最高的bot獲勝。

我們的策略介紹

我們放棄了預測每一個對手的輸出和使用強化學習等複雜演算法的方案。相反，我們使用簡單的統計策略，利用前n局的黃金點的資訊，對當前黃金點進行預測。我們採用一個佇列，對前n局的黃金點資訊進行統計，並且根據一定的劃分和更新策略，我們可以得到m(\(m \leq n\))個黃金點，然後我們根據佇列中概率最大的兩個黃金點進行輸出。

PSP表格記錄預估時間

我們的專案開始時，並沒有考慮利用PSP表格預估時間，在後面的實驗中，我們會改善此方面。

介面設計

由於我們的bot僅僅只需要一個前n個黃金點的統計佇列，以及待選黃金點的更新列表，所以我們預打算一個函式實現所有功能，根據當前history資訊，返回插入和更新後的待預測黃金點列表和近50輪的統計佇列。主函式根據返回的資訊進行輸出。

介面實現

我們的程式功能十分簡單，只有兩個函式，沒有class，所以並不需要流程圖的表示。另外在設計的過程中，我們的演算法考慮到了存在少數人搗亂的情況，可以去預測兩個黃金點的極限值。另外對於大家更改策略的行為，我們的佇列也能夠很快的得以適應。

UML圖

僅有2個函式，沒有類，沒有實體，所有並不需要UML圖的表示。

Design by Contract

• DbC的優缺點
  • 優點在於程式碼除錯很簡單，每一個過程的行為意圖都定義的非常清楚，且不能夠被違反。另外因為關於程式碼實現的契約已經文件化，所有有利於程式碼重用。
  • 缺點在於實現程式碼之前，會花費很大的時間和精力，去商討程式碼契約，規則較強，可能後期根據實際情況也需要修改。
• 我們方法中的體現
  我們在這次程式設計的任務中，由於任務比較簡單，關於介面的交流較少，所以並沒有採用這種設計方式。

結對共識

我們分工合作，在程式設計之前就已經互相商量了應該傳入的引數和返回的結果，採用簡單的註釋，我們便達到了共識。在程式設計中沒有遇到異常。

UI模組

我們並沒有UI模組，所以並沒有UI模組的設計和其他模組之間的對接部分。

結對過程

我們的結對過程非常的愉快，在合作中我們互相學習，共同的進步。

下面是我們正在討論的過程。。。

結對小夥伴

我們在結對過程中，採取的是駕駛員和領航員靈活的合作方式。通過指導監督和執行的交替合作，我們獲得了更好的合作體驗。

• 結對程式設計的優缺點
  • 結對程式設計有助於雙方互相學習對方的優點，為合作提供更好的程式碼質量和設計質量。
  • 合作雙方有更大的積極性，能夠參與到合作中。
  • 有的時候，會出現雙方互相甩鍋的情況，會使得合作的效率大大降低。
• 合作伙伴的評價
  • 我的合作伙伴Kai Hu，是一個非常積極聰明的小夥伴。在討論階段，能夠提出非常creative的idea，在程式碼實現時，也能夠首先承擔起coding的責任，且能夠在整個過程中不斷的提出非常有意思的改進的意見，所以沒有缺點:)

實際花費時間

這個在我們的實際過程中並沒有記錄，所以無法進行對比。

其他收穫

在這次的比賽中，我們的方法比較簡單，主要是我們擔心複雜的演算法會花費我們較大的時間精力，最後結果也不是很好。所以了，一分耕耘一分收穫，沒有付出，就沒有回報。在以後的作業中，我們會認真的對待。