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
The code makes use of several subtypes of AbstractCosmology for different cosmological models: (Closed|Flat|Open)LCDM and (Closed|Flat|Open)WCDM. However, it seems to me that are (if any) very little advantages in doing so, while there are possible disadvantages.
There are two main reasons to have different subtypes:
The comoving_transverse_dist and comoving_volume functions are (slightly) different depending on the spatial curvature
The function a2E can be (very slightly) simplified in case of a flat universe
On the other hand, in some cases one might want to store a cosmological model in a variable, and in that case one is essentially forced to use an abstract type, with the associated penalties in terms of efficiency. Such a situation, for example, arises in case one is interested in performing an inference on the cosmological parameters: in that case one would end up by having the associated cosmological model as an abstract type, which in turns would induce type instabilities in many associated parts of the code.
For this reason, I propose to consider the use of a structure that could accommodate closed, flat, and open cosmological models. In order to avoid making breaking changes, one could add new subtypes of AbstractCosmology:
It would then be trivial to write the relevant functions by just checking the signs of Ω_k in these fields. That would allow one to write type-stable code regardless of the value of the spatial curvature. Note that by just adding these two types one would not break existing code: so, in the usual case where one fixes the cosmological model, one would work with the current types. The general cosmology types could be returned by a specific function similar to cosmology (called, for example, general_cosmology or something similar).
In case there is consensus on this, I would be happy to contribute with the relevant code.
P.S. The other alternative could be to also remove the old (Closed|Flat|Open) types: that might break current code, in case one makes explicit reference to the cosmology type, but I guess that would be a minority of situations. Still, it is probably wiser not to make breaking changes...
The text was updated successfully, but these errors were encountered:
The code makes use of several subtypes of
AbstractCosmology
for different cosmological models:(Closed|Flat|Open)LCDM
and(Closed|Flat|Open)WCDM
. However, it seems to me that are (if any) very little advantages in doing so, while there are possible disadvantages.There are two main reasons to have different subtypes:
comoving_transverse_dist
andcomoving_volume
functions are (slightly) different depending on the spatial curvaturea2E
can be (very slightly) simplified in case of a flat universeOn the other hand, in some cases one might want to store a cosmological model in a variable, and in that case one is essentially forced to use an abstract type, with the associated penalties in terms of efficiency. Such a situation, for example, arises in case one is interested in performing an inference on the cosmological parameters: in that case one would end up by having the associated cosmological model as an abstract type, which in turns would induce type instabilities in many associated parts of the code.
For this reason, I propose to consider the use of a structure that could accommodate closed, flat, and open cosmological models. In order to avoid making breaking changes, one could add new subtypes of
AbstractCosmology
:It would then be trivial to write the relevant functions by just checking the signs of
Ω_k
in these fields. That would allow one to write type-stable code regardless of the value of the spatial curvature. Note that by just adding these two types one would not break existing code: so, in the usual case where one fixes the cosmological model, one would work with the current types. The general cosmology types could be returned by a specific function similar tocosmology
(called, for example,general_cosmology
or something similar).In case there is consensus on this, I would be happy to contribute with the relevant code.
P.S. The other alternative could be to also remove the old
(Closed|Flat|Open)
types: that might break current code, in case one makes explicit reference to the cosmology type, but I guess that would be a minority of situations. Still, it is probably wiser not to make breaking changes...The text was updated successfully, but these errors were encountered: