dcao / babble Goto Github PK

On 9cf4759, the following is totally uncompressed:

(list
  (@ foo (@ (@ + (@ f x)) (@ f x)))
  (@ foo (@ (@ + (@ f x)) (@ f x)))
)

Changing basically anything about one of the inputs, (foo -> bar, x -> y) makes it work again.

Hello,
using the code from compression, we can read and compress inputs in the DreamCoder format. This seems to work, but am I overlooking any functionality for exporting compression results in the same format (e.g. as CompressionOutput as defined in dreamcoder/json.rs? This seems like basic functionality, but I'm confused by all the different experiment classes. My current understanding is that this is not implemented, and I'll have to manually post-process the ExperimentResult. This is of course possible, but appears a bit indirect - is there some simple way to access the invented library functions (and rewritten frontiers) such that we can parse them into the correct format?

Thanks for your help!

Running smiley on the following example (without DSRs):

(+ 
   (move 1 0 circle)
   (move 2 0 circle)
   (move 3 0 circle)
   (move 4 0 circle)
   (move 5 0 circle)
   (move 6 0 circle)
)

produces the expected result:

lib l0 =
  λx1 -> move <x1, 0> circle
in
  [l0 1,
    l0 2,
    l0 3,
    l0 4,
    l0 5,
    l0 6]

Adding a DSR "circle" => "(scale 1 circle)" works well, and even allows to obtain the above result if some of the circles in the input are scaled by 1.

However, adding a more general rewrite ?x -> (scale 1 ?x) results in not learning any libraries, and moreover returning an expression that is larger than the original:

scale 1 [move <1, 0> circle,
  move <2, 0> circle,
  move <3, 0> circle,
  move <4, 0> circle,
  move <5, 0> circle,
  move <6, 0> circle]

There might be two bugs here:

1. AU always returns empty for all pairs of states except the diagonal (might have to do with the e-graph being too loopy?)
2. Extraction also picks the wrong expression (not the original)

Running smiley on the following input:

(+ (move -20 0 (+ (scale 5 circle)
                  (move -2 -1.5 (rotate 90 (scale 2 line)))
                  (move 2 -1.5 (rotate 90 (scale 2 line)))
                  (move 0 2 (scale 4 line))))
   (move -7.5 0 (+ (scale 5 circle)
                   (move -2 -1.5 (rotate 90 (scale 2 line)))
                   (move 2 -1.5 (rotate 90 (scale 2 line)))
                   (move 0 2 (scale 1 circle))))
   (move 5 0 (+ (scale 5 circle)
                (move -2 -1.5 (rotate 90 (scale 1 circle)))
                (move 2 -1.5 (rotate 90 (scale 1 circle)))
                (move 0 2 (scale 1 circle))))
   (move 17.5 0 (+ (scale 5 circle)
                   (move -2 -1.5 (rotate 90 (scale 1 circle)))
                   (move 2 -1.5 (rotate 90 (scale 1 circle)))
                   (move 0 2 (scale 4 line)))))

produces the following output:

lib l15 =
  λx1 x2 x3 -> [scale 5 circle,
    move <-2, -1.5> (rotate 90 (scale x3 x2)),
    move <2, -1.5> (rotate 90 (scale x3 x2)),
    x1]
in
  [move <-20, 0> (l15 (move <0, 2> (scale 4 line)) line 2),
    move <-7.5, 0> (l15 (move <0, 2> (scale 1 circle)) line 2),
    move <5, 0> (l15 (move <0, 2> (scale 1 circle)) circle 1),
    move <17.5, 0> (l15 (move <0, 2> (scale 4 line)) circle 1)]

The issue here is that the four expressions of the form (move <0, 2> (scale ? ?)) are all abstracted into x1, which is incorrect AU, since they share top-level structure. The suspicious rewrite shows up in the log as "anti-unify 6".