Astro::Constants v0.10 release

[Boyd Duffee]

Yesterday, I uploaded a new version of Astro::Constants v0.1002 to PAUSE and the CPANTS reports are all passing.  You can get it from CPAN when it comes to a mirror near you or fresh from the repository at https://github.com/duffee/Astro-Constants  It provides physical constants useful for astronomy/astrophysics in both MKS and CGS systems.  They are also constant in that the compiler emits warnings if you try to assign to them.  The constants are available in two flavours, descriptive names like SPEED_LIGHT or shorter variable names like $A_c.  A list of the constants is at https://metacpan.org/pod/Astro::Constants

Why a new release after 13 years?  It's a simple module that I used as an example to teach myself how to use Dist::Zilla (and will use again when I get around to learning Perl6), but it's raised some interesting issues that I'd like your feedback on.

1) ** Constants aren't ** One of the big standards bodies, NIST, now releases a listing of physical values every 4 years from the Committee on Data for Science and Technology (CODATA).  One change is the Newtonian gravitational constant, G, which in 2010 was 6.67384e-11 and in 2014 is 6.67408e-11.  Both these values are within the stated uncertainty values of 1.2e-4 and 4.7e-5, so it's not controversial, but it's something that I'd never considered before.  How do you feel about your constants changing?  Does this mean that a repository update has the potential to change the results of old programs solving non-linear equations?  scipy.constants v0.16 uses CODATA 2010, while v0.17 uses CODATA 2014.  There will be another adjustment in 2018 based on a revision to the SI units.  Is there any use in being able to refer back to old values for a constant?

2)  CGS (centimetres/grams/seconds) is a system historically used by astronomy.  The 1987 version of Galactic Dynamics quoted luminosities in ergs s^-1, but moved to SI in 1998.  In 2012 (perhaps earlier), the IAU 2012 supported moving to SI.  Is there a reason to still keep those values around?  The original Astroconst header files that this module is based on was written around 1999, so maybe the time has come to deprecate.  Anyone still using it?

3) What would you want to see in this module for you to rely on it?  Is there a fear in depending on someone else's code for your values?  Is speed your most important consideration?  Does it need to be included in your distro's repository instead of CPAN?  Does it have all the constants you use?  How configurable or extensible do you prefer your modules?   Do you like long descriptive names in your calculations or are you allergic to typing?

4) Where next?  If you had to choose the future direction, which would help you more, having the precisions available to you as relative/absolute uncertainties or being able to query the units/dimensions of a constant?

I have become somewhat passionate about constants through this process, so let me know what you think either here or raise a Github Issue.  If you've used the module, tell other people what you think (good or bad) and give it a rating through the link on metacpan.

many thanks for your consideration,
Boyd

[Joel Berger]

"and will use again when I get around to learning Perl6"

I'm not sure how Dist::Zilla relates to Perl6. 

--

---
You received this message because you are subscribed to the Google Groups "The Quantified Onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to the-quantified-o...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Kline]

On Wed, Feb 24, 2016 at 6:49 AM, Boyd Duffee <boyd....@gmail.com> wrote:

Yesterday, I uploaded a new version of Astro::Constants v0.1002 to PAUSE and the CPANTS reports are all passing.  You can get it from CPAN when it comes to a mirror near you or fresh from the repository at https://github.com/duffee/Astro-Constants  It provides physical constants useful for astronomy/astrophysics in both MKS and CGS systems.  They are also constant in that the compiler emits warnings if you try to assign to them.  The constants are available in two flavours, descriptive names like SPEED_LIGHT or shorter variable names like $A_c.  A list of the constants is at https://metacpan.org/pod/Astro::Constants

Why a new release after 13 years?  It's a simple module that I used as an example to teach myself how to use Dist::Zilla (and will use again when I get around to learning Perl6), but it's raised some interesting issues that I'd like your feedback on.

1) ** Constants aren't ** One of the big standards bodies, NIST, now releases a listing of physical values every 4 years from the Committee on Data for Science and Technology (CODATA).  One change is the Newtonian gravitational constant, G, which in 2010 was 6.67384e-11 and in 2014 is 6.67408e-11.  Both these values are within the stated uncertainty values of 1.2e-4 and 4.7e-5, so it's not controversial, but it's something that I'd never considered before.  How do you feel about your constants changing?  Does this mean that a repository update has the potential to change the results of old programs solving non-linear equations?  scipy.constants v0.16 uses CODATA 2010, while v0.17 uses CODATA 2014.  There will be another adjustment in 2018 based on a revision to the SI units.  Is there any use in being able to refer back to old values for a constant?

While this isn't my area of expertise at all. I think having the "default" constant by the most current one seems "least surprising". Having a flag, or import option to use previous "versions" of the constants would maintain backcompat I think.

 

2)  CGS (centimetres/grams/seconds) is a system historically used by astronomy.  The 1987 version of Galactic Dynamics quoted luminosities in ergs s^-1, but moved to SI in 1998.  In 2012 (perhaps earlier), the IAU 2012 supported moving to SI.  Is there a reason to still keep those values around?  The original Astroconst header files that this module is based on was written around 1999, so maybe the time has come to deprecate.  Anyone still using it?

Maybe same as above? Whatever is the current standard (or most widely accepted) is the default with a flag/import option for the other system?

gizmo 

[Boyd Duffee]

On 24/02/16 15:27, Joel Berger wrote:
> "and will use again when I get around to learning Perl6"
>
> I'm not sure how Dist::Zilla relates to Perl6.

Only in the sense of they're both on my list of things to learn. The module
is small and simple so I use it as a test case

[Boyd Duffee]

On 24/02/16 15:32, Joe Kline wrote:
>> 1) ** Constants aren't ** ... Is there

>> any use in being able to refer back to old values for a constant?
>>
>>
> While this isn't my area of expertise at all. I think having the "default"
> constant by the most current one seems "least surprising". Having a flag,
> or import option to use previous "versions" of the constants would maintain
> backcompat I think.
>
>
>> 2) CGS (centimetres/grams/seconds) is a system historically used by
>> astronomy. The 1987 version of Galactic Dynamics quoted luminosities in
>> ergs s^-1, but moved to SI in 1998. In 2012 (perhaps earlier), the IAU
>> 2012 supported moving to SI. Is there a reason to still keep those values
>> around? The original Astroconst header files that this module is based on
>> was written around 1999, so maybe the time has come to deprecate. Anyone
>> still using it?
>>
>>
> Maybe same as above? Whatever is the current standard (or most widely
> accepted) is the default with a flag/import option for the other system?

I was quite inexperienced when I first wrote it and struggled with how to
provide a default. I didn't solve it at the time and just left it. I do
like the principle of least surprise, but I wondered if anyone would want to
be _always_ explicit in which system is being used in their code.

I am now thinking that the default should go into Astro::Constants, meaning I
can get rid of Astro::Constants::MKS and save most everyone 5 keystrokes and
keep Astro::Constants::CGS and start providing Astro::Constants::2010, etc.
I've expanded Issue #3 to plan for a function providing the user with the
version of the standard is being used.

Thanks for the feedback. Sometimes I just need to hear someone else say it
before it makes sense to me.

boyd

[Chris Maloney]

Interesting question! Ideally, I guess, the constants would be packaged separately from the Perl code. That way, you could leverage the versioning and archiving scheme from cpan to enable users to update when they wanted. But, not having looked at your Module, I'm not sure how much work that would be.

[Boyd Duffee]

On 24/02/16 19:36, Chris Maloney wrote:
> Interesting question! Ideally, I guess, the constants would be packaged
> separately from the Perl code. That way, you could leverage the versioning
> and archiving scheme from cpan to enable users to update when they wanted.
> But, not having looked at your Module, I'm not sure how much work that
> would be.

I've pushed all the constants into an XML file that is used to generate the
module code, so there's no problem in using multiple files to generate
different versions plus give the local admin a way of adding in their bespoke
constants. Going down this path means that the choices are made at install
time with the latest values being the default. I haven't done the work yet,
put I've planned for it to be extensible without breaking.

- boyd