- Compact style
- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
Speaker: Ida Caspary
Title: RNTupleTTreeChecker
Instead of looping the checker should just get all the fields and perform a comparison on the sets to see if any field is missing.
Checker run to compare two different RNTuples?
Does the checker also check the data?
Printing all the fields may get out of hand in case of big datasets with hundreds of fields. Maybe we can rethink the way the results of the checks are presented?
Are you planning to have a check of identity of all the values of all the fields?
Should the checker also offer a public API to access all the information programmatically? This could help experiments with more complex checking workflows.
In some cases, for example when converting TTree data to RNTuple via the RNTupleImporter, some things will change e.g. some data types (Long64_t
gets normalised) or parts of the schema itself. These changes still produce a compatible dataset although a strict comparison will report them as mismatches. Maybe we should introduce a report of these "compatible mismatches".
We should discuss what the checker should do about complex classes.
We should really strive to enable comparisons RNTuple vs RNTuple as well as TTree vs TTree.
How can we bring the checker into ROOT?