Haskell中的Floating,Ord和RealFloat

时间:2021-09-03 17:04:42

I'm trying to figure out why this does not compile

我试图找出为什么这不编译

yell :: (Floating a) => a -> [Char]
yell x
    | x > 10.0 = "Yelling"
    | otherwise = "No Yell"

but this

yell :: (Floating a, Ord a) => a -> [Char]
yell x
    | x > 10.0 = "Yelling"
    | otherwise = "No Yell"

and this

yell :: (RealFloat a) => a -> [Char]
yell x
    | x > 10.0 = "Yelling"
    | otherwise = "No Yell"

do compile.

I know that Floating and Ord are typeclasses, but isn't every member of Floating also a member of Ord? And in the end, is RealFloat just a "inner join" of Floating and Ord?

我知道Floating和Ord是类型类,但并不是每个浮动的成员也是Ord的成员?最后,RealFloat只是Floating和Ord的“内部联接”吗?

2 个解决方案

#1


but isn't every member of Floating also a member of Ord?

但浮动的每个成员都不是奥德的成员吗?

The obvious counterexample are complex numbers. Also, some types that give good Num etc. instances don't allow equality or inequality comparisons at all, because they represent more than just a single number value, but e.g. a generic abstraction over function results of some number type. (That's why Eq is not a superclass of Num, though it used to be.)

显而易见的反例是复数。此外,一些提供良好Num等实例的类型根本不允许相等或不等式比较,因为它们不仅仅代表单个数字值,而且例如某种数字类型的函数结果的通用抽象。 (这就是为什么Eq不是Num的超类,虽然它曾经是。)

in the end, is RealFloat just a "inner join" of Floating and Ord?

最后,RealFloat只是Floating和Ord的“内部联接”吗?

Pretty much, though Real, RealFrac and RealFloat actually contain a lot of very specific convenience methods – but I think you could implement them all (albeit much less efficiently) with just a (Floating a, Ord a) constraint.

虽然Real,RealFrac和RealFloat实际上包含了许多非常具体的便利方法 - 但我认为你可以只用一个(浮动a,Ord a)约束来实现它们(尽管效率低得多)。

#2


Let's see definition of Floating typeclass. I think it's just defined as something that guarantees that the following functions can be used with it:

我们来看看Floating类型类的定义。我认为它只是定义为保证以下功能可以使用的东西:

pi, exp, log, sin, cos, asin, acos, atan, sinh, cosh, asinh, acosh, atanh

pi,exp,log,sin,cos,asin,acos,atan,sinh,cosh,asinh,acosh,atanh

None of them requires its argument to be instance of Ord, so it's not. On the other hand Real is an instance of Ord and so is RealFloat.

他们都不要求它的论点是Ord的实例,所以事实并非如此。另一方面,Real是Ord的一个实例,RealFloat也是如此。

#1


but isn't every member of Floating also a member of Ord?

但浮动的每个成员都不是奥德的成员吗?

The obvious counterexample are complex numbers. Also, some types that give good Num etc. instances don't allow equality or inequality comparisons at all, because they represent more than just a single number value, but e.g. a generic abstraction over function results of some number type. (That's why Eq is not a superclass of Num, though it used to be.)

显而易见的反例是复数。此外,一些提供良好Num等实例的类型根本不允许相等或不等式比较,因为它们不仅仅代表单个数字值,而且例如某种数字类型的函数结果的通用抽象。 (这就是为什么Eq不是Num的超类,虽然它曾经是。)

in the end, is RealFloat just a "inner join" of Floating and Ord?

最后,RealFloat只是Floating和Ord的“内部联接”吗?

Pretty much, though Real, RealFrac and RealFloat actually contain a lot of very specific convenience methods – but I think you could implement them all (albeit much less efficiently) with just a (Floating a, Ord a) constraint.

虽然Real,RealFrac和RealFloat实际上包含了许多非常具体的便利方法 - 但我认为你可以只用一个(浮动a,Ord a)约束来实现它们(尽管效率低得多)。

#2


Let's see definition of Floating typeclass. I think it's just defined as something that guarantees that the following functions can be used with it:

我们来看看Floating类型类的定义。我认为它只是定义为保证以下功能可以使用的东西:

pi, exp, log, sin, cos, asin, acos, atan, sinh, cosh, asinh, acosh, atanh

pi,exp,log,sin,cos,asin,acos,atan,sinh,cosh,asinh,acosh,atanh

None of them requires its argument to be instance of Ord, so it's not. On the other hand Real is an instance of Ord and so is RealFloat.

他们都不要求它的论点是Ord的实例,所以事实并非如此。另一方面,Real是Ord的一个实例,RealFloat也是如此。