This would also mean, decimals have to be used.

It's "funny", that Convert To Number is documented as "not precise, if you need precise, use decimal". Then why not fix it?

Taken from https://support.virinco.com/hc/en-us/articles/207424473-Comparison-Operators

Operators in NI TestStand are

Comp Operator	Logic operator	Description
EQ	==	equal
EQUAL	==	equal (only with TestStand add-on)
NE	!= / <>	not equal
GT	>	greater than
LT	<	less than
GE	>=	greater than or equal
LE	<=	less than or equal
GTLT	> AND <	between exclusive
GELE	>= AND <=	between inclusive
GELT	>= AND <	between inclusive low, exclusive high
GTLE	> AND <=	between exclusive low, inclusive high
LTGT	< OR >	not between exclusive
LEGE	<= OR >=	not between inclusive
LEGT	<= OR >	not between inclusive low, exclusive high
LTGE	< OR >=	not between exclusive low, incusive high
LOG	 	no comparison
LOG DATA	 	no comparison (only with TestStand add-on)

Which is far more comprehensive than needed imho, just for reference. EQ and NE already implemented, I have interest just in "between inclusive".

Better support for comparisons and for math in general would be great, but it's hard to decide what exactly we should do. A problem with comparisons is that the most convenient way to write them is like a > 0, but with Robot the easiest approach would be something like

Should Be Greater Than    ${a}    0

which is rather awkward and would require adding multiple separate keywords. I see two ways this problem could be solved:

1. Come up with a convenient syntax that allows using a single keyword for all comparison needs. The Browser library assertions could be used as inspiration. This new keyword could be in BuiltIn.
2. Create a new library for comparisons or for math in general. A math library could be useful even if we were able to create a dedicated comparison keyword.

Both of these solutions require careful design if they were to be incorporated with Robot Framework core, because making changes is hard due backwards compatibility reasons. I believe with both, but especially with the latter, it would be best to start with an external library. It could be developed independently on Robot's development schedule and it wouldn't have such strict backwards compatibility requirements. We could then include the library later when it's more mature, but staying as an external library could still have benefits.

Do you @ilfirin-ms have opinions or ideas related to this? Are you interested to design and implement this kind of keywords/libraries?

Unfortunately I am not that good. I would be able to do logic, but not the proper documentation/tests/etc.

Also, I wasn't thinking about external library at all.
External math library is good idea, but for another purpose, just as numpy/scipy/sympy robot wrapper for all the fancy statistical computations, digital filtering, bigger arrays processing... also I see your point from another bug, here Decimals could be incorporated from the start.

Comparison two numbers I feel should be part of standard library.

I didn't get the Browser example. It looks like "Should Be True" with extra steps (for this usage).

I agree Should Be Greater Than ${a} 0 looks awkward, yet I have no better solution in mind either,
as I understand ${number} Should Be In Range @{range} is not how core Keywords are written.
That's why I have written this bug, hoping someone had better solution.

Well, If we stayed at "Should Be True", which also look awkward, can solution be aliasing to "Check", "Verify", "Ensure", "Assert" or similar?

Check    ${a} > 0
Check    {a} <= 10

Verify    abs(a) == 5
Verify    max(@{array}) <= 2.75

Look a bit more humanly, than

Should Be True    ${a} > 0
Should Be True    {a} <= 10
Should Be True    abs(a) == 5