國際象棋作為可計算數據

我們使用Wolfram 語言的目標是使盡可能多的可計算性。版本13.2 添加了另一個域- 國際象棋 -支持導入 FEN和 PGN 國際象棋格式：

PGN文件通常包含許多游戲，每個游戲都表示為FEN字符串的列表。這將計算特定PGN文件中的游戲數量：

這是文件中的第一個游戲：

鑒于此，我們現在可以使用Wolfram 語言的視頻功能來制作游戲視頻：

控制失控計算

早在1979 年，當我開始構建SMP（Wolfram語言的前身）時，我做了一件對某些人來說似乎非常大膽，甚至可能是魯莽的事情：我建立系統從根本上進行“無限評估”，也就是說，繼續使用任何給定的定義，直到無能為力。換言之，評價過程將一直持續到達到一個固定點。“但是如果x沒有值，你說x= x + 1會發生什么？”人們會問?！澳菢拥脑?，系統不會爆炸嗎？”嗯，從某種意義上說是的。但我賭了一把，人們真正想做的對普通計算進行無限評估的好處將遠遠超過任何看似“毫無意義的極端情況”（如x = x + 1）可能出現的問題。好吧，43年后，我想我可以自信地說，那場賭博成功了。無限評估的概念- 結合 Wolfram語言的符號結構 -一直是巨大力量的源泉，大多數用戶根本就沒有遇到過，也永遠不必考慮x = x + 1 的“極端情況”。

但是，如果您鍵入x = x +1，則系統顯然必須執行某些操作。從某種意義上說，最純粹的事情就是永遠繼續計算。但是34年前，這導致了實際計算機上的災難性問題-事實上今天仍然如此。因為一般來說，這種重復評估是一個遞歸過程，最終必須使用操作系統為每個程序實例設置的調用堆棧來實現。但是操作系統的工作方式（仍然?。┦菫槎褩Ｖ环峙涔潭〝盗康膬却? 如果這被溢出，操作系統只會讓你的程序崩潰（或者，在早期，操作系統本身可能會崩潰）。這意味著從版本1 開始，我們就需要在無限評估方面有一個限制。在早期版本中，我們試圖給出“到目前為止的計算結果”，包裝在Hold 中?；氐桨姹?0，我們開始只返回原始表達式的保留版本：

但即使這樣在某種意義上也不安全。因為有了其他無限的定義，人們最終可能會遇到這樣一種情況：即使試圖返回持有的形式也會觸發額外的無限計算過程。

最近，特別是隨著我們對多計算的探索，我們決定重新審視如何限制無限計算的問題。在某個理論層面上，人們可以想象使用超限數之類的東西明確表示無限計算。但這充滿了困難，并且具有明顯的不可判定性（“這個無限計算輸出真的和那個一樣嗎？”等）。但是在版本13.2 中，作為一種新的“純符號”“失控計算”方法的開始，我們引入了構造TerminatedEvaluation——正如它所說，它只是象征性地表示終止計算。

所以這是現在x = x + 1 發生的情況：

這樣做的一個顯著特征是它是“獨立封裝的”：計算的一部分的終止不會影響其他部分，因此，例如，我們得到：

終止評估和延遲評估之間存在復雜的關系，我們正在開發該領域一些有趣且可能強大的新功能。但就目前而言，終止評估是在計算失控的極端情況下提高系統“安全性”的重要結構。引入它使我們能夠解決多年來圍繞復雜失控計算的“理論上無法解決”的問題。

終止評估是如果您遇到像$RecursionLimit這樣的系統范圍的“護欄”，您會遇到的情況。但在版本13.2 中，我們還加強了對顯式請求中止的處理— 通過將新選項“PropagateAborts 添加到CheckAbort”。一旦生成了中止（直接使用Abort[ ]），或者由于TimeConstrained[ ] 或MemoryConstrained[]之類的結果生成了中止，就會出現中止應該傳播多遠的問題。默認情況下，它會一直向上傳播，因此您的整個計算最終將被中止。但是從版本2（1991年）開始，我們就有了函數CheckAbort，它檢查給定表達式中的中止，然后停止中止的進一步傳播。

但是在諸如時間約束[]之類的問題上總是有很多棘手之處。由這些生成的中止是否應該以與中止[] 中止相同的方式傳播？在版本13.2 中，我們現在已經清理了所有這些，并使用顯式選項PropagateAborts forCheckAbort。使用PropagateAborts→True，所有中止都會被傳播，無論是由Abort[]還是TimeCompated[]或其他什么啟動。傳播中止→錯誤傳播不中止。但也有PropagateAborts→Automatic，它從TimeConstrained[]等傳播中止，但不從Abort[]傳播中止。

另一個小列表函數

在我們永無止境的擴展和完善Wolfram語言的過程中，我們一直在尋找人們反復想要做的“大量計算工作”，我們可以為此創建具有易于理解的名稱的函數。如今，我們經常在Wolfram 函數存儲庫中對此類函數進行原型設計，然后進一步簡化其設計， 并最終在永久核心 Wolfram語言中實現它們.在版本13.2 中，此過程只產生了兩個新的基本列表操作函數：PositionGreatest和 PositionSmallest。

自版本1 以來，我們一直擁有Position 函數，以及Max。但多年來，我經常發現自己需要做的事情是將這些結合起來來回答這個問題：“這個列表的最大值在哪里？當然，在Wolfram 語言中做到這一點并不難——Position[list，Max[list]]基本上就是這樣做的。但是有一些邊緣情況和擴展需要考慮，只有一個函數來做到這一點很方便。而且，更重要的是，現在我們有了像TakeLargest這樣的函數，這個函數有一個明顯的、一致的名稱：PositionLargest。（我所說的“顯而易見”，是指你聽完之后顯而易見;我們直播的設計評審會議的檔案會揭示——就像經常發生的情況一樣——我們實際上花了相當長的時間才確定“顯而易見”。

這是位置最大和在行動：

而且，是的，它必須返回一個列表來處理“關系”：

審核編輯 ：李倩