Yampa交换机有一些图表：
http://www.haskell.org/haskellwiki/Yampa/switch
http://www.haskell.org/haskellwiki/Yampa/rSwitch
http://www.haskell.org/haskellwiki/Yampa/kSwitch
（等等）。
我发现switch是唯一一个有描述的图表，是最容易理解的。 其他人似乎很难按照类似的符号来阅读图表。 例如，尝试使用switch使用的符号读取rSwitch可能是：
是一个递归SF，总是输入一个'in'类型的信号，并返回一个'out'类型的信号。 从相同类型的初始SF开始，但是切换功能之外的某个人（？[cond]）square）也可以通过事件（签名处的类型Event (SF in out)传递新的SF，而条件是满意（对于[cond] square之前的'？'）。 在事件的情况下，Yampa将使用新的SF而不是现有的SF。 这个过程是递归的，因为'？' （除了rSwitch的签名似乎是递归的，否则无法从图中获取它）。
在我查看rSwitch的源代码rSwitch ，看起来它在切换t时使用switch来递归切换到相同的init SF（根据图中所描述的，虽然我没有看到特殊的t是什么在源代码中解雇）。
在Yampa Arcade中，它用代码和示例解释了dpSwitch 。 关于游戏'Frag'的论文也使用了dpSwitch 。 但是这些教程中似乎没有rSwitch 。 所以我真的不知道如何使用r-或k-串行开关，以及在什么情况下我们需要它们。
There is some diagrams of Yampa switches at:
http://www.haskell.org/haskellwiki/Yampa/switch
http://www.haskell.org/haskellwiki/Yampa/rSwitch
http://www.haskell.org/haskellwiki/Yampa/kSwitch
(and so on).
I've found that the switch, the only one diagram with description, is the easiest one to get understand. The others seems hard to follow the similar symbols to read the diagrams. For example, to try to read the rSwitch with the symbols used in the switch may be:
Be a recursive SF which is always fed a signal of type 'in' and returns a signal of type 'out'. Start with an initial SF of the same type but someone outside the switch function (the ?[cond]) square) may also pass a new SF via an Event (the type Event (SF in out) at the signature) while the condition is satisfied (for the '?' before the [cond] square). In case of the Event, Yampa would use the new SF instead of the existing one. This process is recursive since '?' (can't get it from the diagram except the signature of the rSwitch seems recursive).
And after I look into the source of rSwitch, it looks like it use switch to switch to the same init SF recursively while the t is fired (according to what described in the diagram, although I don't see what the special t would be fired in the source code).
In the Yampa Arcade it explains the dpSwitch with the code and example. And the paper about the game 'Frag' also uses dpSwitch. However the rSwitch seems absent in these tutorial. So I really don't know how to use r- or the k-serial switches, and in what cases we would need them.
最满意答案
所有switch功能都是将信号功能改变为另一种信号功能的方法。 我个人觉得Yampa图有点难以解析，但各种开关的类型签名给出了如何理解它们的良好指示。 一旦理解了类型签名，图表就会变得更加清晰。 switch本身是最基本的：
switch :: SF a (b, Event c) -> (c -> SF a b) -> SF a b如果我们查看类型，它会告诉我们它的确切作用：它需要SF sf和SF生成器sfg 。 sf产生类型(b, Event c) ，并且信号函数发生器的输入也恰好是c类型。 因此，每当发生sf事件时，SF将切换到SF发生器的结果。 在事件发生之前，生成的SF将返回原始SF的值。
这个想法也用于rswitch和kswitch变体，但有点不同。
rswitch ：这被称为“外部开关”，意味着SF将在不对其输入或输出进行任何分析的情况下进行切换。 我们来看一下类型签名：
rswitch :: SF a b -> SF (a, Event (SF a b)) b它需要一个SF作为类型a输入值并输出类型b值。 rswitch创建一个新的SF，它也产生输出b ，但需要一个类型为Event (SF ab)的附加输入。 请注意，Event值的类型与输入类型匹配。 这意味着每当事件发生时，此SF将切换到该事件值。 但是，SF的类型仍然是SF (a, Event (SF ab)) b 。 这意味着SF可以自由地接收具有新SF的附加事件，这将影响整个SF的行为。 一个用途可能是游戏中的AI行为：
moveFollowTarget :: SF TargetPosition Velocity moveShootTarget :: SF TargetPosition Velocity moveIdle :: SF TargetPosition Velocity aiMovement :: SF (TargetPosition, Event (SF TargetPosition Velocity)) Velocity aiMovement = rswitch moveIdle -- Initially idle... aiMovementManager :: SF a (Event (SF TargetPosition Velocity)) aiMovementManager = ... whatever ...这里，只要AI的移动行为需要改变， aiMovementManager就会触发事件，并且事件的值将是移动应该改变的SF。
kswitch ：这被称为intrinsic switch ，因为SF的内容被分析以确定正确的开关应该是什么。 让我们回顾一下类型签名
kswitch :: SF a b -> SF (a, b) (Event c) -> (SF a b -> c -> SF a b) -> SF a b在这里， kswitch有三个参数， sf ， analyzer和mapping 。 sf只是一个标准SF，输入类型为a ，输出类型为b 。 sf是信号最初的表现方式。 analyzer是一个SF，它接受sf的输入和输出，可能会或可能不会触发某些值为c的事件。 如果它没有触发事件，那么没有任何反应，SF继续表现得像sf 。 如果它确实触发了一个事件，那么sf和事件值都会传递给mapping ， mapping确定要切换到的新SF。 在根据输出更改系统行为的方式时， kswitch非常有用。
这有用的一个例子是TCP拥塞避免的算法。 在这里，我们看看我们是否丢失了网络数据包，并提高或降低了我们请求数据的速度。
All of the switch functions are ways to change a signal function to behave like another signal function. I personally find the Yampa diagrams to be somewhat difficult to parse, but the type signatures of the various switches give good indication for how to understand them. Once you understand the type signatures, the diagrams become much clearer. switch itself is the most basic:
switch :: SF a (b, Event c) -> (c -> SF a b) -> SF a bIf we look at the type, it tells us exactly what it does: It takes a SF sf and a SF generator sfg. sf produces values of type (b, Event c), and the input to the signal function generator happens to also be of type c. So, whenever sf's event occurs, the SF will switch to the result of the SF generator. Until an event occurs, the resulting SF will return the value of the original SF.
This idea is also used in the rswitch and kswitch variants but a bit differently.
rswitch : This is known as an "extrinsic switch", meaning that the SF will switch without any analysis of its input or output. Let's look at the type signature:
rswitch :: SF a b -> SF (a, Event (SF a b)) bIt takes a single SF that takes as input values of type a and outputs values of type b. rswitch creates a new SF that also produces output b, but takes an additional input of type Event (SF a b). Note that the Event value's type matches the input type. This means that whenever the event happens, this SF will switch to that event value. However, the type of the SF remains SF (a, Event (SF a b)) b. This means that the SF is free to receive additional events with new SFs, which will influence the behavior of the overall SF. One use for this could be AI behaviors in a game:
moveFollowTarget :: SF TargetPosition Velocity moveShootTarget :: SF TargetPosition Velocity moveIdle :: SF TargetPosition Velocity aiMovement :: SF (TargetPosition, Event (SF TargetPosition Velocity)) Velocity aiMovement = rswitch moveIdle -- Initially idle... aiMovementManager :: SF a (Event (SF TargetPosition Velocity)) aiMovementManager = ... whatever ...Here, the aiMovementManager will fire an event whenever the movement behavior of the AI needs to change, and the value of the event will be the SF that the movement should change to.
kswitch: This is known as an intrinsic switch, since the contents of the SF are analyzed to figure out what the proper switch should be. Let's go over the type signature
kswitch :: SF a b -> SF (a, b) (Event c) -> (SF a b -> c -> SF a b) -> SF a bHere, kswitch takes three arguments, sf, analyzer, and mapping. sf is simply a standard SF with inputs of type a and outputs of type b. sf is how the signal behaves initially. analyzer is a SF that takes the input and output of sf and may or may not fire some sort of event whose value has type c. If it doesn't fire an event, then nothing happens, and the SF continues to behave like sf. If it does fire an event, then both sf and the event value are passed to mapping which determines the new SF to switch to. kswitch is useful when changing the way systems behave based on their outputs.
One example where this is useful is the algorithm for TCP Congestion Avoidance. Here, we look at whether or not we lose network packets, and either increase or decrease the speed at which we request data.
更多推荐
发布评论