單元 2.1 計算思維的要素
< A-level 計算機 | OCR
- 抽象 – 將思想與這些思想在工作中的具體例項分離的過程。計算結構由其含義定義，同時隱藏了它們如何工作的細節。抽象試圖從通用模式中提取細節，以便程式設計師可以在接近人類思想的水平上工作，忽略在實踐中很重要但與要解決的問題無關的細節。
- 抽象模型 – 任何從現實生活情況或問題中提取或基於（抽象）的系統模型。
- 遞迴 – 一種高階程式設計結構，其中程式碼塊（通常是函式）能夠呼叫自身。遞迴演算法必須仔細設計，以便滿足終止條件。
- 函式 – 在程式中賦予唯一可識別名稱的程式碼塊。函式在被呼叫時可以接受 0 個或多個引數，並且應該返回一個值。該函式應該被設計和編寫為執行一項任務或操作，該任務或操作由其名稱清楚地指示。
- 引數 – 在程式或函式最初被呼叫時傳遞給它的資料結構。
- 按值傳遞 – 如果一個引數按值傳遞，則子程式中使用的是資料的副本，該副本在子程式退出時被丟棄。
- 按引用傳遞 – 如果一個引數按引用傳遞，則使用的是變數的位置（在記憶體中）。這意味著任何更改都會影響主程式中的變數，因此在子程式退出後會保留。
- 併發處理 – 在系統設計或程式設計中，當您希望同時發生多件事時，任何情況。
- 流水線 – 同時解碼兩個或多個機器指令。當第一個指令的一部分（例如地址欄位）被解碼時，第二個指令的另一部分（例如操作碼）也可以被解碼。
- 分解 – 將問題分解成更小的、更容易解決的部分。較小的部分有時可以遞迴地解決 → 一遍又一遍地解決，直到問題得到解決。
- 面向物件程式設計 – 一個由相互互動的物件組成的程式。例如 Java。
- 相容性 – 問題是否可以用演算法解決。
- 速度 – 限制因素。隨著更大功率的可用，我們可以使用計算機解決更多問題。
- 解決問題是人機之間的合作。
- 有些問題永遠無法由計算機解決。
問題識別
- 首先識別問題很重要
- 使用計算和直覺方法，可能能夠找到解決方案
回溯
一種解決問題的演算法方法，其中問題的部分解決方案被構建為一條路徑 → 如果路徑在某一點失敗，搜尋將從最後一個潛在的成功點開始。
資料探勘
- 遍歷大量可能來自多個來源的資料
- 對搜尋對偶然觀察者來說並不明顯的聯絡和事實很有用。
- 當資料來自未以相同方式結構化的資料集時使用。
- 例如，超市會員卡計劃。
- 執行搜尋以嘗試查詢模式。
- 將顯示是否某些產品一起被同一個人或同一人口統計群體購買。
- 有助於解決問題的演算法被稱為“模式匹配”或“異常檢測”。
資料探勘之所以成為可能，是因為
- 大型資料庫
- 更快的處理
流水線
- "當一條指令被獲取時，之前的指令被解碼，再之前的指令被執行，所有這些都同時發生"
- 一個過程的輸出是另一個過程的輸入
- 在 RISC 結構中很有用。
視覺化解決問題
- 以易於理解的形式呈現資料。
- 最簡單 → 將表格資料作為圖表呈現
- 可以使以前未被注意的事實和趨勢變得顯而易見。
- 抽象是一個現實概念。
- 通常使用符號來代表問題的組成部分，以便人類思維或計算代理可以處理該問題。
- 關於找出在一個場景中什麼重要，什麼不重要。
- 透過讓我們分離出元件並決定哪些重要，它有助於最大限度地提高我們解決問題的可能性。
抽象與現實世界問題
- 沒有抽象，使用計算機來解決現實世界的問題是不可能的。
- 變數是抽象的。它們代表計算中的現實世界值或中間值。
抽象層次
- 在一個複雜系統中，通常使用抽象來表示一個大問題並建立更低階的抽象來處理元件部分。
- 這種方法的強大之處在於，每個抽象層中的細節都可以對其他層隱藏起來。
- 解放了解決過程，可以專注於一次解決一個問題，或者將不同的子問題傳送給不同的員工或不同的公司來處理。
- 分層廣泛存在於任何大型系統的構建中。
- 層是將系統功能劃分為單獨區域的一種方式。
- 相同的原則可以應用於物理物品（例如汽車）。
計算機科學家在編寫系統時，會
- 確定所需的輸出
- 確定實現輸出所需的必要操作
- 確定防止程式崩潰的任何先決條件
- 考慮所需的資源
- 考慮使用者的期望
任何人都可以使用這些策略來
- 決定要實現什麼
- 確定先決條件
- 確定什麼是可能的
計算機示例：快取
人類示例：想要成為計算機專業人士的人需要確定
- 在 A 級別學習的科目
- 在所選 A 級別科目中獲得的分數
- 他們有什麼能力
- 他們需要投入多少工作
- 技能集的潛在需求 – 現在和將來
預取
- 預期的指令在需要之前被獲取並放置在快取中，可以從中快速獲取，因此訪問速度較慢的 RAM 時不會出現延遲。
對可重用程式元件的需求
- 從商業角度和支援未來發展的工具角度來看都很重要
- 大多數系統都是透過組合在其他系統中使用過的現有元件來設計的
- 在軟體中越來越受歡迎。
好處
- 提高可靠性 – 比新軟體更可靠（錯誤和故障已經確定）
- 降低過程風險 – 現有軟體的成本已知，而開發成本是判斷問題。
- 有效利用專家 – 避免專家重複做相同的工作。可以開發封裝他們知識的可重用軟體。
- 符合標準 – 一些標準（例如使用者介面標準）可以實現為一組可重用元件。可以用來確保所有應用程式都具有相同的選單格式。
- 加速開發 – 可以加快系統生產，因為開發和驗證時間可以減少。
缺點
- 維護成本增加 – 由於可重用元件與系統更改可能不相容，因此維護成本可能更高。
- 缺乏工具支援 – 不支援開發重用。將這些工具與計算機庫系統整合可能很困難。
- 非我所創系統 – 寧願重新編寫，因為他們可以改進它們。
- 建立、維護和使用元件庫 – 填充庫並確保開發人員知道如何使用庫可能很昂貴。已經開發出流程來確保庫的使用。
- 查詢、理解和調整可重用元件 – 必須在庫中發現可重用元件，並理解和調整以適應新環境。
示例 – NASA 如何在新視野號任務中超前思考？
- 他們如何在無人值守的情況下維護裝置。
- 成本與回報
- 他們將如何為其供電？
- 他們將如何將資訊傳回地球？他們如何收集資訊？
- 需要多長時間？速度
- 飛越任務還是軌道任務？
- 潛在的未知因素
- 需要什麼裝置
- 未來的潛在任務
快取
- 輸入的資料可能會儲存在 RAM 中，以備在程序關閉之前再次需要時使用。
- 如果需要，它不需要從磁碟再次讀取 → 建立更快的響應時間。
- 預取 → 在指令需要之前從記憶體中請求指令，以加快處理速度。
優點
- 可以減少網路伺服器的負載，因為可以預測所需的資料
缺點
- 實現起來可能很複雜
- 如果快取了錯誤的資料，則很難重新建立正確的資料序列。
輸入和輸出
- 分析師首先要做的事情之一就是確定需要哪些輸出。
- 系統的設計者需要確保在需要的時候有正確的輸入，以確保能夠實現輸出。
關於分解 → 用於使問題更易於管理。
- 任何大型問題都被分解成更小的子問題。
- 最終它們將等同於一個程式模組或一組模組。
- 需要考慮執行順序 - 可能需要在一個模組處理資料，然後另一個模組才能使用它。
- 有些需要以不可預測的方式訪問。
- 大型人類專案也受益於同樣的方法（例如建造房屋）。
順序
- 在規劃解決方案時，順序可能重要也可能不重要。
- 事件驅動的場景 - 順序可能不可預測。
- 在其他情況下，順序可能很重要，因為有時你無法完成一項任務，除非先完成另一項任務。
.
在規劃程式時，識別決策點是程式設計的關鍵部分。可以使用虛擬碼、結構化語句或流程圖進行規劃。
大多數現代計算機可以同時處理多個指令（得益於多核處理器和流水線技術）。
- 這意味著程式需要專門設計以利用這一點。
- 同時處理的模組應該是獨立的。
- 設計良好的程式可以節省大量的處理時間。
- 人類活動也從中受益。
- 甘特圖通常用於視覺化同時進行的專案。
並行處理器
- 使程式的不同部分能夠同時執行。
- 多核處理器也變得越來越普遍。
- 潛在優勢 → 程式執行速度更快，並節省能源。
- 程式必須專門編寫以利用並行處理，這可能使它們更長、更復雜。
- 如果指令必須按順序執行，則可能不會節省太多時間。