diff options
author | graehl <graehl@ec762483-ff6d-05da-a07a-a48fb63a330f> | 2010-08-18 21:26:55 +0000 |
---|---|---|
committer | graehl <graehl@ec762483-ff6d-05da-a07a-a48fb63a330f> | 2010-08-18 21:26:55 +0000 |
commit | 769aadfc431f2eec68c889b65b8939a4d35f56e9 (patch) | |
tree | 31a496a1a49416afde4d5cee668969acc7497e9f /graehl | |
parent | 242774be8f3e4c08d1406ca4ecc9abcc1ca7d190 (diff) |
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
Diffstat (limited to 'graehl')
-rwxr-xr-x | graehl/NOTES.earley | 17 |
1 files changed, 17 insertions, 0 deletions
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. |