生成的数值微调的元数据

Question

如果生成器输出的值包含尝试和时间的元数据，这将对生成测试（具有规范）的优化非常有用。
示例

(-> (s/exercise string? 1)
    first
    meta)
;; => {:time-ms 2, :attemts 1}

这可以帮助找到最慢的生成器，它们可以从中获得最大的定制化好处。

Answer 1

_评论由: alexmiller_

我将此移动到test.check，因为生成器就在那里。

请注意，并非每个值都可以携带元数据（数字、字符串等），但这是一个有趣的想法。

Answer 2

_评论由: jare_

> 请注意，并非每个值都可以携带元数据（数字、字符串等），但这是一个有趣的想法。

这并不算什么大问题，因为元数据将直接对规范工具的开发者有所帮助。任何想要使用它的人可以通过封装原语来克服这个限制。

对于最终用户API，需要有类似于spec/explain(s/explain-data, s/explain-str..)的东西。
我将称之为s/complexity，该函数接收一个规范并提供与原始规范相同结构的结构，其中包含生成复杂性数据（平均时间、尝试、mb规范形式等）。它应该以合理的方式处理过于复杂的规范，即：而不是抛出（如生成器一样），它最好报告规范中的哪个部分过于复杂及其元素的个体复杂性。

Answer 3

评论由：jare 提出

另外，s/complexity可能需要为每个节点（spec元素）设置超时时间（可配置），因为它主要是一个调试/性能分析工具。

Answer 4

评论由：gfredericks 提出

这里的“尝试”是什么意思？它仅适用于{{gen/such-that}}生成器吗？

Answer 5

评论由：jare 提出

是的，在规格说明的上下文中。生成器需要尝试多少次才能满足规格。

Answer 6

评论由：gfredericks 提出

我刚才注意到{{:time-ms}}这个方面，它可能不仅适用于{{such-that}}。

我同意能够轻松调试生成器性能是有用的，但我不认为这种方法明显适用于某些组合器，例如{{gen/fmap}}和{{gen/bind}}。如果有一个更具体的建议，包括这类案例的详细信息，我会更容易考虑。

Answer 7

评论由：jare 提出

bq. 我认为这种方法不太明显适用于一些组合器，例如 gen/fmap

元数据不应该在{{gen/fmap}}应用的功能内部可用。相反，该函数内部耗时的其他性能统计数据应与{{gen/fmap}}输入统计关联，然后连同输出一同返回。因此，数据将在嵌套{{gen/}}调用之间通过上下文携带。

bq. 元数据不应该在{{gen/fmap}}调用的函数内部可用。

或者，你可以允许查看输入统计，但不允许更改它。不确定这样做是否合适。它可能太过复杂。

Answer 8

_评论由: jare_

实际上，如果您允许窥视，它不仅可以用于调试，还可以用于更改生成来提高性能。
为了减轻累积生成器复杂性，通过切换路由来满足某些截止日期。

- - - - -

@gfredericks 由于某种原因，我不能为任何问题添加新评论，所以我更新了旧的一个。

对于


(def g1 ...)

(def g2 (gen/fmap f g1))


复杂度_ 函数应输出



(complexit g1) => {:name :time-ms 10}

(complexit g2) => {:name :fmap :time-ms 5 :args [{:name :time-ms 10}]}


这里 _:time-ms 5_ 是在 _f_ 函数内部的耗时。

Answer 9

评论由：gfredericks 提出

例如，假设我有

`
(def g1 ...)

(def g2 (gen/fmap f g1))
`

当我从 {{g2}} 生成值时，我会得到什么样的信息？它将是关于 {{g1}} 的，还是关于 {{f}} 的，或者以某种方式同时关于两者？

Answer 10

评论由：gfredericks 提出

(链接: ~JAre) 我认为您的评论权限已修复。

好的，我可以看到这可能会是一个明确定义的概念。但这将是一项相当大的工作量，而且我想确保不会有大的性能差异。如果有，我们可能需要一种默认关闭的方法，并确保在关闭时不会有性能损失。

Answer 11

评论由：jare 提出

是的，现在它工作正常了。谢谢。

Answer 12

参考： https://clojure.atlassian.net/browse/TCHECK-153 (由 alex+import 报告)