automatic backchaining declarations?

[jeisner]

@nwf: Students who innocently try to define an innocent-looking function will be met with a scary and unhelpful error message (see below). I'd rather not have to explain planning and the backchain declaration to them.

Eventually we want the determination of chaining to be automatic. So for now, when ordinary planning fails, couldn't the planner see if it helps to add a backchain declaration and try again? This beats making the user do it.

:- foo(X) = X+1.
DynaCompilerError:
FATAL: Encountered error in input program:
 Unable to plan initializers for rule(s):
   /home/jasoneis/.dyna/tmp/15766/f8207d93ff9ba46002ae41fd3e0d02c0840e84e5.dyna:1:1-/home/jasoneis/.dyna/tmp/15766/f8207d93ff9ba46002ae41fd3e0d02c0840e84e5.dyna:1:14

> new rule(s) were not added to program.

[timvieira]

I like this suggestion. On Jun 30, 2013 6:27 PM, "Jason Eisner" [email protected] wrote:

@nwf https://github.com/nwf: Students who innocently try to define an innocent-looking function will be met with a scary and unhelpful error message (see below). I'd rather not have to explain planning and the backchain declaration to them.

Eventually we want the determination of chaining to be automatic. So for now, when ordinary planning fails, couldn't the planner see if it helps to add a backchain declaration and try again? This beats making the user do it.

:- foo(X) = X+1. DynaCompilerError: FATAL: Encountered error in input program: Unable to plan initializers for rule(s): /home/jasoneis/.dyna/tmp/15766/f8207d93ff9ba46002ae41fd3e0d02c0840e84e5.dyna:1:1-/home/jasoneis/.dyna/tmp/15766/f8207d93ff9ba46002ae41fd3e0d02c0840e84e5.dyna:1:14

new rule(s) were not added to program.

— Reply to this email directly or view it on GitHubhttps://github.com/nwf/dyna/issues/30 .

[jeisner]

Here's another case with a very different message. In the proposal, it would add an implicit backchaining declaration of f/1 (which might cause f/1 to be replanned).

:- :- backchain g/1.
:- g(X) = f(X).
DynaCompilerError:
Compiler panic!
This is almost assuredly not your fault!  Please contact a TA.
 Backchaining planner failed

> new rule(s) were not added to program.

[nwf]

Unfortunately, "add the declaration and try again", as nice as it might be, would be a pain to implement, since our planner is just running over a list of rules independently. There's no tracking of which rules are responsible for what -- it's something we'll need going forward, of course, but it just isn't there yet.

[jeisner]

Independence is what makes it easy, I would have thought. My suggestion was to go greedily through the list in order (which is what the REPL does). If rule number 5 has the form f(...) += ... and this fails, and f has not yet been assumed to be FC, then try assuming that f is BC.

[nwf]

I mean that there's no state carried from rule to rule, and no explicit table of materialized predicates -- it was the default. Yes, I know it needs to be fixed.

[jeisner]

See #31 for another reason it needs to be fixed.

[jeisner]

examples/forward-backward.dyna highlights a couple of weaknesses of the current limited mixed-chaining setup. I couldn't just write

alpha(Iteration,start_state) += 1.

nor do this override (which forces a certain emission probability be 1 regardless of smoothed reestimation)

p_emission(Iteration,&stop,&eos) := 1.

without making all of alpha and p_emission (and hence ultimately almost the whole program) be backward-chained. So instead I had to add grounded side conditions, which also had to be defined.

[jeisner]

Instead of automatic backchaining declarations, we could also try generating automatic magic template side conditions. (But just enough to make sure that the rules could be planned.) That would help for the previous example ...

However, note that query alpha(129387410324,start_state) would now be null because the side condition failed, and that's not in keeping with the program semantics. To preserve the semantics of that query, we would have to rename our magic-templated restricted alpha to some internal name, and then provide a public alpha that backchained as needed to support queries. But then we'd need backchaining with forward-chained antecedents, which we don't have yet.