哪个更快,为什么?

第一个更快

 (n >= 3) && (n <= 99)

它正在做3次手术

 n >= 3
 n <= 99
 and

在哪里作为 elem 正在查找数组中的项,因此执行多达(99-3)*2个操作。

index = 0
isFound = false
array[] = { 3, 4, 5, 6, ... 98, 99 }

while isFound == false
   isFound = (n == array[index++])

(n>=3)amp;&(n<=99)速度更快,因为它只涉及两个微不足道的比较。如果编译器/解释器不进行任何真正的黑魔法优化,它必须构造列表([3..99]),因为不能使用延迟计算(通常在完成之前“拉”下一个值,在这种情况下,它的复杂性为O(n/2)。

这两个表达的意思不一样。一个微妙的区别在于 Ord 另一个在 Enum :

> :t \n -> (n >= 3) && (n <= 99)
\n -> (n >= 3) && (n <= 99) :: (Num a, Ord a) => a -> Bool

> :t \n -> n `elem` [3..99]
\n -> n `elem` [3..99] :: (Num a, Enum a) => a -> Bool

因此,例如,如果n为3.14159,那么第一个测试将通过,但第二个测试不会:

> (pi >= 3) && (pi <= 99)
True

> pi `elem` [3..99]
False

再者,当四首前奏曲 Num 实例(实例) Int , Integer , Float 和 Double )都是两者的实例 奥德 和 枚举 ,可以想象一个数字类型是 奥德 但不是 枚举 . 在这种情况下,第二次测试甚至不合法。

因此,一般来说,编译器不能将第二个优化为与第一个相同的速度,除非它知道对于给定的类型,它是 作战需求文件 范围中的所有有序值也在由创建的列表枚举中 enumFromTo . 为了 浮标 和 双重的 这不是真的,而且 int 和 整数 编译器无法派生它,编译器和库程序员必须手工编写代码,并确保在所有情况下都能保存它。

取决于机器和编译器(或解释器)。