From e94cfb6b8cafc410ac0d8b373551034e36ec2db5 Mon Sep 17 00:00:00 2001
From: graehl <graehl@ec762483-ff6d-05da-a07a-a48fb63a330f>
Date: Tue, 6 Jul 2010 19:50:16 +0000
Subject: hg density prune epsilon workaround comment - fundamental bug
probably still exists
git-svn-id: https://ws10smt.googlecode.com/svn/trunk@162 ec762483-ff6d-05da-a07a-a48fb63a330f
---
decoder/hg.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
(limited to 'decoder')
diff --git a/decoder/hg.cc b/decoder/hg.cc
index 50f61865..19dbf892 100644
--- a/decoder/hg.cc
+++ b/decoder/hg.cc
@@ -178,7 +178,8 @@ void Hypergraph::PruneEdges(const std::vector<bool>& prune_edge, bool run_inside
void Hypergraph_finish_prune(Hypergraph &hg,vector<prob_t> const& io,double cutoff,vector<bool> const* preserve_mask,bool verbose=false)
{
const double EPSILON=1e-5;
- cutoff=cutoff-EPSILON; //
+ //TODO: //FIXME: if EPSILON is 0, then remnants (useless edges that don't connect to top? or top-connected but not bottom-up buildable referneced?) are left in the hypergraph output that cause mr_vest_map to segfault. adding EPSILON probably just covers up the symptom by making it far less frequent; I imagine any time threshold is set by DensityPrune, cutoff is exactly equal to the io of several nodes, but because of how it's computed, some round slightly down vs. slightly up. probably the flaw is in PruneEdges.
+ cutoff=cutoff-EPSILON;
vector<bool> prune(hg.NumberOfEdges());
if (verbose) {
if (preserve_mask) cerr << preserve_mask->size() << " " << prune.size() << endl;
--
cgit v1.2.3