-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add momentum() function for psp #88
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far. Do you mind adding convenient defaults, e.g.
momentum(psp, dir,particle, v=Val(1))
if there is only one particle with (dir, particle)
in the psp
?
5fd63a2
to
cc6ef89
Compare
Good idea, I pushed it. |
I just realized that with the |
cc6ef89
to
d12a99a
Compare
It does not add overhead :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've one last suggested change in the error message.
4bde5b3
to
7ba8860
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for me. Thanks again for the implementation!
Adds functions ```Julia momentum(psp::AbstractPhaseSpacePoint, dir::ParticleDirection, species::AbstractParticleType, n::Val{N}) momentum(psp::AbstractPhaseSpacePoint, dir::ParticleDirection, species::AbstractParticleType, n::Int) ``` to get the momentum of the n-th particle of the given species and direction from the `AbstractPhaseSpacePoint`. I provided two overloads: One with a compile-time constant N via `Val{N}` and one with a normal `n::Int`. The first one adds no overhead and is compiled away completely, but only if the given value is actually a compile-time constant, such as a literal `1`. The second overload is implemented separately and is faster than the first when `n` is not a compile-time constant. It still takes ~40ns on my machine, versus ~1ns when the first overload is used. The first overload with a dynamic value (`Val(n)` on variable n) takes ~100ns. Currently I can't add automated unit tests here yet, since the tests are in QEDcore still.
Adds the process test from QEDcore to QEDbase in order to test the implementations relying on the process interface. Once QEDjl-project#95, QEDjl-project#90, and QEDjl-project#88 are merged, I can add tests for their functionalities here as well.
Adds functions ```Julia momentum(psp::AbstractPhaseSpacePoint, dir::ParticleDirection, species::AbstractParticleType, n::Val{N}) momentum(psp::AbstractPhaseSpacePoint, dir::ParticleDirection, species::AbstractParticleType, n::Int) ``` to get the momentum of the n-th particle of the given species and direction from the `AbstractPhaseSpacePoint`. I provided two overloads: One with a compile-time constant N via `Val{N}` and one with a normal `n::Int`. The first one adds no overhead and is compiled away completely, but only if the given value is actually a compile-time constant, such as a literal `1`. The second overload is implemented separately and is faster than the first when `n` is not a compile-time constant. It still takes ~40ns on my machine, versus ~1ns when the first overload is used. The first overload with a dynamic value (`Val(n)` on variable n) takes ~100ns. Currently I can't add automated unit tests here yet, since the tests are in QEDcore still.
Adds the process test from QEDcore to QEDbase in order to test the implementations relying on the process interface. Once QEDjl-project#95, QEDjl-project#90, and QEDjl-project#88 are merged, I can add tests for their functionalities here as well.
Adds functions
to get the momentum of the n-th particle of the given species and direction from the
AbstractPhaseSpacePoint
. I provided two overloads: One with a compile-time constant N viaVal{N}
and one with a normaln::Int
. The first one adds no overhead and is compiled away completely, but only if the given value is actually a compile-time constant, such as a literal1
.The second overload is implemented separately and is faster than the first when
n
is not a compile-time constant. It still takes ~40ns on my machine, versus ~1ns when the first overload is used. The first overload with a dynamic value (Val(n)
on variable n) takes ~100ns.Currently I can't add automated unit tests here yet, since the tests are in QEDcore still.