Constants - #21

Hello,

I have just a few comments; the full code is at https://github.com/phn/astropy/blob/constants-test/astropy/constants/__init__.py .

At some point it will be useful to know the source of constants. For example CODATA or Particle Data Group's compilation or from astronomy references. I thought perhaps we can have a simple number like constants that carry such information with it.

I came up with this simple sub-class of namedtuple, that will act like a constant number but with fields carrying meta-data. The number like behavior is obtained by simply adding methods such as __add__ and so on.

The definition of a constant looks like this:

wien_freq = AstroConst(val=5.8789254e10, err=0.0000053e10,
                   unit="Hz K^-1",
                   name="Wien frequency displacement law constant",
                   notes="F_max / T = wien_freq.",
                   src=_refs['nist_codata'])

The _refs dictionary stores the references. One can do computations, for example,

flux_max = wein_freq * T .

Is this an over-kill?

I think that as we add more astronomy constants, the references will become very important. I believe that one of the reasons the IAU has discontinued(?) issuing constants is because there are many reference to choose the values from, and the one to use is not obvious. For example, distance of Sun from the Galactic center.

Even conversion methods can be added that can be used, for example,

boltzmann_constant.convert("cgs")

or even,

boltzmann_constat.cgs

The conversion factors can be stored, at the module level, as nested dictionaries, with physical quantity as the main key.

For example,

......
......,
'energy': {
    # Conversion factors from
    # http://physics.nist.gov/cuu/Constants/energy.html
    'j': (1.0, None),
    'ergs': (1e7, None),
    'ev': (6.24150934e+18, 0.00000014e+18),
    'mev': (6.24150934e+24, 0.00000014e+24),
    'kg': (1.112650056e-17, None),
    # Inverse meter = Joules / (h * c).
    'im': (5.03411701e+24, 0.00000022e+24),
    'icm': (5.03411701e+22, 0.00000022e+22),
    # Hertz = Joules / h.
    'hz': (1.509190311e+33, 0.000000067e+33),
    # Kelvin = Joules / k; k = bolztman constant
    'k': (7.2429716e+22, 0.0000066e+22),
    # Atomic mass unit = Joules / (atomic_mass_unit * c^2)
    'u': (6.70053585e+9, 0.00000030e+9),
    # Hartree = Joules / (Rydberg_infinity * h * c)
    'eh': (2.29371248e+17, 0.00000010e+17),
    'info': " j: Joules\n ergs: ergs\n ev: electron-volt\n"
            " mev: mega electron-volt\n kg: kilogram\n"
            " im: inverse meter\n icm: inverse centi-meter\n"
            " hz: Hertz\n k: Kelvin\n u: atmoic mass unit\n"
            " eh: Hartree\n"
    },
   ....,

Users can access these conversion factor directly or as methods of constants.

Thanks,
Prasanth

The pull request looks good, except for one thing: __init__.py imports from both cgs and si, and because the constants all have the same name, the si import will overwrite the cgs import. I think we want the default to be cgs, so you could fix that by just killing the from .si import *

Oh, and my preference would be to have all the variables not have underscores, so as not to appear like fnctions (although that's mostly an opinion thing). Also, while technically they should all be capitalized because they're constants, I think here we break that rule, because there are clear conventions for capitalizations that are used when these constants are actually written down, and it would be too confusing to a lot of people to violate those conventions. (To be clear, you've already done that, but I see that Prasanth's version instead uses all caps in some places.)

Prasanth,

First of all, your approach here is quite clever... and not necessarily overkill, but perhaps premature. The main reason why I say that is that there is a units package in the works that we will definitely want to apply to the constants - exactly how it will be implemented is not completely decided, but it definitely needs to be compatible with the constants module. I would strongly recommend you contact Perry Greenfield about the units module, though (he's the one that's coordinating that effort), because I think you've already implemented here some of the stuff that's supposed to go there!

At the astropy meeting it was a more-or-less unanimous agreement that the interim solution would be to use this approach where the constants are stored in the typical unit systems that are encountered, at least until the units system is worked out. That way, when someone imports units and types from astropy.constants.cgs import pc it's immediately obvious in the code that they're getting it in cgs as opposed to SI or whatever.

On the other hand, I definitely like the way the approach you've described here stores the reference information and extra notes, though - you're definitely right that it would be good to keep that available programmatically. One possible approach might be to use your class as you've defined it to store the information, but remove the units part for now (until the larger unit scheme is worked out) and define the constants in the si.py and cgs.py scheme as Thomas has done. If you want to try this, I recommend creating your own pull request with the understanding that we will merge either this one or that one once we decide which is best.

Also, we definitely don't want to include all the parameters for solar system objects in the constants module - the only thing that should be here are actual constants. M_sun/L_sun, M_earth, and M_jup are a special cases here because they are used a lot in the community as though they are constants (generally as units). The solar system information should definitely live somewhere, but the more logical place is wherever the module that does things like calculating orbits ends up.

A few stylistic comment's I'd like to add about your branch though (mostly for your information):

• Implementation shouldn't go in the init.py file - only imports and docstrings. all the actual code should go in other files inside the module. So basically you would just move your init.py to something like astroconstant.py and then have from .astroconstant import * in the init.py file
• in the __repr__ function you do s = Base.__repr__(self) - you should instead use s = super(Base,self).__repr__(), as the coding standards say to always use super unless there's a specific reason not to.
• Also, see my comment above regarding the naming scheme - I think it's important that we use the same names and capitalizations that astronomers are used to seeing when defining constants.

Hello,

Thanks for all the comments.

My idea of a constants module was more like a soft copy of "Astrophysical Quantities"!! So more than constants, I had quantities in mind. I know that this is perhaps too much to ask, and is perhaps impractical.

The current version was a personal project to collect astronomical quantities, and hence the information on physical properties of planets. The orbits of planets would, of-course, be part of say, the coordinates module. But the orbital period of Jupiter, as specified by the Solar System Dynamics group, can be in constants (or quantities).

As an interim solution the current idea of splitting constants into cgs and si is the way to go. But in the "long term", we may run into problems, where the split may not be obvious: is the magnitude system cgs? Here also, I am assuming that the constants module will have quantities such as say, the magnitude of Vega in the Johnson filter, or the B-V color of Sun, or perhaps even the current estimates of the solar abundances according to paper X.

If such quantities are deemed not to be included in constants, then of-course the current split is more appropriate. I will start a branch in my fork, with my version of the AstroConst class and values defined in separate cgs and si modules. I will remove the unit conversion code, but I think the "unit" field can be retained as a meta-data field.

For the naming scheme, I am for using underscores, since they make it easier to read the name. Also, is M_sun the mass of Sun or is it the bolometric absolute magnitude of the Sun? And is year Julian year or Besselian tropical year?

Since we are still in the exploration stage, I will get started with a reasonably consistent naming scheme, and then we can make changes. So I will start with sun_mass and proton_mass, but these can later be changed to M_sun or m_p if they are more appropriate.

The branch was named "constants-test" specifically because it doesn't follow most of the AstroPy coding conventions! Thanks for pointing out the usage of super().

Thanks,
Prasanth

Ah, now that I see what you had in mind I understand your implementation better.

I see your point that it makes sense to have a unified object to store this information (including reference info and the like). So while the class is a good idea, and we should probably encourage its use if we end up adopting this solution, my main point was that many of these quantities themselves should actually be defined in whatever module is most appropriate to them. Things like e.g. magnitude of Vega do not belong in constants - that should live in a module where photometric processing is performed. constants is for quantities that don't have a specifically obvious domain.

Oh, and M_sun is solar mass (at least that's what the comment above it says).

year looks to me to be the tropical year in seconds (is that right, Thomas?) I think year probable does not belong in constants though, as it would lead to a fair amount of confusion because of precisely these ambiguities - the time module (not in yet but being worked on) can take care of that stuff.

Erik, I'm not sure I understand your first comment about the imports in __init__.py. At the moment, I'm not doing from .cgs import * (I am doing from . import cgs), so none of the variables are being overwritten. Could you point me to the file/line you are referring to?

I do like the idea of keeping some metadata in the constants, and have a few comments about that:

• Why redefine all the possible operations on constants rather than just subclassing float? For example:

  class Constant(float):
      def __init__(self, *args, **kwargs):
          self.system = "cgs"
          self.source = "CODATA"
          float.__init__(self, *args, **kwargs)
  

  works fine and acts like a float. You can also overload __repr__ and __str__ to display the meta-data.

• I don't like the name AstroConstant or variants of that because the Boltzmann constant for example is not specifically an astronomy constant. Just using something like Constant or PhysicalConstant (to differentiate from programming constants) would be better in my opinion.

• A compromise to including units before a proper unit conversion solution exists would be to use e.g. system as in my above example, and not say e.g. m/s but S.I.. Once we have the units module implemented, we can add a units field to the above object.

• I think that even if/once constants are defined with such a class, we still want to have them importable from constants.si and constants.cgs because it's still useful to have them pre-defined in several systems, so I don't see that API as being temporary.

Sorry, you're absolutely right - I saw what you wrote and somehow mentally assigned from .cgs import * ... I think at one point we had discussed doing that and hence I was expecting to see that. Your approach here I think is a good one and is fine - sorry about that!

Also, a suggestion for the __init__.py docstring:

"""
The constants module stores physical and astronomical constants.  

These constants are currently accessible in two unit systms: cgs or SI.  
These are stored as submodules (`~astropy.constants.cgs` and 
`~astropy.constants.si`) of the constants module.  Thus, the constants should
 be accessed as e.g. ``from constants.cgs import c`` or 
``from constants.cgs import c``

Notes
--------
Many of these constants make use of the 2010 CODATA recommended values [cod]_ . 

References
----------------
.. [cod] http://www.codata.org/
"""

Thanks for the docstring! I'll include that. What should we do for now regarding classes - should we use floats, a 'thin' wrapper around floats like what I showed above, or a more complete class like what Prasanth is suggesting?

Perhaps you can try doing the thin wrapper approach? I think that seems a bit cleaner to me, but it sounds like Prasanth is going to change his approach based on the above comments, and we can just see which seems to work better?

Hello,

As both of you say, the simplest thing to do right now is to have two separate modules with SI and CGS values. In fact, we should just stick to a simple list of constants as Tom has done now.

I accept that as an interim solution, since we don't have a consistent way of working with units. And additionally many of the "constants" can be defined in separate modules like time, coords, photometry, and then simply have references to them in the constants module.

In a module it will be easier to see which system is being used by looking at the import line, but this will be hard while working at the terminal. So in my opinion having classes, with built-in conversions, will be more appropriate in the long term than having separate modules. We could store instances of classes, with the appropriate units and values, in the submodules constants.si and constants.cgs, to maintain backward compatibility. Also, we can import the one we want without having to perform an additional conversion step.

My point in asking about year was not the nature of the value, but of the naming scheme: year v/s julian_year and besselian_year.

Within the two module scheme, I am for storing reference values in constants.si and then performing the conversion in constants.cgs.

I went with namedtuples because that was the first thing that came to mind: constants => immutable => tuple!

For me, most of these are issues that can be settled one way or the other; I can live with either one. But there may be users, even if they are not developers, who may have strong opinions on these.

Prasanth

I only just noticed this pull request and the ensuing discussion. I don't have too much more to add at the moment other than a +1 for using a wrapper approach. It doesn't necessarily need to be limited to floats either, though I'm not sure I can think of any examples where a float wouldn't be the most appropriate type anyways.

Before I modify the pull request to include the thin wrapper we are talking about, I just wanted to mention the scipy constants module: http://docs.scipy.org/doc/scipy/reference/constants.html - do we want to repeat constants that are already in scipy? do we want to use a system that is the same as theirs?

I think If we plan to implement the thin wrapper with source information, it makes sense to do it all internally consistently and not use the scipy constants module, given that some of those values don't have source information. Also, given that we are not requiring scipy, it might be useful to include them here on their own.

Also, a lot of the constants in the scipy module aren't relevant to astronomy... although it certainly makes sense to have a See Also section that points to scipy.constants.

Oh, but we probably should use t numpy.pi and numpy.e values, though.

About distributing constants of some sort throughout astropy: While I agree that the mass of the electron and the bolometric magnitude of the sun will usually not appear in the same formula it would be nice to have a way to import all constants in astropy in one go - it helps to "see what is there". This could be done eventually by including statements like from photometry.constants import * in astropy.constants or maybe astropy.constants.photometry = astropy.photometry.constants.

I've implemented the Constant class. Since the CODATA 2010 values are in SI, I decided for simplicity that the constants should actually be defined in S.I. and converted into cgs (trust me, it makes checking the values a lot easier...). Do you think the Constant class is an acceptable solution? You can do:

In [4]: k_B
Out[4]: <Constant: name='Boltzmann constant' value=1.3806488e-23 error=1.3e-29 system='SI' origin='CODATA 2010' >

In [5]: print k_B
  Name   = Boltzmann constant
  Value  = 1.3806488e-23
  Error  = 1.3e-29
  System = SI
  Origin = CODATA 2010

We can still discuss things like capitalization, underscores, etc., but otherwise are you happy with this system?

Also, once we have a proper units module in Astropy, we can add a units attribute that would allow 'intelligent' unit conversion. I could actually already add the units, and have them just not be 'intelligent'. Thoughts?

Also, here's a dilemma: is 'e' the electron charge, or numpy.e? (in astronomy, I'd say the former)

Why do we need np.e or np.pi at all? Since numpy is required, everyone can use numerical from there. I suggest to limit astrolib.constants to physical and astronomical constants.

@astrofrog - I would say add 'dumb' units now, as long as it won't take too much time - but make sure to put a disclaimer in the docstring that this is for informational purposes and will be changed in the future.

@hamogu - That's a good point... I was thinking people might expect pi, in particular, to be in a constants module, but it should be pretty obviously that they can find it either in numpy or in the standard library math, so perhaps it is better not to include it here. So I'd say that means astropy.constants.e should be the electron charge.

Oh, and maybe system should be unitsystem , just for clarity. Or perhaps we should ditch that attribute completely, if you implement units instead.

Also, one extra suggestion: we should set a scheme that automatically adds a last of the constants into the docstring, so we don't have to rely on people updating the docs whenever they add a new constant. (I can do this later if you'd rather not do it now, though.)

@eteq - I guess adding dumb units is fine because if someone does c in cgs times k in SI for example, it will give a float anyway, not a Constant that would need to figure out units. So it's up to the user to figure out the units of the result. I'll get rid of system too, since in some cases it doesn't even apply (e.g. Avogadro's number).

Also agree about getting rid of pi!

@hamogu - I agree that might be a good approach, but until the unit scheme is implemented, I don't think we want to guarantee that this will be the case, given that the design might end up putting this information somewhere else. In that case, we certainly don't want two (potentially) different values of au in two different places.

That is, you're probably right if its better that they stay there, but I'm just suggesting we warn anyone who's going to use this that it might change when the units are implemented.

@eteq - I don't want all values in this file, I just suggest that they can be referenced via astropy.constants.au. They can sit in any other file, as long as we do astropy.constants.au = anyotherfile.au. As a user I don't care in which file the value is actually defined. This would be analogous to many functions in scipy, e.g. scipy.sum() is not defined in scipy is is just imported from numpy, but as a user I don't care, I can write either scipy.sum or numpy.sum and get the same result (because it is the same function called by two different names).

In the same way astrolib.constants can be a one-stop-shop for constants including au, even is au is defined in any other file.

That said, there is nothing wrong with a disclaimer at this stage. Also there might be good reasons not to have au in here. That's not up to me to decide, I merely wanted to put forward a humble suggestion.

@hamogu - I agree this is a very reasonable scheme (although with the caveat that it's actually astropy.constants.cgs.au or astropy.constats.si.au that you want :) - perhaps the warning should instead just say something like "don't count on this beign a Constants object" or something like that, as it may end up a "Units" object or something like that in the future.

Alternatively, cgs.au can remain a constant (which it is) and be used by the unit conversion system? Even when the units system is implemented, it will still be true that cgs.au is a constant in cgs units :-)

You could argue that M_sun, M_earth etc. are units too and if you check, that's basically all of the 'astronomical' constants. I'd suggest that we keep these and au, kpc, pc, etc. in this module though, and have the units module use these values if necessary. Anyway, I guess this is something that can be decided later, and I would be for just putting a deprecation warning if things do change (not pre-emptively, in case we don't actually deprecate them in the end).

Last comment - the nice thing about keeping au, kpc, M_sun, etc. in constants is that with this object we can keep track of the origin of the values (because there are many definitions of these values, and origin is really important).

Right, I was just think it might be that the Units object that may or may not appear might have a different way of representing this. But I'm fine with either a warning now or just later giving a DeprecationWarning if people use it.

I just checked over all the Allen's values and saw two (related) typos that I commented on inline.

One final thought: For all the values that currently have errors of "0", perhaps the errors should be changed to .5 of the last significant digit? e.g. if the value is "1.8987e27", perhaps the error should be "0.00005e27" ?

Thanks for the comments - I fixed the units as @hamogu pointed out, I changed the Stefan-Boltzmann constant to sigma_sb, and I set the uncertainties to 0.5 times the position of the last significant digit as @eteq suggested, except for the speed of light. Even though this might not be the 'true' uncertainty, it is better than saying the uncertainty is zero.

Looks good to me as it stands.

@phn - were you planning on implementing something in a branch of your own still, or should we go ahead and merge this?

Hello,

@phn - were you planning on implementing something in a branch of your own

still, or should we go ahead and merge this?

I don't have anything to add on to the current material, since at this
stage a thin wrapper is more than enough.

Prasanth

@phn - sorry, didn't see your earlier comment until now: I don't think None or 'exact' or similar is a good idea for uncertainties, because most people that write any kind of generic code will expect uncertainty to be a number. So None or a string will cause that code to fail. As it stands now, 0 indicates 'exact', while for those with no uncertainty listed, the implied uncertainty is at the level of the last decimal point (that's what I always learned is what you assume when there's no uncertainty, anyway...).

I'm going to merge this to make it easier for some upcoming work, but if you disagree with this approach still, feel free to continue commenting and @astrofrog or I can change it directly in master.

Hello,
On Fri, Oct 28, 2011 at 3:19 AM, Erik Tollerud <
[email protected]>wrote:

@phn - sorry, didn't see your earlier comment until now: I don't think
None or 'exact' or similar is a good idea for uncertainties, because
most people that write any kind of generic code will expect uncertainty to
be a number. So None or a string will cause that code to fail. As it
stands now, 0 indicates 'exact', while for those with no uncertainty
listed, the implied uncertainty is at the level of the last decimal point
(that's what I always learned is what you assume when there's no
uncertainty, anyway...).

I agree with you on the usage aspect. But then the information begins to
diverge from what is in the reference. I would like people to be aware that
the reference does not give any information on uncertainties.

I'm going to merge this to make it easier for some upcoming work, but if
you disagree with this approach still, feel free to continue commenting and
@astrofrog or I can change it directly in master.

Comment, I shall! Hopefully, I can submit code and not just keep commenting
:)

Reply to this email directly or view it on GitHub:
#21 (comment)

Prasanth