对Yampa交换机的图表感到困惑 [英] Confused about diagrams of Yampa switches
问题描述
nofollow> http://www.haskell.org/haskellwiki/Yampa/switch
http://www.haskell.org/haskellwiki/Yampa/rSwitch
< a href =http://www.haskell.org/haskellwiki/Yampa/kSwitch =nofollow> http://www.haskell.org/haskellwiki/Yampa/kSwitch
（依此类推）。
我发现开关，唯一一个带有描述的图，是最容易理解的图。其他人似乎很难遵循相似的符号来阅读图表。例如，要尝试阅读 rSwitch 并使用在开关中使用的符号，可能是：
是一个递归SF，它总是输入一个'in'类型的信号，
返回一个'out'类型的信号。以同样的
类型的初始SF开始，但开关函数（？[cond]）平方之外的某个人可能
也通过一个Event（类型事件（SF输出）在
签名处），条件满足时（对于
[cond]平方之前的'？'）。在事件的情况下，Yampa将使用新的SF
而不是现有的SF
。这个过程是递归的，因为'？'（除了rSwitch的签名似乎是
递归），
不能从图表中获得它。
在查看 rSwitch 的源代码后，它看起来像使用 switch 当 t 被触发时，根据图中描述的内容递归地切换到相同的init SF，尽管我没有看到特殊的
在Yampa Arcade中，它解释了 dpSwitch 代码和示例。关于游戏Frag的论文也使用 dpSwitch 。然而，这些教程中似乎没有 rSwitch 。所以我真的不知道如何使用 r - 或 k - 串行开关，在什么情况下，我们将需要它们。
开关改变一个信号功能的行为像另一个信号功能。我个人发现Yampa图很难解析，但各种开关的类型签名为如何理解它们提供了很好的指示。一旦你了解了类型签名，图表变得更清晰。 switch 本身是最基本的： switch :: SF a b，事件c） - > （c - > SF a b） - > SF ab
如果我们看一下这个类型，它会告诉我它到底做了什么：它需要一个SF sf 和一个SF生成器 sfg 。 sf 产生 c 。因此，无论何时发生 sf 的事件，SF都将切换到SF发生器的结果。在事件发生之前，由此产生的SF将返回原始SF的值。
这个想法也用于 rswitch
$ b $ < rswitch ：这被称为外部开关，这意味着SF将在没有任何输入或输出分析的情况下进行切换。让我们看看类型签名：
rswitch :: SF a b - > SF（a，Event（SF ab））b
需要一个SF作为输入值类型为 a ，并输出 b 类型的值。 rswitch 会创建一个新的SF，它也会产生输出 b ，但需要输入事件（SF ab）。请注意，事件值的类型与输入类型相匹配。这意味着每当事件发生时，该SF将切换到该事件值。但是，SF的类型仍然是 SF（a，Event（SF a b））b 。这意味着SF可以自由地接收新SF的附加事件，这将影响整个SF的行为。其中一个用途可能是AI在游戏中的行为：
$ move $ F $ TargetFosition Velocity $ b $ moveShootTarget :: SF TargetPosition Velocity
moveIdle :: SF TargetPosition Velocity
$ b aiMovement :: SF（TargetPosition，Event（SF TargetPosition Velocity））速度
aiMovement = rswitch moveIdle - 最初闲置...
aiMovementManager :: SF a（Event（SF TargetPosition Velocity））
aiMovementManager = ...任何...
这里，只要AI的移动行为需要改变， aiMovementManager 就会触发一个事件，事件将是运动应该改变的SF。
kswitch ：这被称为内部开关，因为分析了SF的内容以确定正确的开关应该是什么。让我们来看看类型签名
kswitch :: SF a b - > SF（a，b）（事件c） - > （SF a b→> c→SF a b）→> SF ab
在这里， kswitch ， sf ，分析器和映射。 sf 只是一个标准的SF，输入类型 a ，输出类型 b 。 sf 是信号最初的表现。 analyzer 是一个SF，它接受 sf 的输入和输出，并且可能或不可以触发某种类型的事件，其值有类型 c 。如果它没有触发一个事件，那么什么都不会发生，并且SF继续像 sf 那样工作。如果它触发了一个事件，那么 sf 和事件值都会被传递给 mapping ，这决定了新的SF到切换到。 kswitch 在根据系统输出改变系统行为方式时非常有用。
一个有用的例子是用于 TCP拥塞避免的算法。在这里，我们看看是否会丢失网络数据包，并增加或减少我们请求数据的速度。
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.
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 b
If 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)) b
It 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 b
Here, 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.
这篇关于对Yampa交换机的图表感到困惑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
