Support Enumerate inside HMC

[null-a]

Previous discussion:

• Original HMC issue
• Use Histogram everywhere #287

[stuhlmueller]

To do this, it could be helpful to generalize transformERP so that it transforms all files in the repository that end in .ad.js.

[null-a]

I think I have this working for the case where tapes enter the enumerated model as ERP parameters. See this test (based on Andreas' example from #287) for an example.

(See my hmc-over-enum branch for the rest of the code.)

It's of course possible to write down models where tapes enter in some other way, but I couldn't come up with any examples that seemed useful in practice. Does what I have cover the cases we're interested in?

So far I've adified appropriate bits of code by hand to get a feel for what needs transforming. It's not clear to me exactly how to best generalize transformERP, but I think we could happily merge this without such a generalized transform to begin with.

[stuhlmueller]

This may already be covered by what you have, but two important cases to get right are sequential and nested enumerations, as in these examples:

Sequential:

var model = function() {      
  var x = uniform(0, 1);

  var firstMarginal = Enumerate(function() {
    var y = flip(x);
    factor(!y ? 0 : -2);
    return y;
  });

  var secondMarginal = Enumerate(function(){
    var z = sample(firstMarginal);
    factor(z ? 1 : -1);
    return z;
  });

  var w = sample(secondMarginal);      
  return x * w;
};

Nested:

var model = function() {    
  var x = uniform(0, 1);

  var outerMarginal = Enumerate(function() {

    var innerMarginal = Enumerate(function(){
      var y = flip(x);
      factor(y ? 1 : -1);
      return y;
    });

    var z = sample(innerMarginal);
    factor(!z ? 0 : -2);
    return z;
  });

  var w = sample(outerMarginal);
  return x * w;
};

[ngoodman]

We do have a lot of cases where params flow into nested Enumeration not directly as an ERP param. Eg. within the enum there might be a factor(param1*x + param2*y) kind of thing.

We also often access the score of a submodel (not just sample from it): within outer factor(submodelERP.score([],x)).

@mhtess or @hawkrobe can provide further examples of actual cases.

[null-a]

two important cases to get right are sequential and nested enumerations

Great. I think they'll work, but I'll make sure.

We do have a lot of cases where params flow into nested Enumeration not directly as an ERP param

Ah, of course! Come to think of it I think these will probably already work too, but again I'll make sure.

Thanks!

[null-a]

I've added more tests for the cases mentioned above, they all seem to work OK. I've also decided on an approach to generalizing transformERP. There are still a few loose ends still to tie up, but not too many.

[stuhlmueller]

I've also decided on an approach to generalizing transformERP.

Why not transform everything in every file that ends with .ad.js? Would that have serious performance drawbacks, or are there other reasons?

[null-a]

Why not transform everything in every file that ends with .ad.js?

The only file that's transformed at present is erp.ad.js. The reason that whole file isn't transformed is that in putting together #265 I followed the approach both Sid and Daniel had taken of only transforming the scorers.

I believe this was done for performance reasons. One relevant data point is that in #265 we noticed that using ADified score functions caused the run time of existing algorithms to increase by something like 40%.

The more general version of the AD transform I wrote can be used to transform a whole file. (It only requires a 'use ad'; directive adding to the top of the file.) The idea is that I'll be able to use this to experiment with transforming all of enumerate.js, aggregation.js, etc. as a way making HMC over Enumeration work. I suspect it will work, but I won't know until I try.

The question of whether we should be transforming all of erp.ad.js is unrelated to this issue I think.

[stuhlmueller]

I agree that it's unrelated to this issue—I'm discussing it here since this is where you linked to the new approach to generalizing transformERP. It will be interesting to experiment with whole-file vs scorer-only transformations. If we find that there isn't a big difference, we might want to turn whole-file into the default for all .ad.js files, in which case we could simplify adify.js a bit.