WeightInherit type=additive thinks operator is \sum

Question

The ::WeightInherit property appears to treat the operator implicitly as a \sum when type=additive.

x::Weight(value=2, label=field).
y::Weight(value=3, label=field).
f{#}::WeightInherit(label=all, type=additive).
ex:= f{x}.
drop_weight(ex, $field=2$);

returns 0, as expected, but

drop_weight(ex, $field=1$);

returns x. (Same for field=3,4,...)

Interestingly,

ex := f{x}{y}.
drop_weight(ex, $field=3$);
ex := f{x}{y}.
drop_weight(ex, $field=2$);

returns first x and then y. Similarly,

ex := f{x}{y}{z}.
drop_weight(ex, $field=3$)

returns f{x}{z}.

So drop_weight is converting f{x} to x but if f has more than one child, it's leaving it as f. Presumably this is because the code implicitly treats f as \sum.

Answer 1

Yeah, this is fishy. The drop_weight algorithm is trying to be clever to determine where it can apply, and then fails miserably in this situation. Your particular problem can probably be solved by not treating f as a sum with one term, but the general problem is more complicated.

What we really want is to restrict this algorithm to "terms in a sum". But the question is now whether that sum is allowed to appear somewhere deeper down the tree, e.g. in f(x+y+z) if the full expression reads f(x+y+z)+g(a+b). I obviously didn't think this through fully. Suggestions welcome.

To a certain extent this issue also arises for zoom: when is a non-sum node to be treated as a single-term sum? zoom ignores this altogether (and never works except in an explicit multi-term sum).

Comments

I agree it's tricky. Keeping f{x} from turning into {x}, with all the other behavior unchanged, would seem consistent.

But then I guess this is basically just presuming

f{x}{y} == f{x} + f{y}

if you want to be able to split up f in drop_weight or zoom.

Additive is weird....