You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, it's non-trivial and kind of ugly to pass arguments through to the calculators, as reported by @kpachal, for example when trying to have an m_isTruth flag.
There are two nicer ways to fix this I have considerd.
Fix the kind of ugly "m_calculatorName" setup to actually take the calculator object. This is probably the best...
1a) Just set the members of the calculators from the script.
Pass a dict into the calculate alg or the calculator (if we implement 1a) which allows all the derived calculators to have their own set of options saved in a std::map (translating dict -> map), or a boost variant if we want to allow any kind of key-value pair (I don't know this too well, but this is the right class to do this).
Probably the best is doing both of these, and then people could just pass the args from their run script and not fill up their headers with worthless member variables. This is probably a bit annoying to code, but probably worth it since it would be nice to be able to set these options from the python scripts but also avoid the ugly list of 100 bools that ends up plaguing many algorithm headers.
The text was updated successfully, but these errors were encountered:
Ideally if we actually wanted to do this I would probably actually use the xAODAnaHelpers algorithm class instead of the EventLoop one and put it in that class. Obviously this requires talking to the xAODAnaHelper guys and it might not be worth it (it's maybe a bit confusing to some people although I think it's a lot more powerful/flexible in the end).
Right now, it's non-trivial and kind of ugly to pass arguments through to the calculators, as reported by @kpachal, for example when trying to have an
m_isTruth
flag.There are two nicer ways to fix this I have considerd.
Fix the kind of ugly "m_calculatorName" setup to actually take the calculator object. This is probably the best...
1a) Just set the members of the calculators from the script.
Pass a dict into the calculate alg or the calculator (if we implement 1a) which allows all the derived calculators to have their own set of options saved in a std::map (translating dict -> map), or a boost variant if we want to allow any kind of key-value pair (I don't know this too well, but this is the right class to do this).
Probably the best is doing both of these, and then people could just pass the args from their run script and not fill up their headers with worthless member variables. This is probably a bit annoying to code, but probably worth it since it would be nice to be able to set these options from the python scripts but also avoid the ugly list of 100 bools that ends up plaguing many algorithm headers.
The text was updated successfully, but these errors were encountered: