Thanks or sharing - found some constants I didn't see for 40 years working as a physicist.

Nitpicky remark: Why do you zip a 26kB file? It takes precisely 26kB zipped as well. #)

## Constants

### Re: Constants

DM42 SN: 00041 Beta

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

### Re: Physical constants & related questions

@Walter. You are indeed right; the zip format was useless for my last program sharing, in my yesterday's post!

(see viewtopic.php?f=19&t=271#p12446)

Thanks anyway, Mr Walter, for your encouragement to my more down to earth contribution. I am wondering about what physical constants would you prefer instead of these that you didn’t encounter very often in your physicist career. As a physicist myself, I am just curious of what is superfluous or eventually more needed instead, if you or others have any good enlightening suggestions. More pertinent or specialised versions of this type of program are foreseeable (easy to develop & useful to share on this very forum), that’s why I’ve put a “0” at the end of the entitling label “Const0”.

By the way, as of today, I added a NOTE to this previous post for explaining what I believe is the inner working of these local variables (of Mr. Thomas Okken) or at least to illustrate how I used them. And this leads me to somewhat tougher (imaginative) questions for you and Mr. Pauli about the WP34s local variables implementation, and also to you and your collaborators of the 43S development team.

Note that I already appreciate and use daily this powerful RPN calculator/emulator of yours (mostly the WP34s emulator), but I never tried to program it using your different implementation of local variables (which, together with local flags, survive only within a given subroutine, if I understood well).

1) The first question is therefore the following. Would my actual DM42/Free42’s use of local variables be possible, with the same purpose, on the WP34s ? If the variables content is not maintained throughout nested subroutines, I fear that the answer would be probably no, except if I am missing something, or if another technique may be used instead (like passing them as some string or matrix arguments to a nested function ? I don’t know.).

2) Anyway, this leads me to express another (quasi android) question/suggestion in the context of the 43S development. If the answer to my previous question is possibly no (or something equivalent), would it be possible that the future introduction of 43S’s local variables might take advantage of an approach similar to Mr. Okken’s implementation ? I am just leaving this to your thought as an appealing possibility without hoping any commitment in return. (I hope this last suggestion was not too unrealistic or far-fetched...)

Thanks for your attention. Yours truly.

(see viewtopic.php?f=19&t=271#p12446)

Thanks anyway, Mr Walter, for your encouragement to my more down to earth contribution. I am wondering about what physical constants would you prefer instead of these that you didn’t encounter very often in your physicist career. As a physicist myself, I am just curious of what is superfluous or eventually more needed instead, if you or others have any good enlightening suggestions. More pertinent or specialised versions of this type of program are foreseeable (easy to develop & useful to share on this very forum), that’s why I’ve put a “0” at the end of the entitling label “Const0”.

By the way, as of today, I added a NOTE to this previous post for explaining what I believe is the inner working of these local variables (of Mr. Thomas Okken) or at least to illustrate how I used them. And this leads me to somewhat tougher (imaginative) questions for you and Mr. Pauli about the WP34s local variables implementation, and also to you and your collaborators of the 43S development team.

Note that I already appreciate and use daily this powerful RPN calculator/emulator of yours (mostly the WP34s emulator), but I never tried to program it using your different implementation of local variables (which, together with local flags, survive only within a given subroutine, if I understood well).

1) The first question is therefore the following. Would my actual DM42/Free42’s use of local variables be possible, with the same purpose, on the WP34s ? If the variables content is not maintained throughout nested subroutines, I fear that the answer would be probably no, except if I am missing something, or if another technique may be used instead (like passing them as some string or matrix arguments to a nested function ? I don’t know.).

2) Anyway, this leads me to express another (quasi android) question/suggestion in the context of the 43S development. If the answer to my previous question is possibly no (or something equivalent), would it be possible that the future introduction of 43S’s local variables might take advantage of an approach similar to Mr. Okken’s implementation ? I am just leaving this to your thought as an appealing possibility without hoping any commitment in return. (I hope this last suggestion was not too unrealistic or far-fetched...)

Thanks for your attention. Yours truly.

DM42 SN: 03090

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

### Re: Constants

Please look at the draft documentation of WP43S at/in GitLab for the constants currently provided by us (see https://gitlab.com/Over_score/wp43s/tre ... umentation). We have all constants (sic!) stored in a table and just point to them.

So far, we don't feature the Cs frequency, Wien's displacement (especially not in mK = millikelvin!), "Photon E×/\ coeff(eV*nm)", "Lum eff @ 540 THz KCD(lm/W)", "Molar mass cst " (we have the atomic mass constant instead), and the "atomic" versions of Planck's constants AFAICS.

EDIT: I'm going to add the Cs frequency.

So far, we don't feature the Cs frequency, Wien's displacement (especially not in mK = millikelvin!), "Photon E×/\ coeff(eV*nm)", "Lum eff @ 540 THz KCD(lm/W)", "Molar mass cst " (we have the atomic mass constant instead), and the "atomic" versions of Planck's constants AFAICS.

EDIT: I'm going to add the Cs frequency.

DM42 SN: 00041 Beta

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

### Re: Constants & local variable management

@Walter. Thanks Mr. Walter for your immediate and clear answer. Always appreciated.

Concerning the topic of physical constants availability, I already recognized their introduction since the summer release of your first “Pre-alpha version 2019.06” prototype of the 43S emulator (whose design is outstanding and greatly anticipated in my opinion). And, I assure you that I prefer, and still up to now, I make great use of your actual design, as it was done in the WP34s providing direct access to a huge choice of various constants referred by quite meaningful symbolic names (my students are always amazed when they suddenly see through the class projector the sudden appearance of this very long menu column, full of intriguing symbols !). And I guess that due to severe memory limitations of the WP34s, it was surely out of the question to provide any short of small description or whatsoever (but this might be not the case however in the future 43S in the eventuality that the DM42 hardware platform is used).

However, concerning the different topic of local variables management, the first question remains. In the case of the WP34s was I right to suspect a different behaviour (specifically, in the sense of the added NOTE in the following post viewtopic.php?f=19&t=271#p12446) ? In the case of the future 43S, be sure that I didn't attempt to interfere and I would totally understand if you don’t even want to comment the second question (I fully respect your actual position).

EDIT : For sure "all of you" (because you just wrote "we" as if you speak for many others) can evaluate, criticize, dispose and/or rearrange all the chosen constants as you wish, that's the idea of adapting the program to your very own specific needs. However, here are a few noticeable remarks FYI :

1) The “eV*nm” coefficient is usefull for some of us doing photoelectric effect calculations near visible light: Eph[eV] ≈ 1240/ λ[nm] the coefficient being precisely = h x c / (e x 10^9) for a matter of efficient unit conversion. As other units like eVs for the Planck constant. It is a matter of taste.

2) To the misfortune of several opponents who severely criticized the arrival of this new reform of the SI system, this strange factor Mu = 0.99999999965 g/mol = M/A emphasizes the very fact that since May 2019, molar mass M and atomic mass A are no longer equivalent since this new factor (almost negligeable in term of multiplication, I know) had to be introduced (note that before 2019, Mu was precisely 1 g/mol) due to the exact redefinition of the Avogadro#. You may confirm or verify this new fact by performing an explicit numeric confirmation. Indeed, using my newly updated program on your DM42 calculator or Free42 software, you just have to compute directly the following product : NA*u*10^3 to obtain precisely this very same factor (in g/mol) called the "Molar mass constant" (see the paragraph entitled "Post-2019 redefinition" in https://en.wikipedia.org/wiki/Molar_mass_constant). As a logical and practical consequence, this new convention imposes from now on :

M(12C) = 0.999 999 999 65 x 10^-3 x 12 kg/mol

That's why I thought it was a good idea to introduced it. But get rid of it if you think it is useless! As you can also decide that you don't need this KCD value (not very usefull, I agree) corresponding to the new luminous efficacy convention "aimed at enabling photometric measurements to be made by purely physical methods", according to https://www.bipm.org/utils/common/pdf/r ... 019-05.pdf.

3) Concerning Wien's displacement law, anyone who has a minimal knowledge of it, knows that the units of the constant is m x K (meter times Kelvin). Sorry about the possible confusion with "mK" (millikelvin, may be I should have written "Km" instead ?!!). I clearly remember, as I wrote it, that I indeed realised the possible source of confusion but I decided to rely on the reader good judgment! I choose to do so to homogenize outputs with the same writing convention everywhere, due to severe space restrictions of the alpha register. This explains why I disposed of any multiplication symbols, spaces, parenthesis and also of negative exponents using instead successive divisions for instance (I know, I dislike it too !) like : units of G : N x m^2 x kg^-2 = N x m^2 / kg^2 equivalent to (disposing of N) m^3 x kg^-1 x s^-2 = m^3 / (kg x s^2) rewritten simply with the shortest expression m^3/kg/s^2.

Otherwise feel free to ask any questions, to comment, improve or adapt the program. Positive criticisms will always be welcome.

Concerning the topic of physical constants availability, I already recognized their introduction since the summer release of your first “Pre-alpha version 2019.06” prototype of the 43S emulator (whose design is outstanding and greatly anticipated in my opinion). And, I assure you that I prefer, and still up to now, I make great use of your actual design, as it was done in the WP34s providing direct access to a huge choice of various constants referred by quite meaningful symbolic names (my students are always amazed when they suddenly see through the class projector the sudden appearance of this very long menu column, full of intriguing symbols !). And I guess that due to severe memory limitations of the WP34s, it was surely out of the question to provide any short of small description or whatsoever (but this might be not the case however in the future 43S in the eventuality that the DM42 hardware platform is used).

However, concerning the different topic of local variables management, the first question remains. In the case of the WP34s was I right to suspect a different behaviour (specifically, in the sense of the added NOTE in the following post viewtopic.php?f=19&t=271#p12446) ? In the case of the future 43S, be sure that I didn't attempt to interfere and I would totally understand if you don’t even want to comment the second question (I fully respect your actual position).

EDIT : For sure "all of you" (because you just wrote "we" as if you speak for many others) can evaluate, criticize, dispose and/or rearrange all the chosen constants as you wish, that's the idea of adapting the program to your very own specific needs. However, here are a few noticeable remarks FYI :

1) The “eV*nm” coefficient is usefull for some of us doing photoelectric effect calculations near visible light: Eph[eV] ≈ 1240/ λ[nm] the coefficient being precisely = h x c / (e x 10^9) for a matter of efficient unit conversion. As other units like eVs for the Planck constant. It is a matter of taste.

2) To the misfortune of several opponents who severely criticized the arrival of this new reform of the SI system, this strange factor Mu = 0.99999999965 g/mol = M/A emphasizes the very fact that since May 2019, molar mass M and atomic mass A are no longer equivalent since this new factor (almost negligeable in term of multiplication, I know) had to be introduced (note that before 2019, Mu was precisely 1 g/mol) due to the exact redefinition of the Avogadro#. You may confirm or verify this new fact by performing an explicit numeric confirmation. Indeed, using my newly updated program on your DM42 calculator or Free42 software, you just have to compute directly the following product : NA*u*10^3 to obtain precisely this very same factor (in g/mol) called the "Molar mass constant" (see the paragraph entitled "Post-2019 redefinition" in https://en.wikipedia.org/wiki/Molar_mass_constant). As a logical and practical consequence, this new convention imposes from now on :

M(12C) = 0.999 999 999 65 x 10^-3 x 12 kg/mol

That's why I thought it was a good idea to introduced it. But get rid of it if you think it is useless! As you can also decide that you don't need this KCD value (not very usefull, I agree) corresponding to the new luminous efficacy convention "aimed at enabling photometric measurements to be made by purely physical methods", according to https://www.bipm.org/utils/common/pdf/r ... 019-05.pdf.

3) Concerning Wien's displacement law, anyone who has a minimal knowledge of it, knows that the units of the constant is m x K (meter times Kelvin). Sorry about the possible confusion with "mK" (millikelvin, may be I should have written "Km" instead ?!!). I clearly remember, as I wrote it, that I indeed realised the possible source of confusion but I decided to rely on the reader good judgment! I choose to do so to homogenize outputs with the same writing convention everywhere, due to severe space restrictions of the alpha register. This explains why I disposed of any multiplication symbols, spaces, parenthesis and also of negative exponents using instead successive divisions for instance (I know, I dislike it too !) like : units of G : N x m^2 x kg^-2 = N x m^2 / kg^2 equivalent to (disposing of N) m^3 x kg^-1 x s^-2 = m^3 / (kg x s^2) rewritten simply with the shortest expression m^3/kg/s^2.

Otherwise feel free to ask any questions, to comment, improve or adapt the program. Positive criticisms will always be welcome.

Last edited by wiljea on Sun Nov 17, 2019 7:50 pm, edited 8 times in total.

DM42 SN: 03090

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

### Re: Constants

These products are not self-explanatory. They are not meant to be and they even cannot be IMHO. Please note that the symbols used for the constants supported are far more meaningful than just calling them by numbers (as some calculator manufacturers did not too long ago). But students dealing with a particular topic should know the usual abbreviations/symbols for "their" usual constants by heart. If not, take a quick look to the manual and you'll find what you were looking for.

This holds for the WP34S and WP31S and WP43S.

BTW, am I guessing right that your "Photon E×/\ coeff(eV*nm)" equals hc?

This holds for the WP34S and WP31S and WP43S.

BTW, am I guessing right that your "Photon E×/\ coeff(eV*nm)" equals hc?

DM42 SN: 00041 Beta

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

### Re: Constants

Yes (almost, considering units conversion), to answer your last question about the coefficient (see point 1 of the EDIT at the end of my last post).

DM42 SN: 03090

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

### Re: Constants

@wiljea: You wrote

Notations are made for good reason: They should ease reading and, in consequence, comprehending. Anyone who has a minimal knowledge of SI, and certainly every scientist, knows about writing statements as clear and unambiguous as possible. This applies to units as well, especially if there are no other typographical means for differentiation. So, Km would have been almost as wrong as mK. If space is scarce, Unicode offers a wide variety of spaces to separate one letter from an other.

Concerning Wien's displacement law, anyone who has a minimal knowledge of it, knows that the units of the constant is m x K (meter times Kelvin).

Notations are made for good reason: They should ease reading and, in consequence, comprehending. Anyone who has a minimal knowledge of SI, and certainly every scientist, knows about writing statements as clear and unambiguous as possible. This applies to units as well, especially if there are no other typographical means for differentiation. So, Km would have been almost as wrong as mK. If space is scarce, Unicode offers a wide variety of spaces to separate one letter from an other.

DM42 SN: 00041 Beta

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

### Re: Constants

I agree with you but still the DM42's alpha register doesn't provide a lot of space and I had to proceed thoroughly and rapidly (and, BTW "km" was a joke !).

HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42

(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado