Rust中的所有整数类型都实现了Ord，它强调总排序，而浮点类型只实现了PartialOrd.这意味着可能存在无法比较的浮点值.这似乎很难理解，因为浮点数可以被认为是实数的近似值，而实数恰好是一个完全有序的集合.甚至正负无穷的加法也能使实数集保持完全有序.为什么 Select Rust ？
这个限制意味着一个通用的排序/搜索算法只能假设数字的偏序.IEEE 754标准似乎规定了total ordering predicate.
NaN在泛型代码中有这么多问题吗？
Rust中的所有整数类型都实现了Ord，它强调总排序，而浮点类型只实现了PartialOrd.这意味着可能存在无法比较的浮点值.这似乎很难理解，因为浮点数可以被认为是实数的近似值，而实数恰好是一个完全有序的集合.甚至正负无穷的加法也能使实数集保持完全有序.为什么 Select Rust ？
这个限制意味着一个通用的排序/搜索算法只能假设数字的偏序.IEEE 754标准似乎规定了total ordering predicate.
NaN在泛型代码中有这么多问题吗？
你的问题是什么？你是在问NaN是否存在，还是可以通过意外或自愿计算得到？是的，确实如此，而且可以.当提供的顺序不是总顺序时，需要密钥的总顺序的数据 struct 会完全崩溃.你甚至不希望一个异常值与它本身不同，因为它会 destruct struct 的不变量，意味着从此以后任何事情都可能发生.只要没有问题，NaN就不应该被认为是无害的，尽管that has been tried in other languages.
IEEE 754对普通比较运算符<、<=……的定义使它们在一般情况下非常有用，如果不需要总阶数的话.特别是，很容易写入条件，以便将NaN输入发送到错误分支:
if (!(x <= MAX)) { // NaN makes this condition true
error();
}
if (!(x >= MIN)) { // NaN makes this condition true
error();
}
由于<和<=非常有用，它们是在现代处理器中作为单个快速指令实现的操作.IEEE 754中的totalOrder谓词通常不在硬件中实现.编程语言将快速指令映射到语言中的 struct ，并让任何异常需要totalOrder的人从库中 Select 它，甚至自己定义它.