From 8ec14f00d1078f0fa7ab3ba2a01954b1f6ca5260 Mon Sep 17 00:00:00 2001 From: graehl Date: Wed, 18 Aug 2010 21:26:55 +0000 Subject: ValueArray instead of string for state - same LM decode scores git-svn-id: https://ws10smt.googlecode.com/svn/trunk@593 ec762483-ff6d-05da-a07a-a48fb63a330f --- graehl/NOTES.earley | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'graehl/NOTES.earley') diff --git a/graehl/NOTES.earley b/graehl/NOTES.earley index 6f94f898..4156063a 100755 --- a/graehl/NOTES.earley +++ b/graehl/NOTES.earley @@ -88,3 +88,20 @@ then X[k,i]->rY.s (a',b') with a' += a*b'', b' += b*b'' ========== is forward cost viterbi fine? i.e. can i have items whose names ignore the lhs NT (look up predictions that i finish lazily / graph structured?) +====== + +1) A -> x . * (trie) + +this is somewhat nice. cost pushed for best first, of course. similar benefit as left-branching binarization without the explicit predict/complete steps? + +vs. just + +2) * -> x . y + +here you have to potentially list out all A -> . x y as items * -> . x y immediately, and shared rhs seqs won't be shared except at the usual single-NT predict/complete. of course, the prediction of items -> . x y can occur lazy best-first. + +vs. + +3) * -> x . * + +with 3, we predict all sorts of useless items - that won't give us our goal A and may not partcipate in any parse. this is not a good option at all. -- cgit v1.2.3