NOTICE OF DEPRECATION
This module is now deprecated and will be removed from the package in version 0.15. Write new code to use Astro::Constants or check the documentation. The IAU stopped using cgs units last century, so it's about time this module was archived.
SYNOPSIS
use strict; # important!
use Astro::Constants::MKS qw/:long/;
# to calculate the gravitational force of the Sun on the Earth in Newtons, use GMm/r^2
my $force_sun_earth = GRAVITATIONAL * MASS_SOLAR * MASS_EARTH / ASTRONOMICAL_UNIT**2;DESCRIPTION
This module provides physical and mathematical constants for use in Astronomy and Astrophysics.
The :long tag imports all the constants in their long name forms (i.e. GRAVITATIONAL). Useful subsets can be imported with these tags: :fundamental :conversion :mathematics :cosmology :planetary :electromagnetic or :nuclear. Alternate names such as LIGHT_SPEED instead of SPEED_LIGHT or HBAR instead of H_BAR are imported with :alternates. I'd like to move away from their use, but they have been in the module for years. Short forms of the constant names are included to provide backwards compatibility with older versions based on Jeremy Bailin's Astroconst library and are available through the import tag :short.
The values are stored in Physical_Constants.xml in the data directory and are mostly based on the 2014 CODATA values from NIST.
Long name constants are constructed with the constant pragma and are not interpolated in double quotish situations because they are really inlined functions. Short name constants are constructed with the age-old idiom of fiddling with the symbol table using typeglobs, e.g. *PI = \3.14159, and may be slower than the long name constants.
Why use this module
You are tired of typing in all those numbers and having to make sure that they are all correct. How many significant figures is enough or too much? Where's the definitive source, Wikipedia? And which mass does "$m1" refer to, solar or lunar?
The constant values in this module are protected against accidental re-assignment in your code. The test suite protects them against accidental finger trouble in my code. Other people are using this module, so more eyeballs are looking for errors and we all benefit. The constant names are a little longer than you might like, but you gain in the long run from readable, sharable code that is clear in meaning. Your programming errors are a little easier to find when you can see that the units don't match. Isn't it reassuring that you can verify how a number is produced and which meeting of which standards body is responsible for its value?
Trusting someone else's code does carry some risk, which you should consider, but have you also considered the risk of doing it yourself with no one else to check your work?
And plus, it's FASTER
Benchmarking has shown that the imported constants can be more than 3 times faster than using variables or other constant modules because of the way the compiler optimizes your code. So, if you've got a lot of calculating to do, this is the module to do it with.
EXPORT
Nothing is exported by default, so the module doesn't clobber any of your variables. Select from the following tags:
POD }
sub write_pod_footer { my ($fh, ) = @_;
say $fh <<POD;
$dzil_methodtag prettyThis is a helper function that rounds a value or list of values to 5 significant figures.
$dzil_methodtag precision
Give this method the string of the constant and it returns the precision or uncertainty listed.
\$rel_precision = precision('GRAVITATIONAL');
\$abs_precision = precision('MASS_EARTH');At the moment you need to know whether the uncertainty is relative or absolute. Looking to fix this in future versions.
Deprecated functions
I've gotten rid of list_constants and describe_constants because they are now in the documentation. Use perldoc Astro::Constants for that information.
SEE ALSO
Reference Documents:
REPOSITORY
* https://github.com/duffee/Astro-Constants
ISSUES
File issues/suggestions at the Github repository https://github.com/duffee/Astro-Constants. The venerable RT is the canonical bug tracker that is clocked by meta::cpan.
Using strict is a must with this code. Any constants you forgot to import will evaluate to 0 and silently introduce errors in your code. Caveat Programmer.
If you are using this module, drop me a line using any available means at your disposal, including *gasp* email (address in the Author section), to let me know how you're using it. What new features would you like to see? If you've had an experience with using the module, let other people know what you think, good or bad, by rating it at cpanratings.
Extending the data set
If you want to add in your own constants or override the factory defaults, run make, edit the PhysicalConstants.xml file and then run dzil build again. If you have a pre-existing PhysicalConstants.xml file, drop it in place before running dzil build.
Availability
the original astroconst sites have disappeared
ROADMAP
I plan to deprecate the short names and change the order in which long names are constructed, moving to a noun_adjective format. LIGHT_SPEED and SOLAR_MASS become SPEED_LIGHT and MASS_SOLAR. This principle should make the code easier to read with the most important information coming at the beginning of the name.
ASTROCONST
(Gleaned from the Astroconst home page - astroconst.org )
Astroconst is a set of header files in various languages (currently C, Fortran, Perl, Java, IDL and Gnuplot) that provide a variety of useful astrophysical constants without constantly needing to look them up.
The generation of the header files from one data file is automated, so you can add new constants to the data file and generate new header files in all the appropriate languages without needing to fiddle with each header file individually.
This package was created and is maintained by Jeremy Bailin. It's license states that it is completely free, both as in speech and as in beer.
DISCLAIMER
No warranty expressed or implied. This is free software. If you want someone to assume the risk of an incorrect value, you better be paying them.
(What would you want me to test in order for you to depend on this module?)
from Jeremy Bailin's astroconst header files
The Astroconst values have been gleaned from a variety of sources, and have quite different precisions depending both on the known precision of the value in question, and in some cases on the precision of the source I found it from. These values are not guaranteed to be correct. Astroconst is not certified for any use whatsoever. If your rocket crashes because the precision of the lunar orbital eccentricity isn't high enough, that's too bad.
ACKNOWLEDGMENTS
Jeremy Balin, for writing the astroconst package and helping test and develop this module.
Doug Burke, for giving me the idea to write this module in the first place, tidying up Makefile.PL, testing and improving the documentation.