Suggestion: to add a "Center" range command and modify others to act algebraically & also (Bug) with units

[Wiljea]

We already have the "Size" command acting in RPN mode but not in algebraic mode and I think that this will be useful. As one can see (valid for all typenames):

7 3 →∆Range @Expecting 7±3
7±3 Size @Expecting 6
Size(7±3) @Failing 6 => "Error: Syntax error"

An algebraic use would be needed in writing examples or else, because it would allow to extract the standard uncertainty when we divide the result by 2. We know that a simple RPL program might use Range→ to do the same, but there exist circumstances where only algebraics are allowed (like in the C++ code written for scientific constant computations and also in the Equation Library).

On the other hand, if one needs instead to extract the central value, it would be nice to introduce a new command "Center" to do so in both modes (for whatever argument typename):

Center(7±3) @Failing 7 => not yet defined, but would be the same as
   7±3 Center @Failing 7 => not yet defined.

In the same order of idea, it would be nice to add an algebraic access to the four usual range commands:

→∆Range(7; 3) @Failing 7±3 => "→∆Range error: Bad argument type" to be the same as
   7 3 →∆Range @Expecting 7±3
→Range(4; 10) @Failing 4…10 => "→Range error: Bad argument type" to be the same as
   7 3 →Range @Expecting 3…7
→%Range(10; 15) @Failing 10±15% => "→%Range error: Bad argument type" the same as
   10 15 →%Range @Expecting 10±15% 
→σRange(7; 3) @Failing 7±σ3 => "→σRange error: Bad argument type" to be the same as
   7 3 →σRange @Expecting 7±σ3

And I wonder if in presence of a constant like ε₀, these functions could act differently, to write as output the associated interval. Note that this part of the suggestion is also related to a similar comment of @evgaster (in ISSUE #1615). For instance (in a uniform analog manner from one type of interval to the other):

→∆Range(ε₀) @Failing 8.85418 78188⁳⁻¹²±1.4⁳⁻²¹ F/m OR
   Ⓒε₀ →Num Ⓢε₀ →Num →∆Range @Expecting 8.85418 78188⁳⁻¹²±1.4⁳⁻²¹ F/m OR
      ε₀ Dup LibraryConstant Swap StandardUncertainty →∆Range @Expecting: same
→Range(ε₀) @Failing 8.85418 78174⁳⁻¹²…8.85418 78202⁳⁻¹² F/m OR
      ε₀ Dup LibraryConstant Swap StandardUncertainty Dup2 + UnRot - →Range 
      @Expecting 8.85418 78174⁳⁻¹²…8.85418 78202⁳⁻¹² F/m
→%Range(ε₀) @Failing 8.85418 78188⁳⁻¹²±1.58117 26932 5⁳⁻⁸% F/m OR
      ε₀ Dup LibraryConstant Swap RelativeUncertainty 100 * →%Range @But do not work !
→σRange(ε₀) @Failing 8.85418 78188⁳⁻¹²±σ1.4⁳⁻²¹ F/m OR
   Ⓒε₀ →Num Ⓢε₀ →Num →σRange @Expecting 8.85418 78188⁳⁻¹²±σ1.4⁳⁻²¹ F/m OR
      ε₀ Dup LibraryConstant Swap StandardUncertainty →σRange @Expecting: same

The first function →∆Range(ε₀) being the algebraic equivalence of the key combination "🟦ε₀" as described in ISSUE #1615. I think that will be really pertinent to be used in RPL program.

[Wiljea]

Also, we have to make sure that all these commands work when the ranges have units. For instance, one can actually verify (in DB48x v.0.9.16Z) that the command "Size" accepts ranges with units as argument but leads to a BUG since it produces an erroneous results:

26.±10. Size @Expecting 20. as expected
26.±10._m/s Size @Failing 20._m/s => this gives: 1 which is an error !