复杂策略中的@composite vs flatmap

假设允许两种不同的方式来定义派生策略@compositeflatmap。据我所知,前者可以做任何事,后者可以做。但是,numpy arrays策略的implementation谈到了一些隐性成本
    # We support passing strategies as arguments for convenience,or at least
    # for legacy reasons,but don't want to pay the perf cost of a composite
    # strategy (i.e. repeated argument handling and validation) when it's not
    # needed.  So we get the best of both worlds by recursing with flatmap,# but only when it's actually needed.
我认为

表示收缩行为更糟,但是我不确定,并且在其他任何地方也找不到此文件。因此,什么时候应该使用@composite,什么时候flatmap以及什么时候应该像上面链接的实现中那样走这条中间路线?

history918 回答:复杂策略中的@composite vs flatmap

@composite.flatmap确实完全等效-您可以对任何一个进行处理,也可以对另一个进行处理,并且它们也将具有相同的性能。

我实际上写了该评论,原因是我们有时有时只想使用平面图/复合材料,而总是要仔细验证我们的逻辑。按照我设置的方式,我们可以避免使用.flatmap多次调用验证程序-如果要使用@composite,则需要第二个函数定义。

(还有一个API风格的问题,即这些参数几乎总是值,但有时也可以是策略。我们现在主要基于arrays()引起的混乱而禁止此类API,以便让用户编写他们自己的.flatmap

本文链接:https://www.f2er.com/2919091.html

大家都在问