Divide by Zero in Weighted Arithmetic Mean Algorithm

[nathannaveen]

The Weighted Arithmetic Mean algorithm in the wam package currently returns math.NaN() when totalWeight is zero.

Is this intended behavior or should the algorithm return an error in this scenario instead of math.NaN()?
In other scenarios, returning math.NaN() may be fine, but when the total weight of the inputs is zero, it is better to return an error so that the user of the algorithm is aware that the calculation failed and can take appropriate action.

criticality_score/internal/scorer/algorithm/wam/wam.go

Line 47 in a3d961d

return s / totalWeight

[nathannaveen]

cc @calebbrown 👀

[jailby]

I think that to emulate a negative weight you need to use the smaller_is_better attribute in the signal config like the updated_since signal:
https://github.com/ossf/criticality_score/blob/main/config/scorer/original_pike.yml#L27-L30

I think that's the way to handle negative signal.

[nathannaveen]

@jailby I agree that smaller_is_better should be set when we have a negative weight, but what about a 0 weight? If we have totalWeight equal zero then we get math.NaN().

[calebbrown]

Non-positive weights don't make much sense, and should cause an error if supplied.

• zero weights are meaningless - it implies that the particular field should be ignored, but it could just be removed
• negative weights are ambiguous - does it mean "smaller is better" or "the presence of this field should have a negative impact on the final score"? Algorithmically for a WAM a negative weight makes the total weight smaller, and cause the fields contribution to the total score to be negated, which is confusing.

Other ways of mutating the fields to make them work well in a aggregation function (like WAM) may be necessary (e.g. inverse, diff with another field), but that should be done separately.

[nathannaveen]

@calebbrown So, should we create errors for zero and negative weights?