[HP Prime] Constants Library Values


Posting this with the hope that the powers that be will see it and include/update the existing constants library of the HP Prime Graphing Calculator.

HP Prime — Fundamental Physical Constants
(Source: 2010 CODATA which may be found at NIST Constants page )

The physical constants list in the HP Prime Constants library ([Shift] [Units] [Const]) is based on the 2006 CODATA values and is out of date. These values have now been superseded by the 2010 CODATA values. Nearly all of the accepted values for these frequently-used, physical constants have been altered in the most recent iteration of CODATA. This is a consequence of the continued efforts for increased precision through new and improved measurements and a more fundamental effort to reorganize the world’s measurement units-—in a way that will produce an absolute system of measurement. (For an entertaining and detailed review of the historic quest for an absolute system of measurement I recommend reading World in the Balance by Robert P. Crease.)

Here (below) are the values as they should be listed in the HP Prime’s Constants Library if it were to use the 2010 CODATA values. Where appropriate, values are reported with 16 significant digits (the same number internally stored in the WP 34s). If the HP Prime can store numbers with an excess of 12 significant digits that should certainly be done. I have also included units: should not the Constants library display units also?


NA = 6.022 141 29 E23 [Avogadro constant]

k = 1.380 6488 E-23 (J K^-1) [Boltzmann constant k=R/NA]

V_m = 22.413 968 E-3 (m3 mol^-1) [molar volume of ideal gas Vm=RT/p, where T=273.15 K, p=101.325 kPa]

R = 8.314 4621 (J mol-1 K^-1) [molar gas constant]

Std_T = 273.15 (K) [standard temperature]

Std_P = 101.325 (kPa) [standard pressure]


sigma = 5.670 373 E-8 (W m^-2 K^-4) [Stefan-Boltzmann constant]

c = 299 792 458 (m s^-1) [speed of light in vacuum, exact]

epsilon_0 = 8.854 187 817 620 393 … E-12 (F m^-1) [electric constant , exact]

mu_0 = 12.566 370 614 359 17 … E-7 (N A^-2) [magnetic constant, exact]

g = 9.806 65 (m s^-2) [standard acceleration of gravity]

G = 6.673 84 E-11 (m3 kg^-1 s^-2) [Newtonian constant of gravitation]


h =6.626 069 57 E-34 (J s) [Planck constant]

hbar = 1.054 571 726 E-34 (J s) [reduced Planck constant or Dirac constant]

q = 1.602 176 565 E-19 (C) [electron charge q=e]

me = 9.109 382 91 E-31 (kg) [electron mass]

qme = 1.758 820 088 E11 (C kg^-1) [electron charge to mass quotient]

mp = 1.672 621 777 E-27 (kg) [proton mass]

mpme = 1 836.152 672 45 [proton-electron mass ratio]

alpha = 7.297 352 5698 E-3 [fine-structure constant]

Phi = 2.067 833 758 E-15 (Wb) [magnetic flux quantum]

F = 96 485.3365 (C mol^-1) [Faraday constant]

R_infinity = 10 973 731.568 539 (m^-1) [Rydberg constant]

a_0 = 0.529 177 210 92 E-10 (m) [Bohr radius]

mu_B = 927.400 968 E-26 (J T^-1) [Bohr magneton]

mu_N = 5.050 783 53 E-27 (J T^-1) [nuclear magneton]

lambda_0 = 1 239.841 929 200 421 (nm) [1eV-photon wavelength]

f_0 = 2.417 989 349 604 730 E14 (Hz) [1eV-photon frequency]

lambda_C = 2.426 310 2389 E-12 (m) [Compton wavelength of an electron]

Note: I have used the digit-grouping number format as spelled out in the NIST Guide to SI (section 10.5.3):

10.5.3 Grouping digits
Because the comma is widely used as the decimal marker outside the United States, it should not be used to separate digits into groups of three. Instead, digits should be separated into groups of three, counting from the decimal marker towards the left and right, by the use of a thin, fixed space. However, this practice is not usually followed for numbers having only four digits on either side of the decimal marker except when uniformity in a table is desired.

76 483 522 but not: 76,483,522

43 279.168 29 but not: 43,279.168 29

8012 or 8 012 but not: 8,012

0.491 722 3 is highly preferred to: 0.4917223

0.5947 or 0.594 7 but not: 0.59 47

8012.5947 or 8 012.594 7 but not: 8 012.5947 or 8012.594 7

Note: The practice of using a space to group digits is not usually followed in certain specialized applications, such as engineering drawings and financial statements.

This would be a good method to improve legibility of larger and smaller numbers on the HP Prime in lieu of incorporating a digit grouping character. I would also like to see the leading zero return for decimal fractions.


Edited: 30 Oct 2013, 8:52 p.m.


From one Timothy to another, thanks! I'll take a look and see what needs updating.

I would like it to display the units at some point, as well as some possible other improvements.


Edited: 30 Oct 2013, 10:46 p.m.


Perhaps you could use the behavior of the HP 39gII as a starting point for some other improvements.

I am thinking broadly about the Prime’s [Units] menu as a whole and its constituent submenus: [Tools] (conversion functions), [Units] (library of stored units categorized by type), and [Const] (constants library, also categorized by type) and how they work (or do not work) together to fulfill a task.

Although I much prefer the methodology on the HP 50g (set to soft MENU) for calculations involving units, if one must use menus then it seems the HP 39gII is easier and more practicable than the HP Prime at the moment.

Some things the HP 39gII does well (not really a quote, was looking for a bullet list):

When highlighting a unit symbol in the Units menu it provides a descriptor at the bottom of the menu which is helpful. Highlight mmHg and the descriptor reminds you it is millimeter of mercury.

When highlighting a constant in the Const menu it provides a descriptor at the bottom of the menu (when Value switch is off) or the value itself (when Value switch is on): again helpful. This is similar to the functionality of the HP 50g constants library. An obvious improvement for the Prime or 39gII would be the inclusion of the units for the constant in the descriptor whether you require the units with or just the value of the selected constant.

Having previously entered the [Math] menu, upon returning to the Math/Units/Phys (toolbox equivalent) it remembers what you were doing last -- right down to the constant or unit or function you selected -- and that is where you start off again (this is especially helpful when working with units, as you will frequently and necessarily return again and again, and it is time consuming drilling down into the same unit submenu when setting up a conversion).

Leaving the HP 39gII as a model.

I most frequently visit the [Units] menu on the Prime to grab a constant for a calculation or, as the name of the menu implies, to do a unit conversion. The function I most often use from [Tools] is CONVERT. Might it occupy one of the empty soft menu positions on the touch screen? That would save time jumping from one menu to another.



... was looking for a bullet list.

Find it here: http://www.hpmuseum.org/artfmt.htm. Quite close, isn't it?




  • you are correct -- it was close;
  • must have missed the more at the end.


Thanks for pointing to CODATA 2010. Regarding CONST in the WP 34S, seems we need storing some digits more for [eps_0] and [µ_0] and two more for R_[infinity]. I didn't find any other deviations so far.

With respect to digit grouping: we'll introduce this with the 43S.



I thought we'd already done the CODATA 2010 update. Have to check the tolerances.

- Pauli


We match all digits for those three constants. µ0 is a multiple of pi, so we could extend the presented digits.

- Pauli


Hmmmh, why do I get far less than 16 digits when recalling [eps_0] or µ_0 from CONST even with DBLON set?? I'd expect more instead. FYI: 3384 emulator as well (bad?) as 3407 calculator.



We match the NIST values as presented by NIST. There are less than 16 digits presented in their listing, thus we provide less than 16 digits.

eps0 is listed as 8.854 187 817... x 10-12 F m-1. The 34S uses 8.854187817E-12.

µ0 is listed as 12.566 370 614... x 10-7 N A-2. The 34S uses 12.566370614E-7.

- Pauli


Rats! >:-( Did you notice the elipses in their listing?

Come on, µ0 is clearly stated as 4[pi]*10^(-7) N/A^2; and you don't want to tell me you set [pi]=3.141 592 653 since some folks would list it as 3.141 592 653..., do you? You know better!



Does this mean we should use values for these constants not as per the NIST listing? Despite claiming in the manual that we do?

Increasing the number of digits is just a matter of adding the extra digits to the definition. The build process will figure out that they are now double precision and allocate them as such.

- Pauli


Du musst dein Gehirn nicht abgeben, wenn du diese Liste liest.

(Attempted translation: You're still allowed to think while reading that listing).



I've done a rebuild.


Ha, what a difference today makes! Thanks Pauli & Marcus!


P.S.: But - alas - somebody forgot Z0 :-(

Edited: 1 Nov 2013, 1:30 p.m.


This is the first mention of Z0. We can't read minds, so it must have been you who forgot :)

You've got svn commit permissions. It really is just changing the constant in the source file & rebuilding.

- Pauli


You've got svn commit permissions. It really is just changing the constant in the source file & rebuilding.

I know, I know. But I still have problems committing there :-(
We can't read minds ...

Nor do I. But all of us can read formulas, can't we? ;-)

Anyway - thanks for build 3467!



Since there still seems to be some room for additional digits in the 34s firmware, I would like to express my hope that a long existing annoyance may finally be fixed as well: what do you think - how much room would be required to store all current menu positions, not just that of the last one? This would make using the 34s so much more comfortable.


still hoping for a solution.


Hallo Dieter,

One thing is storage space for constants, another thing is space for variables. Memory for variables is almost full (one bit left AFAIK). The odds for fullfilling your wish with the WP 34S are below 0.1%.



It's a trade-off between register space, program space and other info stored in RAM. Room for the firmware implementation should be available.


Fine, let's see. Ten menus with, say, up to 64 entries (is it really that much?) would require 10x 6 bits. Or let's say 64 bits. Eight bytes. That's not much. What could be sacrificed for this?



There are twenty one catalogues present in the 34S, varying in sizes ranging from 9 entries to 126:

	#entry	#bits	Catalogue
9 4 Alpha arrows
10 4 Alpha comparisons
40 6 Alpha special lower case letters
40 6 Alpha special upper case letters
26 5 Alpha subscripts
19 5 Alpha symbols
76 7 CONST
76 7 CONST with complex prefix
90 7 CONV
52 6 MODE
54 6 PROB
63 6 PROG
17 5 STAT
14 4 SUMS
38 6 TEST
14 4 X.FCN in alpha mode
24 5 X.FCN with complex prefix
105 7 X.FCN in real mode
60 6 X.FCN in integer mode
126 7 X.FCN in programming mode

total 872 118 21 catalogues in total

Of these the constants and complex constants could share an position and the upper and lower case special alpha catalogues could too -- this would cost more code space but save a few bits of RAM.

With optimal binary packing (second column) we'd require 118 bits -- fifteen bytes. This would cost plenty of code space to implement. Using seven bits per entry, means nineteen bytes at a more reasonable code space cost. One byte per entry, would be twenty one bytes.

Dropping the existing catalogue position state twelve bits are reclaimed. Plus there is one spare bit in this piece of RAM.

Any excess space would have to come out of program/return stack/statistics/register memory -- there simply isn't any other memory available.

- Pauli


All values in SI without prefixes except only Standard Pressure.
Why isn't 101325_Pa?
Using the value without dimension may it causes errors in calculations.



FWIW, it's 101 325 Pa in the WP 34S CONST catalog. And we can rightfully claim featuring the most precise values of the fundamental physical constants [eps]0, µ0, and Z0 available in a true pocket calculator.



Great post! I was just reading a couple days ago about updating the constants again, and trying to rewrite some of the constants to be EXACT in terms of other constants. Good callout!

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime Fundamental Constants Timothy Roche 7 1,268 12-04-2013, 04:49 PM
Last Post: Walter B
  Library#4 Modules mass-update and New Overlays Ángel Martin 0 524 11-09-2013, 05:55 AM
Last Post: 'Angel Martin
  [HP-Prime CAS] Vector Calculus Library CompSystems 7 1,123 10-31-2013, 12:48 PM
Last Post: Han
  Equation Library/App for the Prime Harold A Climer 3 669 10-30-2013, 10:14 AM
Last Post: CompSystems
  Equation Library on the PRIME Harold A Climer 0 385 10-26-2013, 10:01 AM
Last Post: Harold A Climer
  CASplus Library for HP-Prime CompSystems 1 483 10-05-2013, 12:44 AM
Last Post: CompSystems
  The Rich HP Calculator Library Eddie W. Shore 0 327 09-27-2013, 10:19 PM
Last Post: Eddie W. Shore
  So, latest 41CL / Library 4 config is... Gene Wright 4 796 09-22-2013, 02:59 AM
Last Post: Ángel Martin
  Cleaning exiting library programs patryk 2 485 09-14-2013, 12:36 PM
Last Post: patryk
  Problem loading library into emulator Tom Grydeland 2 536 09-08-2013, 08:42 AM
Last Post: Marcus von Cube, Germany

Forum Jump: