Feat/integrated shrinking #109

sir4ur0n · 2021-04-12T10:14:16Z

Closes #106

This is a WIP MR, many things are still pending, I will try to list them below

gr-im

I give a first look (mainly because I'm curious).
I find that reading the code with all these type annotations is quite complicated.
And, it is maybe just a stylistic concern but instead of directly defining the infix operator, I suggest to find it a name (... like the comment) and defining the infix operator in term of the named function.
I think that Selective API could be a great improvement as suggested by on the issue and you can add select a b = branch a b (pure (fun x -> x))

src/core/QCheck_ng.ml

c-cube · 2021-04-12T14:00:02Z

I give a first look (mainly because I'm curious).
I find that reading the code with all these type annotations is quite complicated.

I couldn't disagree more :-).

Personally I tend to annotate most functions; at least return types or arguments that are not the t of the module. I gradually moved towards that style as I find it more readable and it isolates type errors better. Annotating return types is even better than annotating arguments because you get what the function does at a glance, and you don't risk using a partial application as the last expression mistakenly.

gr-im · 2021-04-12T14:21:23Z

@c-cube it is a very interesting feedback! (tbh it is an actual debate in a community shared by @sir4ur0n and me) and it is pretty interesting to see that your feedback intersect with @sir4ur0n's one.

c-cube · 2021-04-12T14:38:21Z

I'd love to hear more about this debate! I also tend to not write .mli early these days (sometimes I don't write them at all if my .ml is composed of a list of constrained submodules):

module Foo : sig …
end = struct …
end```).

Anyway for me it helps to annotate types so that future me can read the code back more easily. Types as documentation, in a way.

gr-im · 2021-04-12T14:55:11Z

When I work on datastructure, I usually have a module type. So the module type is available in the ml and I tend to use the constraint. When I work on particular file, not attached to a datastructure, I generally use a local module, called Internal, which allows me to work without mli, but allows me to have a clear separation between the interface and the definition. Which is, in my opinion, more readable. And when the module is "finished", it easy to move the signature of the internal module in a mli.

c-cube · 2021-04-12T15:03:53Z

Interesting. When I write against an interface I actually tend to not constrain it too early (module Foo : S … = struct …) because merlin gives an error on Foo and I want to focus on the content 😂 .

gr-im · 2021-04-12T15:24:13Z

Only on save :) (but yes, I shutdown merlin regularly)

sir4ur0n · 2021-04-12T16:29:32Z

I just pushed an MLI as well as put back add_shrink_invariant.

I keep thinking add_shrink_invariant is useless with integrated shrinking but I'm waiting for feedback before removing it once and for good.

c-cube · 2021-04-12T16:38:20Z

@sir4ur0n so what do you think of putting all that in QCheck.ml instead, as we discussed elsewhere? In a GenTree module?

src/core/QCheck_ng.ml

sir4ur0n · 2021-04-13T07:43:00Z

For ease of debugging generators/shrinkers, I have added a pretty printer to Tree.t and a function generate_print (its API may change) that generates a tree and pretty-prints it, here's an example output (I am open to suggestions, I am not good at the pp thing in OCaml):

$ Gen.generate_print (Gen.int_range ~origin:10 2 20) Format.pp_print_int |> Format.eprintf "%s"
Tree(
  Node(
    12
  ),
  Shrinks(
    Tree(
      Node(
        10
      ),
      Shrinks()
    ),
    Tree(
      Node(
        11
      ),
      Shrinks(
        Tree(
          Node(
            10
          ),
          Shrinks()
        )
      )
    )
  )
)

This tells us it generated the value 12 which has 2 shrinks:

value 10 with no shrinks as it is the origin (best shrink)
value 11 with nested shrink 10

c-cube · 2021-05-02T01:41:57Z

I am well aware that this is a pretty big PR, and thus reviewing it may be time/energy consuming, I greatly appreciate your guidance and patience these last days/weeks bowing_man, and I do hope we can make this PR happen Soon ™

thank you for all that work! I'll try to review it in a reasonable amount of time. Already wrote a patch for the printer 0001-refactor-pretty-printer.patch.gz which I find more readable :-)

I noticed that some functions from Stdlib are recent (ish: 4.08) and that's a bit annoying for the few codebases I have that try to support older versions. I wonder if qcheck2 (or qcheck-core2? qcheck2-core?), like ounit2, could be its own package, on which qcheck-core now depends. Then eventually we could deprecate the whole of qcheck-core. What do you think?

sir4ur0n · 2021-05-02T12:42:33Z

Already wrote a patch for the printer 0001-refactor-pretty-printer.patch.gz which I find more readable :-)

I have enabled "Allow edits by maintainers" so feel free to push code changes directly on it, I will not feel offended 😄

About supporting old OCaml compiler versions:

I'm not sure I understand how putting QCheck2 in its own package would solve this? AFAIU the qcheck2 package would still need to have a "ocaml" {>= "4.07.0"} constraint (e.g. to have Seq module available) and thus qcheck could not depend on qcheck2 for compiler versions < 4.07.0.
Otherwise I don't have any opinion on putting QCheck2 in its own package. However if we do so, wouldn't it be better to rename it to QCheck too?
This is where my recent learning of OCaml and its ecosystem is a problem: is there a way to add optional code, depending on e.g. the compiler version? That way, for compilers < 4.07.0 we could create a module where we copy all "recent" code we rely on, like Seq, and more recent compiler versions would just use Stdlib code instead. Generally I'm not familiar with practices, tips and tricks to support that kind of situation in OCaml

jmid · 2021-05-02T13:34:20Z

* I'm not sure I understand how putting `QCheck2` in its own package would solve this? AFAIU the `qcheck2` package would still need to have a `"ocaml" {>= "4.07.0"}` constraint (e.g. to have `Seq` module available) and thus `qcheck` could not depend on `qcheck2` for compiler versions < 4.07.0.

@c-cube has a ... package for every occasion: https://github.com/c-cube/seq 🤓

c-cube · 2021-05-02T15:12:33Z

Ahah I forgot. That's a transitional package dating back to when I added Seq to the stdlib :-). I was indeed not thinking straight. We can depend on 4.03 on forward I imagine, unless I go and vendor the newer functions again.

sir4ur0n · 2021-05-02T19:42:42Z

We can depend on 4.03 on forward I imagine

I'm not sure I understand 😅 If we depend on 4.03 the problem of all the missing modules and functions (Seq, Int, Float, Option, etc.) is still there, isn't it?

c-cube · 2021-05-02T21:04:10Z

I meant 4.08, sorry :). Force of habit maybe?

c-cube

That's excellent, thanks a lot for all the work. I think there are things to change, but I'm confident in the result.

remove all the functional stuff for now, deal with it in Followup: Reimplement function shrinking in integrated shrinking #110
a few smaller changes that are in comments

src/core/QCheck.mli

src/core/QCheck2.mli

src/core/QCheck2.ml

c-cube · 2021-05-04T01:04:26Z

src/core/QCheck2.ml

+    | _ -> false
+


I think this might be very useful in practice:

Suggested change

| _ -> false

| _ -> false

let rec interleave s1 s2 () =

match s1() with

| Nil -> s2()

| Cons (x, s1') -> Cons (x, interleave s2 s1')

c-cube · 2021-05-04T01:05:02Z

src/core/QCheck2.ml

+    let Tree (x0, xs) = a in
+    let Tree (f0, fs) = f in
+    let y = f0 x0 in
+    let ys = Seq.append (Seq.map (fun f' -> ap f' a) fs) (Seq.map (fun x' -> ap f x') xs) in


Suggested change

let ys = Seq.append (Seq.map (fun f' -> ap f' a) fs) (Seq.map (fun x' -> ap f x') xs) in

let ys = Seq.interleave (Seq.map (fun f' -> ap f' a) fs) (Seq.map (fun x' -> ap f x') xs) in

Doesn't this implementation break some applicative laws that we may want to respect?

It breaks at least the composition property:

pure (fun g f x -> g (f x)) <*> u <*> v <*> w = u <*> (v <*> w)

but I don't know if this can lead to problems along the way, maybe we don't care

Also: functionally speaking, what is the benefit of such interleaving?

I think a benefit is that if the problem is on value a (no matter the function a -> b), it will try faster shrinks of a (instead of first trying to exhaust all shrinks of f, and also trying again all shrinks of f at each shrink of a before further shrinking a), am I correct?

This is a sensible benefit indeed

The (expected) benefit is indeed to be able to try shrinks of b before we exhaust the (direct) shrinks of a, so it's more "fair".

I don't think it breaks the composition property, since we don't really have a notion of equality on trees 😏 . If you consider shrinks as a set, the associativity still holds; is order of shrinks something we should care about algebraically?

c-cube · 2021-05-04T02:08:06Z

src/core/QCheck2.mli

+end
+
+(** An observable is a random function {i argument}. *)
+module Observable : sig


let's remove that :)

c-cube · 2021-05-04T02:12:34Z

src/core/QCheck2.mli

+type _ fun_repr
+(** Internal data for functions. A ['f fun_] is a function
+    of type ['f], fundamentally. *)
+
+(** A function packed with the data required to print/shrink it. See {!Fn}
+    to see how to apply, print, etc. such a function.
+
+    One can also directly pattern match on it to obtain
+    the executable function.
+
+    For example:
+    {[
+      QCheck.Test.make
+        QCheck.(pair (fun1 Observable.int bool) (small_list int))
+        (fun (Fun (_,f), l) -> l=(List.rev_map f l |> List.rev l))
+    ]}
+*)
+type _ fun_ =
+  | Fun : 'f fun_repr * 'f -> 'f fun_
+
+(** Utils on functions
+    @since 0.6 *)
+module Fn : sig
+  type 'a t = 'a fun_
+
+  val print : _ t Print.t
+
+  val apply : 'f t -> 'f
+end


all that should go

c-cube · 2021-05-04T02:12:39Z

src/core/QCheck2.mli

+    (shrinking will be faster).
+    @since 0.6 *)
+
+module Tuple : sig


c-cube · 2021-05-04T02:12:54Z

src/core/QCheck2.mli

+val fun_nary : 'a Tuple.obs -> 'b arbitrary -> ('a Tuple.t -> 'b) fun_ arbitrary
+(** [fun_nary] makes random n-ary functions.
+    Example:
+    {[
+      let module O = Observable in
+      fun_nary Tuple.(O.int @-> O.float @-> O.string @-> o_nil) bool)
+    ]}
+    @since 0.6 *)
+
+val fun2 :
+  'a Observable.t ->
+  'b Observable.t ->
+  'c arbitrary ->
+  ('a -> 'b -> 'c) fun_ arbitrary
+(** @since 0.6 *)
+
+val fun3 :
+  'a Observable.t ->
+  'b Observable.t ->
+  'c Observable.t ->
+  'd arbitrary ->
+  ('a -> 'b -> 'c -> 'd) fun_ arbitrary
+(** @since 0.6 *)
+
+val fun4 :
+  'a Observable.t ->
+  'b Observable.t ->
+  'c Observable.t ->
+  'd Observable.t ->
+  'e arbitrary ->
+  ('a -> 'b -> 'c -> 'd -> 'e) fun_ arbitrary
+(** @since 0.6 *)


src/core/QCheck2.mli

sir4ur0n · 2021-05-09T11:04:26Z

Bumped the min OCaml version to 4.08 in 1ceea87

Co-authored-by: Simon Cruanes <[email protected]>

c-cube · 2021-05-14T23:48:46Z

@sir4ur0n sorry for the loss of synchronization; is this ready for review again?

sir4ur0n · 2021-05-17T05:59:07Z

No, I lack time to work on it these days 😞 I have fixed some issues but definitely not all of them yet.

I'll ping you when it's done

Edit: I just saw you merged it, is that intentional? 😅

c-cube · 2021-05-17T17:58:45Z

Yes I did, I thought it was ready and I was stalling it … :p

c-cube · 2021-05-17T18:02:38Z

I just force pushed back, sorry. We need to fix #115 first :)

Julien Debon and others added 8 commits April 9, 2021 22:24

tmp: Start integrated shrinking

0cbe1e7

Gen mostly migrated, starting migrating arbitrary

2b7b024

Moar progress

88a1e44

End arbitrary and adapt main runner with new shrinker

62d5362

Start working on function generation

7e4e057

Fix applicative implementation for Tree.t

ef76c72

QCheck.ml compiles

2bf7d02

Move to QCheck_ng

560ef84

gr-im reviewed Apr 12, 2021

View reviewed changes

src/core/QCheck_ng.ml Outdated Show resolved Hide resolved

src/core/QCheck_ng.ml Outdated Show resolved Hide resolved

src/core/QCheck_ng.ml Outdated Show resolved Hide resolved

src/core/QCheck_ng.ml Outdated Show resolved Hide resolved

src/core/QCheck_ng.ml Outdated Show resolved Hide resolved

Various cleanup

047a848

Add mli and add_shrink_invariant

0d554c8

sir4ur0n commented Apr 12, 2021

View reviewed changes

src/core/QCheck_ng.ml Outdated Show resolved Hide resolved

Julien Debon added 7 commits April 12, 2021 19:24

libev needed for utop

430fcde

Improve error message for find_origin

c14a844

Improve and fix the printable char generator

475c87b

Format

19ff5ab

Add pretty printer for Tree.t to ease debug

bea6858

Fix infinite loop on int_range

947c9ab

Fix adding the last shrink candidate for int_range and int32/64 ranges

1aceb83

Julien Debon added 2 commits April 13, 2021 09:54

Change shuffle_a to a regular generator

ba8dbd6

Improve pretty printer

a0d1a7f

c-cube requested changes May 4, 2021

View reviewed changes

sir4ur0n added 3 commits May 8, 2021 14:31

Consistency on RS vs Random.State

328e7df

Migrate to Format

525ff27

Bump min OCaml version to 4.08

1ceea87

sir4ur0n and others added 3 commits May 9, 2021 13:40

Use format string

978c45a

Add comment on QCheck.Test

ac36c23

Minor improvement on cell documentation

ff99201

Co-authored-by: Simon Cruanes <[email protected]>

sir4ur0n force-pushed the feat/integratedShrinking branch from 21c9df0 to 40014f3 Compare May 9, 2021 12:10

number_towards: use module

40014f3

c-cube mentioned this pull request May 10, 2021

nat_split, pos_split #114

Merged

gasche mentioned this pull request May 10, 2021

Switch to Integrated Shrinking a la Hypothesis/Hedgehog #106

Closed

c-cube merged commit 3a10c79 into c-cube:master May 15, 2021

This was referenced May 19, 2021

Feat/integrated shrinking #116

Merged

Remove arbitrary and use Gen.t directly in tests #119

Closed

Composing shrinking #120

Open

Choose/Oneof: shrink towards the first or not #121

Closed

This was referenced May 27, 2021

Provide unfold in Gen and/or in Tree #122

Open

Move corner functions/values into a dedicated module Corner #123

Open

jmid mentioned this pull request Jul 14, 2023

Documentation - role of Gen.t vs. arbitrary #281

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat/integrated shrinking #109

Feat/integrated shrinking #109

sir4ur0n commented Apr 12, 2021 •

edited

Loading

gr-im left a comment

c-cube commented Apr 12, 2021

gr-im commented Apr 12, 2021

c-cube commented Apr 12, 2021

gr-im commented Apr 12, 2021

c-cube commented Apr 12, 2021

gr-im commented Apr 12, 2021

sir4ur0n commented Apr 12, 2021

c-cube commented Apr 12, 2021

sir4ur0n commented Apr 13, 2021

c-cube commented May 2, 2021

sir4ur0n commented May 2, 2021

jmid commented May 2, 2021

c-cube commented May 2, 2021 via email

sir4ur0n commented May 2, 2021

c-cube commented May 2, 2021 via email

c-cube left a comment

c-cube May 4, 2021

c-cube May 4, 2021

sir4ur0n May 4, 2021

c-cube May 4, 2021

c-cube May 4, 2021

c-cube May 4, 2021

c-cube May 4, 2021

c-cube May 4, 2021

sir4ur0n commented May 9, 2021

c-cube commented May 14, 2021

sir4ur0n commented May 17, 2021 •

edited

Loading

c-cube commented May 17, 2021

c-cube commented May 17, 2021

-    | _ -> false
+    | _ -> false
+let rec interleave s1 s2 () =
+  match s1() with
+  | Nil -> s2()
+  | Cons (x, s1') -> Cons (x, interleave s2 s1')

	let ys = Seq.append (Seq.map (fun f' -> ap f' a) fs) (Seq.map (fun x' -> ap f x') xs) in
	let ys = Seq.interleave (Seq.map (fun f' -> ap f' a) fs) (Seq.map (fun x' -> ap f x') xs) in

Feat/integrated shrinking #109

Feat/integrated shrinking #109

Conversation

sir4ur0n commented Apr 12, 2021 • edited Loading

gr-im left a comment

Choose a reason for hiding this comment

c-cube commented Apr 12, 2021

gr-im commented Apr 12, 2021

c-cube commented Apr 12, 2021

gr-im commented Apr 12, 2021

c-cube commented Apr 12, 2021

gr-im commented Apr 12, 2021

sir4ur0n commented Apr 12, 2021

c-cube commented Apr 12, 2021

sir4ur0n commented Apr 13, 2021

c-cube commented May 2, 2021

sir4ur0n commented May 2, 2021

jmid commented May 2, 2021

c-cube commented May 2, 2021 via email

sir4ur0n commented May 2, 2021

c-cube commented May 2, 2021 via email

c-cube left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sir4ur0n commented May 9, 2021

c-cube commented May 14, 2021

sir4ur0n commented May 17, 2021 • edited Loading

c-cube commented May 17, 2021

c-cube commented May 17, 2021

sir4ur0n commented Apr 12, 2021 •

edited

Loading

sir4ur0n commented May 17, 2021 •

edited

Loading