Incorrect behavior of commands: CstName & CstValue

[Wiljea]

In the second menu of "PART" (reached on the keyboard with 🟦E ►), the commands "StdUnc" (🟨F3) & "RelUnc" (🟨F4) give respectively the correct (sometimes) standard & relative uncertainties of a constant given on the stack, but the commands "CstName" (🟨F1) & "CstValue" (🟨F2) seems to behave incorrectly or lead to error message:

'Ⓒre' →Num @Expecting  2.81794 03204 6 fm  
'Ⓒre' StdUnc @Failing 0.00000 00013 fm => 'StdUnc' not recognized
    @typing: 'Ⓒre' 🟦E ► 🟨F3 => 'Round(Round(3.42⁳⁻¹²÷α;-2)·2.81794 03204 6 fm;-2)'
            can't be computed because 'α' should be a constant 'Ⓒα'
'Ⓒre' CstName @Failing 'Classical electron radius' => 'CstName' not recognized 
    @typing: 'Ⓒre' 🟦E ► 🟨F1 => re →Num => 2.81794 03204 6 fm not the name
'Ⓒre' CstValue @Failing 2.81794 03204 6 fm => 'CstValue' not recognized
    @typing: 'Ⓒre' 🟦E ► 🟨F2 => "Drop error: Invalid or unknown constant" &
    "ConstantValue error: Invalid or unknown constant"

The same can be observed for the Rydberg constant except that in this case 'ⒸR∞' is interpreted as 'Ⓒre' which is not the same constant! But in this case 'ⒸR∞' 🟦E ► 🟨F3 => 0.00001 2 m⁻¹, we obtain the expected value.

I understand that this comes from the fact that in v0.9.14 these command are not or only partly implemented but I think that they should be equivalent to (or interpreted as):

1. for 'StdUnc' <=> append 'Ⓢ' before the constant and then execute →Num,
2. for 'RelUnc' <=> append 'Ⓡ' before the constant and then execute →Num.

[evgaster]

I noticed that the commands StandardUncertainty and RelativeUncertainty lack help information. So I can't read there what they are supposed to do.

I can imagine that they would give the respective uncertainties of a constant. I would prefer by default to keep it "symbolic" and let evaluation to a numeric value depend on various evaluation settings.

[evgaster]

I think there is an error in the definition of the value for the RelativeUncertainty of re: 'ROUND(3*Ⓢα/α;-2)'.

Shouldn't that be 'ROUND(3*Ⓢα/Ⓒα;-2)'?

[evgaster]

I also noticed a strange value for the label above rp.
The definition seems to be missing a value for the label.
Also the value and the StandardUncertainty seem incorrect.
There are -16 power numbers that are missing the 10 base.

[Wiljea]

As far as I can see in: db48x/src
/constants.cc,
the code seems perfectly correct to me:
    // *Proton charge radius - Measurement
     "rp", "[ 8.4075-16_m "
                    " 0.0064-16_m "
                    " 'ROUND(Ⓢrp/Ⓒrp;-2)' ]",
This is adequately written and the values are in conformity with CODATA2022. So, I don't know what happens when this code is executed once, at startup or at the moment when the application is constructed. Is it due to some sort of memory corruption? I don't know. I think that @c3d must have a look.

[Wiljea]

In the case of Ⓒre, the code (located at the same place) is:
    // Classical electron radius - Calculation from measurement
     "re", "[ 'CONVERT(Ⓒα²Ⓒa0;1_fm)' "
                    " 'ROUND(ⓇreⒸre;-2)' "
                    " 'ROUND(3Ⓢα/α;-2)' "
                    " 2.818 fm ]",
You're right, the third line should be:
                    " 'ROUND(3*Ⓢα/Ⓒα;-2)' "
and gives: 4.7e-10 in conformity with CODATA2022. I just had a quick look at all other constants and it seems that there is no other missing character (Ⓒ, Ⓢ & Ⓡ).

[evgaster]

Then you need to take a more closer look at the "code" for rp.
I my view it should be:

    // *Proton charge radius - Measurement
    "rp",       "[ 8.4075⁳-16_m "
                "  0.0064⁳-16_m "
                "  'ROUND(Ⓢrp/Ⓒrp;-2)' "
                "  0.841 fm ]",

Notice the ''⁳" before the "-16". Compare with e.g. a0
Notice the 4th line.

[evgaster]

By the way fixing the values for re and rp, doesn't solve the CstName & CstValue issue.

There definitely is a lookup issue.

[evgaster]

The label for the Thomson cross-section = 6.652⁳⁻²⁹ m↑2.
The unit doesn't look good that way.

[evgaster]

a bit of testing with test definitions of re and rp

rp on the stack
StdUnc replaces it with the value
rp on the stack
RelUnc replaces it with the value

rp on the stack
CstValue gives weird results. I just now got "Drop error: Invalid or unknown constant".
After hitting EXIT I got "ConstantValue error: Invalid or unknown constant".

There is something wrong with the lookup but also with the error recovery.
If the previous command isn't Drop but Duplicate I get "Duplicate error: Invalid or unknown constant" in stead. So the error seems te refer to the previous successful command.

[evgaster]

rp on the stack
CstName adds re to the stack.

Even with pi on the stack ...
CstName adds re to the stack.

Even with c on the stack ...
CstName adds re to the stack.

Looks like a pattern.

[evgaster]

Changed the label for the Thomson cross-section to 6.652⁳⁻²⁹ m² but it still shows up as 6.652⁳⁻²⁹ m↑2. I don't understand the menu label rendering.

[evgaster]

@Wiljea

Jean can you point me to user and design documentation for the commands:

• ConstantName
• ConstantValue
• StandardUncertainty
• RelativeUncertainty

That would help understand what they are supposed to do. I can guess and try to reverse engineer from the code but that is not the right way.
Documentation would help further investigation.

[evgaster]

I put some test constants in config/constants.csv. With those the behaviour is the same as with the builtin constants.

• ConstantName --> puts re on the stack
• ConstantValue --> gives the twisted 2 errors
• StandardUncertainty --> removes top of the stack; puts corresponding StandardUncertainty on the stack
• RelativeUncertainty --> removes top of the stack; puts corresponding RelativeUncertainty on the stack

By the way "re" happens to be the value of the label of F1. Coincidence?