-
Notifications
You must be signed in to change notification settings - Fork 2
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
Hubble parametrized #31
Conversation
Can you explain this change a little more? As I understand it, a Hubble parameter comes with having a scale factor, which comes with knowing what a cosmological redshift is... So in this picture, every FLRW cosmology should be |
As in, we should package it into |
I just don't see how it could be separate from the distance functions. The Hubble function is the connection between redshift and physical time, from which you get the comoving distance. Hm, ok, on the implementation side, I see how a cosmology instance might not expose the Maybe the name sent me in the wrong direction, because it's not parametrised by the Hubble function. Perhaps |
That sounds reasonable, or what about |
Also, then I suppose we would separate out |
I think if we want to separate everything, then yes, we should separate truly everything. This is similarly more about the presence of certain methods in the object than about physics, so there probably isn't a contradiction either. I like the |
492cc30
to
889c6fc
Compare
Ok. Followup PR will separate out the Tcmb and rename the components. |
What are your thoughts on |
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #31 +/- ##
==========================================
+ Coverage 75.91% 76.59% +0.68%
==========================================
Files 12 13 +1
Lines 274 282 +8
==========================================
+ Hits 208 216 +8
Misses 66 66
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
62849f0
to
40099a1
Compare
@ntessore, ready for review. One thing I've considered changing w.r.t astropy is |
I don't see a benefit to requiring it. It might not be exposed by the underlying cosmology object, similar to the point of this PR.
I find both |
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.
LGTM. I would not have put this into its own submodule, it can just live next to the main cosmology implementation, to save the time for one more import.
When mypyc has fixed some Issues with runtime-checkable protocols we can compile this whole library into c-wheels. Long term, speed will never be an issue. |
SGTM
For v0.1 we can remove |
Sounds good. I don't know of any other, more recognisable name for |
We have |
Signed-off-by: nstarman <[email protected]>
Signed-off-by: nstarman <[email protected]>
40099a1
to
3d9f5d5
Compare
Those uppercase function names violate PEP 8 and look like constants, so that makes |
😮💨. Yeah, it's a problem with |
Signed-off-by: nstarman <[email protected]>
Signed-off-by: nstarman <[email protected]>
Co-authored-by: Nicolas Tessore <[email protected]> Signed-off-by: Nathaniel Starkman <[email protected]>
I'll do a squash commit when it's ready. |
I think the
StandardCosmology
should only be an inheritance of other components. Therefore, we should separate out the Hubble (and later the Tcmb) pieces. This PR makes the ProtocolHubbleParametrized
which holds the Hubble info.PR Checklist
CHANGES.rst
file. See existing changelog for examples.docs
folder.