The current implementation (def weighted_deletion_cost) of the function relies on iterating over the feature weights alongside the feature vectors (using something like zip(self.fm.weights, v1, v2)) to compute the cost. This means that the label order in both the feature vector and the weights array is critical.
However, the feature vector for phonemes is defined with the following order:
syl, son, cons, cont, delrel, lat, nas, strid, voi, sg, cg, ant, cor, distr, lab, hi, lo, back, round, velaric, tense, long, hitone, hireg
In contrast, the feature weights are defined in this order:
syl, son, cons, cont, delrel, lat, nas, strid, voi, sg, cg, ant, cor, distr, lab, hi, lo, back, round, tense, long, velaric # 0.25 | 0.125 | 0.25
As a result, I think the computed substitution cost—and thus the overall edit distance—will not accurately reflect the intended weighted differences
The current implementation (def weighted_deletion_cost) of the function relies on iterating over the feature weights alongside the feature vectors (using something like zip(self.fm.weights, v1, v2)) to compute the cost. This means that the label order in both the feature vector and the weights array is critical.
However, the feature vector for phonemes is defined with the following order:
syl, son, cons, cont, delrel, lat, nas, strid, voi, sg, cg, ant, cor, distr, lab, hi, lo, back, round, velaric, tense, long, hitone, hireg
In contrast, the feature weights are defined in this order:
syl, son, cons, cont, delrel, lat, nas, strid, voi, sg, cg, ant, cor, distr, lab, hi, lo, back, round, tense, long, velaric # 0.25 | 0.125 | 0.25
As a result, I think the computed substitution cost—and thus the overall edit distance—will not accurately reflect the intended weighted differences