為什么 Rust 不通過 f64 和 f32 的 Ord 特征實現全排序？

Question

雖然 Rust 中的所有整數類型都實現了強調全序的Ord ，但浮點類型只實現PartialOrd 。 這意味着可能存在無法比較的浮點值。 這似乎很難消化，因為浮點數可以被認為是對實數的近似，而實數恰好是一個完全有序的集合。 即使加上正無窮和負無窮，也能保持實數集完全有序。 為什么在 Rust 中有這個奇怪的選擇？

此限制意味着通用排序/搜索算法只能假設對數字進行部分排序。 IEEE 754 標准似乎提供了一個總排序謂詞。

泛型代碼中的 NaN 有這么大的問題嗎？

Answer 1

你的問題究竟是什么？ 您是在詢問是否存在NaN，或者是否可以通過意外或自願計算獲得NaN？ 是的，它確實可以。 當提供的訂單不是總訂單時，需要總訂單的數據結構完全分解。 你甚至不希望一個特殊的價值與它本身不同，因為它會打破結構的不變量，並意味着今后任何事情都可能發生。 只要沒有出現任何問題，NaN就不應該被認為是無害的，盡管已經在其他語言中嘗試過 。

IEEE 754對普通比較運算符< ， <= ，...的定義使它們在一般情況下非常有用 - 如果不需要總訂單的話。 特別是，很容易編寫條件，以便將NaN輸入發送到錯誤分支：

if (!(x <= MAX)) { // NaN makes this condition true
  error();
}

if (!(x >= MIN)) { // NaN makes this condition true
  error();
}

因為<和<=非常有用，所以它們是在現代處理器中作為單個快速指令實現的操作 - 來自IEEE 754的totalOrder謂詞通常不在硬件中實現。 編程語言將快速指令映射到語言中的構造，並讓異常需要totalOrder的任何人從庫中選擇它，甚至自己定義它。

Answer 2

它不能，因為 Rust 的核心設計錯誤是讓Ord成為PartialOrd的子類型。

這意味着盡管浮點值具有總順序，但該層次結構中只能有一個實現； 並且該實現使用比較謂詞（僅是部分順序），而不是全順序謂詞（這是全順序（因此也是部分順序））。

如果Ord和PartialOrd不相關，那么實現 IEEE754 規范中的 5.10 和 5.11 將是微不足道的——但因為它們不是——Rust 必須選擇一個，它選擇了 5.11。

---

很容易想象一種不同的設計，例如， Sortable提供 5.10， Comparable提供 5.11，並且類型在適當的時候實現了這兩者。

然后，如果用戶需要全序，則可以寫Sortable ，如果需要偏序，則可以寫Comparable 。