What is concidered "relevant"? I would say be a little more precise. What other constants do you want?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
One of my unanswered questions in an earlier discussion on the Idea Exchange is what to do about physical "constants" whose scientifically understood value changes over time. Let's take a look at one of my favorite constants, Planck's, and how the accuracy of our understanding of this value has changed since 2002...
2002
6.6260693 x 10^-34 J s
2006
6.62606896 x 10^−34 J s
2010
6:62606957 x 10^-34 J s
(And don't even get me started on uncertainty in these numbers.)
From what I can tell, LabVIEW 2012 is still using the 2002 value. (Aside: This is a little surprising to me; I thought we updated the values a few years ago to the 2006 versions. Maybe we didn't. But hey, the 2002 value was apparently more accurate than the 2006 version. 🐵
What behavior would you like to see in your existing programs if we did update this value? If you've stored a lot of data derived from the 2002 value, would you want the latest LabVIEW to compute (arguably more accurate) values derived from the 2010 value? Or would you prefer the math stay the same unless you explicitly updated the constant somehow? For the naive LabVIEW user, the former is "safer"--we're giving you a different, but more accurate value without you having to do anything. For the experienced LabVIEW user, the latter is "safer", since you are in control over the change in value.
This really begs the question of whether LabVIEW should have any physical constants. Couldn't you just type in the value you want and put a label on it? If you want to update to CODATA 2010, you find those constants in your code (hopefully embedded in a read-only global, VI, or LV class) and update them.
I'd like to figure out a plan to solve this problem in a way that the community agrees with before we add a bunch more physical constants into the palettes.
I doubt many scientific constants change over time. Planks could very well be the only exception. Wouldn't it be nifty if you could right click a constant and select its version/year.
I'm all for putting all commonly used scientific constants into a palette of their own. I personally don't care if they change over time as it would have a negligible effect on what we do. If you are doing something that is truly world leading edge you would be aware of any changes to the applicable constants (and probably initiated the world wide change) that you can type it in yourself.
"All physical constants" is a tall order. I'd say there are ulmost an unlimited number of physical constants, as they tend to be created, mixed and matched to fit the purpose. On top of that comes the fact Brian mentions, that they change over time for many reasons. And no, Planck's is definetely not the only one. Why would it be? Measurement and definition of the standard second varies over time for instance, which again impacts several groups of physical constants. What about constants used in other technical fields; medicin, chemistry, math, architecture, biology etc.?
Updating this in LabVIEW to something approaching completeness would be almost impossible. Every time I see an attempt at this I see something missing (Look at Wolfram for instance). I'd definetely vote for declining this request, as it would be so much easier to just define the necessary constants and definition scope by the user on a by-project basis.
As a side note I must also add that these constants would vary in precision depending on the numeric data type you use in your application. Some of them might not even make sense within SGL, DBL or EXT precision. But which degree of uncertainty your specific application can live with can only be guessed at by NI. You're much better of doing this yourself.
I personally think that the community should create a Constant Toolkit for LabVIEW, put it in a package and host it on the LabVIEW Tools Network. This way the constants can be updated as often as the scientists decide to change their mind and we don't have to wait for the next major release of LabVIEW. Plus, only those who want the constants need to install them and the rest of the world doesn't have their palette/quick drop clogged up with hundreds of constants they don't need.
They could even be separated similar to how OpenG separates them such that different sub-packages have different classes of constants. This way the astro-physicists don't have to install chemical constants and the chemists don't have to install astronomical constants...
Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.