NaN SHAP values from Booster.predict with pred_contribs=True

[jzakrzew]

Environment info

Operating System: Linux

Compiler: gcc 8.1.1

Package used (python/R/jvm/C++): python

xgboost version used: tried both 0.7 and 0.71
python version used: 3.6

Steps to reproduce

run bug.py from nan-contribs.tar.gz to get the following output:

[0.00081278 0.05731808 0.00092801 0.00081278]
[[ 0.0000000e+00 -3.8550010e+00            nan -7.3062401e+00
  -1.5469847e+00  3.7286822e-02 -6.7939714e-02 -2.0173371e-01
   7.2428236e+00]
 [ 0.0000000e+00 -2.9010804e+00            nan -6.2523079e+00
  -4.6626371e-01  2.5810658e-03 -7.5633558e-03 -1.9301096e-01
   7.2428236e+00]
 [ 0.0000000e+00 -3.8550010e+00            nan -7.3062401e+00
  -1.5469847e+00  3.7286822e-02  6.7191636e-03 -2.0173371e-01
   7.2428236e+00]
 [ 0.0000000e+00 -3.8550010e+00            nan -7.3062401e+00
  -1.5469847e+00  3.7286822e-02 -6.7939714e-02 -2.0173371e-01
   7.2428236e+00]]

After some debugging, I discovered that the nans come from the UnwoundPathSum function in
xgboost/include/xgboost/tree_model.h:

xgboost/include/xgboost/tree_model.h

Lines 725 to 726 in 230cb9b

	total += (unique_path[i].pweight / zero_fraction) / ((unique_depth - i)
	/ static_cast<bst_float>(unique_depth + 1));

There, at some point, both unique_path[i].pweight and zero_fraction happen to be zero.

[xydrolase]

Noticed the same issue with certain models.

[slundberg]

@jzakrzew Thanks for getting to the source of the nan's! My guess is we just need to wrap that op in a check for that corner case. I'll look into here soon.