DTF via LoKi functors #3
Conversation
|
Here we are! So, you said that the refit is done once per variable...is there a way to do it only once? I don't know whether that is the reason, but I noticed that it gets terribly slow when you have something like 20 variables... |
|
Unfortunately, the way things are coded now it doesn't look like there's a way of only doing one refit. This is in fact one of the reasons why we decided against including Having said that, I have some time scheduled with Vanya to discuss the LoKi functors part, so I'll try to see if there's some magic incantation that I haven't thought of to bypass this problem. |
|
Ok, so for the moment I write a comment in the text, explaining that the refit is done several times and that it might take some time, and then if things change we update it accordingly ;) |
|
I added a comment on pros and cons of the two approaches. Feel free to modify it and let me know if you think it's fine ;) |
|
@apuignav I thought about this for a bit. Actually the MVADictTools might be a foundation to solve this. At least this is a LoKi-aware way to write a whole set of variables to the ntuple. Will require some coding, though to make the DTF produce a dictionary of all it's output and plug this into the dict tools (not a project for the starterkit) |
|
I agree @sneubert, but the solution is not obvious, because it requires to pass the Decay Tree Fit from functor to functor, ie, save some kind of state. I guess this is the real challenge. |
|
I guess what we would do is to not actually call the DTF from a functor (just like the BDT is not called in the functor but in the DictTool). It would actually be similar to the current TupleTool but with the added benefit that the syntax to write variables to your tree would look like LoKi functors. |
|
Yes, someone write this please! 👍 |
4 participants
No description provided.