You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
emp_feat += DiagonalAlignment::Feature(j, i, trg.size(), src.size()) * p;
in the surrounding loops, i ranges from 1 to src.size() inclusive and j from 0 to trg.size() exclusive. Further up in the code, j+1 is used as well, and I think the feature calculation assumes the same.
This bug would bias it towards a flatter distribution I think, but I'm not sure.
The text was updated successfully, but these errors were encountered:
You either pay for this with a slightly off-center prior either when j=0 or
j=trg.size() - 1-- I noticed this after I had run all the experiments and
decided not to fix it, but a couple people have pointed it out, so it's
probably worth fixing at some point...
emp_feat += DiagonalAlignment::Feature(j, i, trg.size(), src.size()) * p;
in the surrounding loops, i ranges from 1 to src.size() inclusive and j
from 0 to trg.size() exclusive. Further up in the code, j+1 is used as
well, and I think the feature calculation assumes the same.
This bug would bias it towards a flatter distribution I think, but I'm not
sure.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4
.
You either pay for this with a slightly off-center prior either when j=0 or j=trg.size() - 1
I'm not sure I quite follow this. Right now when collecting counts the features used are
calculated using 0-based indexing, while the rest of the program uses 1-based indexing.
The diagonal is calculated using the same (1-based). When using j+1 in that bit of code, doesn't it
just fix it to do what the paper says? How does that put the prior off-center?
shouldn't line 225 use j+1 instead of j?
in the surrounding loops, i ranges from 1 to src.size() inclusive and j from 0 to trg.size() exclusive. Further up in the code, j+1 is used as well, and I think the feature calculation assumes the same.
This bug would bias it towards a flatter distribution I think, but I'm not sure.
The text was updated successfully, but these errors were encountered: