[tutorials][ML] Add RDataLoader tutorial for XGBoost

[siliataider]

This Pull request:

Changes:

Adds a new tutorial ml_dataloader_XGBoost.py demonstrating XGBoost training using RDataLoader to stream data directly from EOS without intermediate files stored after the shuffling/splitting phase.

This tutorial is inspired from the tmva101_Training workflow but eliminates the need for the tmva100_DataPreparation step which splits the dataset in 2 separate training/testing sets and stores 2 intermediate files.

[guitargeek]

I'm curious: is there an advantage of using the batching data loader for loading all data at once? RDataFrame.AsNumpy seems completely fine here.

Your new code can maybe be seen as a usage example of the RDataLoader, but I would rather do this only in tutorials where the data is actually loaded in batches. Otherwise, we risk sending the wrong message that getting your ROOT data to Numpy is not as easy as one line RDataFrame.AsNumpy.

[siliataider]

Fair point.

There are a couple of advantages of using the rdataloader though:

• you can define your label and wieght columns with rdataframe and unpack them with the rdataloader as the target/weights separation is built-in instead of manually creating separate arrays
• using the rdataloader essentially makes the entire data preparation script unnecessary as you can do both shuffling and splitting dynamically at train time

So:

• either i merge the tmva100_DataPreparation.py and tmva101_Training.py because using the RDataLoader we don't need both,
• or I create a separate example inspired from this one, just with this alternative laoding mechanism

My goal at the end is to have a tutorial showing how to do XGBoost training with the RDataLoader

[guitargeek]

Fair point.

There are a couple of advantages of using the rdataloader though:

* you can define your label and wieght columns with rdataframe and unpack them with the rdataloader as the target/weights separation is built-in instead of manually creating separate arrays

As you see in the existing tutorial, adding the weights as NumPy arrays is not hard, so I wouldn't really call it an advantage of the data loader.

* using the rdataloader essentially makes the entire [data preparation](https://root.cern/doc/master/tmva100__DataPreparation_8py.html) script unnecessary as you can do both shuffling and splitting dynamically at train time

So:

* either i merge the `tmva100_DataPreparation.py` and `tmva101_Training.py` because using the `RDataLoader` we don't need both,

The same argument I made earlier still applies: even if you merge the tmva100_DataPreparation and tmva101_Training, you could just do a AsNumpy in the end, so I don't think this justifies the RDataLoader here.

* or I create a separate example inspired from this one, just with this alternative laoding mechanism

My goal at the end is to have a tutorial showing how to do XGBoost training with the RDataLoader

That's not what you show in this tutorial. You're showing how to convert ROOT data to NumPy arrays via the RDataLoader, for which I don't see why you'd do that 🙂 And now the tutorial sends the (what I think wrong) message that the RDataLoader is the right way to do this conversion.

And since the XGBoost algo is also not designed to re-read training data in each iteration, but it converts it into an internal quantized representation once in the beginning, there is also no way do directly hook in the data loader into XGBoost training.

[siliataider]

Fair enough modifying tmva101 wasn't the right approach probably, I've created a separate tutorial instead: ml_dataloader_XGBoost.py

The use case comes from workflows where users want to:

• Retrain with different shuffling seeds without regenerating intermediate files
• Stream directly from EOS without local Snapshot copies of subsets of the original dataset

You're correct that for simple one-shot loading, AsNumpy() is sufficient and simpler, however if users want to do more, like shuffling, splitting datasets without saving intermediate files, under/oversampling etc. the RDataLoader is a more convenient choice, this tutorial shows that

[guitargeek]

I would not mention tmva101. Cross-referencing between tutorials has a risk to not age well, in particular here because we definitely have to do something about tmva101: it encourages users to store experimental objects like TMVA::Experimental::RBDT in a ROOT file via ROOT.TMVA.Experimental.SaveXGBoost, without explicitly telling you to not do this for production purposes. Yes, the SaveXGBoost interface is clearly experimental, but it doesn't warn the users that the content of the generated file will also be experimental classes.

[guitargeek]

Suggested change

	| ml_dataloader_XGBoost.py | Training XGBoost directly from remote ROOT files. |
	| ml_dataloader_XGBoost.py | Training classifier models directly from remote ROOT files, shown with an XGBoost example. |

The pattern you show generalized very well to other classification algos, so I would make that clear before people ask you to re-write the same tutorial for catboost or sckit-learn algorithms

[guitargeek]

Nice, thank you! Just two small suggestions: I'd refrain from mentioning tmva101 and make it more clear that this tutorial is not XGBoost specific: you'd do exactly the same for any other classifier. Maybe even show a different one, like logistic regression from scikit learn. I'd even consider renaming the tutorial to ml_dataloader_classification.py, but actually sticking with XGBoost in the title might make it more attractive... Can't decide for myself 🙂

[github-actions]

Test Results

    23 files      23 suites   3d 12h 47m 31s ⏱️
 3 874 tests  3 873 ✅ 0 💤 1 ❌
76 227 runs  76 221 ✅ 0 💤 6 ❌

For more details on these failures, see this check.

Results for commit 391a7b2.