Discussion on new PDGID qualifiers such as is_quarkonium

Hi @HDembinski and @henryiii. I’m working towards a version 1.0 of the package, dealing with outstanding issues and committing various things I’ve had in the pipeline.

While producing for inspection a series of tables per particle “category” I realised that it might be neat to make the several “helpers” (I had to write) readily available to the user - OK, some are trivial, but not all. So I would enhance the PDGID class with several boolean functions beyond what we already have, such as is_lepton or is_diquark. This is the kind of list I’m thinking about:

- is_sm_quark
- is_sm_lepton
- is_gauge_boson_or_higgs
- is_special_particle
- is_heavy_flavor
- is_light_meson = is_meson and not is_heavy_flavor
- is_strange_meson
- is_charmed_meson
- is_charmed_strange_meson
- is_bottom_meson
- is_bottom_strange_meson
- is_bottom_charmed_meson
- is_quarkonium or is_heavy_qqbar_meson
- is_light_baryon
- is_strange_baryon
- is_charmed_baryon
- is_bottom_baryon

It’s basically giving the class a means to straightforwardly provide the classification the PDG uses in their MC numbering scheme document https://pdg.lbl.gov/2020/reviews/rpp2020-rev-monte-carlo-numbering.pdf. This can be used as usual in searches with Particle.findall(...). Adding this ensures the user does not have to implement it itself and may also prevent silly bugs …

What do you think? Thanks.

[HDembinski]

I am on the fence on this. I can see how these are useful, but if you add these, you are adding a lot of redundant interface. Users should be empowered to compose these filters by themselves. The consensus in books on design and programming is that redundancy should generally be avoided, because it easily gets out of hand and it adds “noise” to an otherwise clear and concise interface. More interface requires more documentation and testing. Plus, it can make it overwhelming to learn a tool which has a lot of interface that is actually redundant (you won’t realize this on first glance).

I would rather spend a section in the docs to teach users how to compose these queries instead of adding pre-defined filters.

[henryiii]

(I agree too)