Add PhaseSpacePoint definition

[AntonReinhard]

Proposal to fix issue #46

This branch is currently based on PR #39 and should be merged after it.

This is a draft for now, but I think it is a good compromise from the discussion in issue #46. The definition is type stable, allows some nice overloads for is_fermion and so on for the ParticleStateful objects, and takes care of preventing illegal objects in the constructors.

Creating particles is straightforward and disallows illegal configurations (electron with polarization or photon with spin):

in_el = ParticleStateful(rand(SFourMomentum), Electron(), AllSpin(), Incoming())
in_ph = ParticleStateful(rand(SFourMomentum), Photon(), AllPol(), Incoming())
out_el = ParticleStateful(rand(SFourMomentum), Electron(), AllSpin(), Outgoing())
out_ph = ParticleStateful(rand(SFourMomentum), Photon(), AllPol(), Outgoing())

in_particles_valid = SVector(in_el, in_ph)
in_particles_invalid = SVector(in_el, out_ph)

out_particles_valid = SVector(out_el, out_ph)
out_particles_invalid = SVector(out_el, in_ph)

Creating PhaseSpacePoints is similarly simple and prevents illegal configurations, e.g. incoming particles in the outgoing list, but is still reasonably fast and does not need allocations. One PhaseSpacePoint for a 2 to 2 process is 944B in memory.

julia> @benchmark PhaseSpacePoint($process, $model, $phasespace_def, $in_particles_valid, $out_particles_valid)
BenchmarkTools.Trial: 10000 samples with 991 evaluations.
 Range (min … max):  39.268 ns … 111.740 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     41.068 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   43.116 ns ±   6.557 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

   ▃▇█▆▂ ▁▂▁▁                                             ▁    ▁
  ▆███████████▇▆▆▇▆▆▆▅▅▆▆▆▅▄▅▅▄▄▆▆▆▆▆▆▇▇▆▇▇█▇▅▄▅▅▄▅▄▅▄▅▆████▇▇ █
  39.3 ns       Histogram: log(frequency) by time      70.9 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

Suggestions welcome

[szabo137]

Thank you for this!

This is not a full review of the changes, but some first obvious comments from my side.

Can you explain, why the unit tests for Julia v1.6 and v1.7 fail, but the others not? Looks a bit like an API change for @test_throws.

[AntonReinhard]

Can you explain, why the unit tests for Julia v1.6 and v1.7 fail, but the others not? Looks a bit like an API change for @test_throws.

Yeah I'm pretty sure that's what it is... I think the matching to a regex is new. I can just wrap it in a check about the Julia version, but are we sure we need to support 1.6 and 1.7 anyways? Especially when the now stable version is 1.10 already.

[szabo137]

I like the implementation, here are some comments from my side.

Furthermore, we should think about some custom Base.show methods for these nested types.

[szabo137]

Can you explain, why the unit tests for Julia v1.6 and v1.7 fail, but the others not? Looks a bit like an API change for @test_throws.

Yeah I'm pretty sure that's what it is... I think the matching to a regex is new. I can just wrap it in a check about the Julia version, but are we sure we need to support 1.6 and 1.7 anyways? Especially when the now stable version is 1.10 already.

Julia v1.6 is the defacto LTS, but you are right, the tests for v1.7 to v1.9 are somewhat arbitrary. However, I am fine with the exclusion of some tests, if there is an API change of lack of support in the respective Julia version. Therefore, there is no need to drop the support in the current status, but we should keep an eye on that.

Regarding the support of Julia v1.10, you are right, of course. There should be an issue opened on its inclusion 😉

[szabo137]

Just some minor issues. Can be merged if resolved.

[szabo137]

Btw: we must not set assignees on pull requests, because it breaks the gitlab bot somehow 🤷‍♂️

[AntonReinhard]

Oh you're right, I completely forgot

[szabo137]

Since there is no open issue for this one, I am happy to merge!