Suggestion: to produce a numeric interval in position 3 (🟦) of each constant menu

[Wiljea]

The idea to produce a numeric interval in position 3 (ex.: 🟦ε₀) of each constant menu would allow a nice integration of the calculation/presentation of constants with the interval formalism of DB48x. The user would then be able to do range computation with these intervals. In DB48x v0.9.15, position 1 gives the algebraic symbol of the constant (ex.: 'ε₀'), position 2 gives its numeric value (ex.: 🟨ε₀ executes 'Ⓒε₀' →Num Eval) & position 3 is actually empty.

This would produce on the stack either the following RPL codes, or preferably, the corresponding numeric intervals. Here are 3 examples:

'Ⓒε₀' →Num 'Ⓢε₀' →Num →∆Range Eval @Expecting 8.85418 78188⁳⁻¹²±1.4⁳⁻²¹ F/m.
'ⒸG' →Num 'ⓈG' →Num →∆Range Eval @Expecting 6.6743⁳⁻¹¹±1.5⁳⁻¹⁵ m↑3/(s↑2·kg)
'Ⓒℏ' →Num 'Ⓢℏ' →Num →∆Range Eval @Expecting 1.05457 18176 5⁳⁻³⁴±0 J·s

where 'Ⓒε₀' represents the central value of the constant & 'Ⓢε₀' its standard uncertainty to be assembled together in a drange type interval by the RPL command '→∆Range'.

To do so there are two problems that need to be addressed in priority. The first problem is the fact that the standard uncertainty of some mathematical constants is not defined properly and gives erroneous values, for instance:

'Ⓢπ' →Num Eval @Failing 0 => gives instead 3.14159 26535 9
'Ⓢe' →Num Eval @Failing 0 => gives instead 2.71828 18284 6

The second problem relates to the impossibility to execute the following simple RPL program:

π « → CstX « "Ⓒ" CstX + Text→Algebraic →Num "Ⓢ" CstX + Text→Algebraic →Num →∆Range » » Eval
@Failing 3.14159 26535 898±0 => gives instead the result seen in problem one

ε₀ « → CstX « "Ⓒ" CstX + Text→Algebraic →Num "Ⓢ" CstX + Text→Algebraic →Num →∆Range » » Eval
@Failing 8.85418 78188⁳⁻¹²±1.4⁳⁻²¹ F/m => "Text→Algebraic error: Invalid input"

ℏ « → CstX « "Ⓒ" CstX + Text→Algebraic →Num "Ⓢ" CstX + Text→Algebraic →Num →∆Range » » Eval
@Failing 1.05457 18176 4615⁳⁻³⁴±0 J·s => "Text→Algebraic error: Invalid input"

where, in debug mode, we observe that CstX contains the expression 'ε₀' rather than just the characters ε₀ (whose TypeName indicates "expression"). And surprisingly, I have the same problem with ℏ (typename: "constant") which, unlike π, is also considered in the program as the algebraic expression 'ℏ' instead of just the symbol ℏ! Why the constants π & ℏ are treated differently? This seems incoherent.

[evgaster]

The idea to produce a numeric interval in position 3 (ex.: 🟦ε₀) of each constant menu would allow a nice integration of the calculation/presentation of constants with the interval formalism of DB48x. The user would then be able to do range computation with these intervals. In DB48x v0.9.15, position 1 gives the algebraic symbol of the constant (ex.: 'ε₀'), position 2 gives its numeric value (ex.: 🟨ε₀ executes 'Ⓒε₀' →Num Eval) & position 3 is actually empty.

A very good idea.
Except that in stead of "numeric interval" it should be uncertain number. Where you use "→∆Range" you should use →σRange.

@Wiljea Jean,
You of all people now that these constants with their absolute and relative uncertainty do not represent a range of values (consisting of either in- or excluded boundaries and all values in between; likely a large set of values) but a single value which is not exactly known and for which we have an estimate of how uncertain the value is.

A range and uncertain value are different concepts.

[Wiljea]

@evgaster
In statistical terms, you are correct as long as the standard uncertainty is indeed a multiple of the standard deviation (which is not necessarily always the case). However, for me, the notation a±Δa to denote a central value and its standard uncertainty is simply a general interval form that can, if necessary, be processed either by interval arithmetic [1] (for the drange type) or by generalized superposition of uncertainties [2] (for the uncertain type). The "Cycle" function could potentially (if ISSUE #1614 is resolved as I suggest) perform the transformation from one type to the other.

Note that this notation of central value plus or minus its standard uncertainty is consistent with the approach recommended by NIST. Furthermore, when a secondary constant is calculated from statistically independent constants, approaches [1] and [2] give exactly the same result. Hence the advantage of using a more general (less restrictive) interval form.

[evgaster]

I agree "the notation a±Δa" is preferred for an uncertain number "a".
It is unfortunate that the current implementation of db48x squeezes a σ in to make it a±σΔa.
"the notation a±Δa" was already taken, by the current implementation of db48x , for a ∆range.

∆Range and %Range are "syntactic sugar" for Range.
Perhaps even all the *Range stuff is bloatware.

I would not mind to drop ∆Range and %Range.
Actually, I would not mind to drop *Range. I see little use for it. But if others do, lets keep Range.

I do want to keep "uncertain". I would very much like the external presentation a±Δa, without σ, for it.
Further I want db48x to respect the difference between range and uncertain and provide functionality appropriate for each and avoid misuse (such as: using generalized superposition of uncertainties on a range; cycling from range to uncertain).

[evgaster]

'Ⓢπ' →Num Eval @Failing 0 => gives instead 3.14159 26535 9
'Ⓢe' →Num Eval @Failing 0 => gives instead 2.71828 18284 6

The value of π and e is treated (very) special:

        // Special cases for pi and e where we have built-in constants
        if (cname->matches("π"))
            return decimal::pi();
        else if (cname->matches("e"))
            return decimal::e();

I can't find a special treatment for the uncertainty. I assume that is looked up in the table:

    "Mathematics",     nullptr,

    "π",        "3.14159",              // Evaluated specially (decimal-pi.h)
    "e",        "2.71828",              // Evaluated specially (decimal-e.h)
    "ⅈ",        "0+ⅈ1",                 // Imaginary unit

which doesn't provide a value for neither the absolute not the relative uncertainty for those constants, like:

    "Chemistry",     nullptr,

    // *Avogadro's number - Exact definition
    "NA",       "[ 6.02214076E23_mol⁻¹ "
                "  0_mol⁻¹ "
                "  0 ]",

What are the uncertainty values that should be included in the table?

Considering:

'Ⓢπ' →Num Eval @Failing 0 => gives instead 3.14159 26535 9

is a incorrect statement. That is what it shows on the stack.
But the value you get is more accurate and probably depends on accuracy settings.
What shows in edit mode is:

3.14159 26535 89793 23846 264

But have a look at src/decimal-pi.*.

[evgaster]

Why the constants π & ℏ are treated differently? This seems incoherent.

π and Pi are commands that return Ⓒπ.
If you type ε₀ or ℏ they are just characters, with TypeName --> "expression".

«
    Duplicate
    LibraryConstant
    Swap StandardUncertainty
   →σRange
»
'LibraryConstant→σRange' Store

ℏ LibraryConstant→σRange @Expecting 1.05457 18176 5⁳⁻³⁴±σ0 J·s
ε₀ LibraryConstant→σRange @Expecting 8.85418 78188⁳⁻¹²±σ1.4⁳⁻²¹ F/m
π LibraryConstant→σRange @Expecting 3.14159 26535 9±σ0

[Wiljea]

Nice little program, thanks. But, knowing the definition relation:
        Ⓒε₀=1/(Ⓒμ₀*Ⓒc²
and using the following definition instead of yours:

«
    Duplicate
    LibraryConstant
    Swap StandardUncertainty
   →∆Range
»
'LibraryConstant→ΔRange' Store
μ₀ LibraryConstant→ΔRange @Expecting 0.00000 12566 37±2.⁳⁻¹⁶ H/m

you can easily calculate the drange associated to ε₀ using directly interval arithmetic:

    μ₀ LibraryConstant→ΔRange 'Ⓒc²' →Num × Inv RngRnd '1_F/m' Convert 
            @Expecting 8.85418 78188⁳⁻¹²±1.4⁳⁻²¹ F/m

which is the same as ε₀ LibraryConstant→ΔRange (see below for the RPL command RngRnd). This emphasizes the fact that the use of drange with interval arithmetic is somehow simpler.

NOTE: the RngRnd command is the following:

«
	@ Rounding Program RngRnd: 2 SFs for std uncertainty b & same ending decimal position for a in drange type a±b. The command works for all interval types.
	Duplicate TypeName
	@ Extracting Range units if present
	if
		"unit" =
	then
		Duplicate 1 Swap →Unit Swap Object→ Drop Swap
	else
		1
	end 0
	→ NumberUnits RangeType
	«
		case
			@Convert all types to range type X1…X2 (and also 2 decimals X & Δ)
			Duplicate TypeName "drange" =
			then
				Cycle Cycle "drange" 'RangeType' Store
			end
			Duplicate TypeName "prange" =
			then
				Cycle "prange" 'RangeType' Store
			end
			Duplicate TypeName "range" =
			then
				"range" 'RangeType' Store
			end
			Duplicate TypeName "uncertain" =
			then
				Object→ →∆Range Cycle Cycle "uncertain" 'RangeType' Store
			end
			@Case of 2 decimals (X & Δ) considered as elements of a drange type X±Δ
			→ X ∆
			«
				" " X UnitValue ∆ UnitValue - + "…" + X UnitValue ∆ UnitValue + + Text→
			»
			"drange" 'RangeType' Store
		end
		@Rounding std uncertainty at 2 SD’s & the central value at the same ending decimal
		Object→ Duplicate2 + 2 ÷ UnRot Swap - 2 ÷ -2 Round Duplicate UnRot StdRnd Swap
		case
			RangeType "drange" =
			then
				→∆Range NumberUnits ×
			end
			RangeType "prange" =
			then
				→∆Range Cycle NumberUnits ×
			end
			RangeType "range" =
			then
				→∆Range Cycle Cycle NumberUnits ×
			end
			RangeType "uncertain" =
			then
				→σRange NumberUnits ×
			end
		end
	»
» 'RngRnd' Sto