[R-package] ensure use of interaction_constraints does not lead to features being ignored

[mayer79]

This enhances the R-API of interaction constraints by adding a feature group with those features that do not appear in any of the interaction groups. Currently, these are simply dropped from training, which seems undesirable.

Additionally, it reorganizes the code of the corresponding helper function .check_interaction_constraints().

It solves the R-package part of #6376. I will attempt a separate PR for the Python-package.

Example

.check_interaction_constraints(list("a", 2:3), letters[1:5])

# Output
[[1]]
[1] "[0]"

[[2]]
[1] "[1,2]"

[[3]]
[1] "[3,4]"

Without the PR, the result is

[[1]]
[1] "[0]"

[[2]]
[1] "[1,2]"

i.e., the last two features are silently dropped from the training.

[mayer79]

Getting a failing unit test:

  -- 1. Failure (test_lgb.Booster.R:209:5): Loading a Booster from a text file wor

  bst2$params[names(params)] not equal to `params`.

  Component "interaction_constraints": Length mismatch: comparison on first 2 components

I will have a look at it next week (afk).

[jameslamb]

Thanks! Left a few minor comments.

@ me if you need help with the failing tests. Let's also please get confirmation that excluding omitted features from training wasn't intentional (#6376 (comment)).

[jameslamb]

Hey @mayer79 , across your recent PRs I've seen multiple "fix linting" types of commits. Totally fine to keep using Continuous Integration to get that feedback (we don't have a lot of activity going on in the repo right now), but you'd probably find it faster to run the linting locally. It only requires R and the {lintr} package.

Rscript .ci/lint_r_code.R $(pwd)/R-package

[mayer79]

Hey @mayer79 , across your recent PRs I've seen multiple "fix linting" types of commits. Totally fine to keep using Continuous Integration to get that feedback (we don't have a lot of activity going on in the repo right now), but you'd probably find it faster to run the linting locally. It only requires R and the {lintr} package.

Rscript .ci/lint_r_code.R $(pwd)/R-package

Thanks, this is the stuff that I should have asked long time ago, but never did :-).

[mayer79]

Pipeline seems happy @jameslamb - but really no pressure :-)

[jameslamb]

Thanks very much for this! And I really appreciate you keeping it up to date with master while waiting for reviews.

I just left one suggestion about covering this a bit more thoroughly with tests. If you don't have time in the next week to get to that, let me know if you're open to me writing that test and pushing it here...I'm sorry for the time pressure (especially after not reviewing this for so long 😬 ), but I'm going to try to push for v4.4.0 to get out in the next week, ahead of the numpy 2.0 release (#6439 (comment)), and I'd love to get this change into it if we can.

[jameslamb]

This PR doesn't currently have a test confirming that the new automatically-added grouped is actually added to the model.

The change here on this line is passing that group through params from the beginning, and the new test added in test_utils.R only checks that .check_interaction_constraints() adds that group to whatever's passed into it... not necessarily that the output of that function actually makes it all the way to LightGBM's C++ code and therefore affects training.

Could you please add a test that works roughly like the following?

• passes something like interaction_constraints = list(3L, 1:2L) through params to lgb.train()
  • passing them out of order like that also might help catch some issues
• checks that the interaction_constraints in $get_params() of that Booster produced looks correct (i.e. includes the automatically-added group)
• checks that interaction_constraints parameter looks correct in the model string produced by $save_model_to_string()

That'd help improve our confidence that this is working end-to-end.

[jameslamb]

This comment is FANTASTIC, made it very easy for me to understand the code. Thank you!