summaryrefslogtreecommitdiff
path: root/graehl
diff options
context:
space:
mode:
authorgraehl <graehl@ec762483-ff6d-05da-a07a-a48fb63a330f>2010-08-18 21:26:55 +0000
committergraehl <graehl@ec762483-ff6d-05da-a07a-a48fb63a330f>2010-08-18 21:26:55 +0000
commit769aadfc431f2eec68c889b65b8939a4d35f56e9 (patch)
tree31a496a1a49416afde4d5cee668969acc7497e9f /graehl
parent242774be8f3e4c08d1406ca4ecc9abcc1ca7d190 (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-xgraehl/NOTES.earley17
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.