[Feature Request] Support for Float Numbers ROS Scripting

RouterOS Scripting
1

1. :bullseye: Introduction and Objective

We submit this proposal to address one of the oldest and most restrictive limitations in the RouterOS Scripting language (RSC): the lack of native support for floating-point numbers (Float or Decimal). The primary objective is to enable engineers to perform accurate and reliable calculations, which are fundamental to modern network management.

2. :confounded_face: The Current Problem: An Obsolete Limitation

RouterOS Scripting’s dependence on only Integers for arithmetic has been a significant weakness for years. In today's programming landscape, floating-point support is considered table stakes (a basic, expected feature). This constraint forces your users to:

  1. Lose Critical Precision: Any division operation that doesn't yield an integer results in truncation (the fractional part is simply dropped), leading to inaccurate results for sensitive calculations like bandwidth usage percentages, performance averages, and timing functions.

  2. Employ Obsolete Workarounds: Developers must resort to complex, time-consuming, and hard-to-read techniques (such as multiplying by 1000 and dividing back later) to simulate precision. This significantly slows down development and increases the potential for coding errors.

The Limitation Example: If x = 5, the expression x / 2 currently evaluates to 2 (losing 0.5), instead of the required 2.5.

3. :sparkles: Proposed Solution (Native Float Support)

We urge the development team to introduce a dedicated data type for floating-point numbers into the RouterOS scripting language.

This vital upgrade will:

  • Ensure accurate and reliable computational results suitable for a production networking environment.

  • Allow scripts to handle quantifiable data such as precise percentages and time measurements (sub-second values).

  • Align the language with current industry expectations and automation tool standards.

4. :white_check_mark: Conclusion

Addressing this long-standing limitation by supporting Float Numbers, alongside the previously proposed Compound Operators, will represent a major leap forward in the capabilities of RouterOS scripting. We highly recommend prioritizing this fundamental and overdue feature to enhance the control and automation power for network engineers globally.

Sincerely,

2

Proposed it a year ago to support, just got a standard response "we'll see what we can do".

Send this request to them directly. More requests - more chances to have this implemented.

3

I already did that (send a suggestion ticket)

4

Ehm...

5

I've already told you that RouterOS scripting isn't a programming language for creating programs as it's commonly understood.
It's precisely your perspective that's wrong from the start.

Although, obviously like more than ten years ago, I completely agree with the request.

6

Well, they've implemented exit/break/continue in just 15 years after request. So, probably we need to wait just another 5 years for floating point numbers... :roll_eyes:

7

Please note that not all processor that RouterOS runs on have FPU. The old hEX with MT7621A for example doesn't. On all those devices a software emulated floating point library will have to be added to the routeros package and will be orders of magnitude slower than integer math.

8

This function, doe some time ago, read a DWORD FLOAT and convert it on number...

9

It's not uncommon for scripting languages to not have floating point support. You can always use fixed point...

Also, beyond simple arithmetics, there are quite a few library functions which would also be expected, including string formatting and parsing.

It's a choice.

10

Another issue is this:

{ :local myVar 2.5/2; :put "$myVar $[:typeof $myVar]"; :put 12.34; :put [:typeof 12.34] };

Some alternative notation will be needed for floating point numbers.

11

Yesseeee.... Is why I use comma (like on my national language) than a dot.... :grin:

1,1 = 1 + 1/10 (as example, for RouterOS is still a string...)
1.1 = 1.0.0.1 (this really for RouterOS)

12

We cannot obtain a decimal by calculating an expression like 2.5/2 ,it will round to integer 1 ；

but system can accept the command like :beep length=1.25; Very magical ！

If I want to perform operations precise to decimals in the script，need to write a complex script to convert the format , but sometimes the conversion cannot solve it；

This is really frustrating

13

Not magic. More illusion.

beep length= takes a time type. While this does appear to have decimal values shown for millseconds. But even time type is still an integer of milliseconds sin Jan 1, 1970 (excluding leap seconds). I suppose you can do math on time... but even then still left dealing with base24 and base60 numbers in-between, and division will never result in decimal values.

:put (5s / 2s)
2
14

Perhaps esoteric, but there is another problem with supporting "float" is the decimal numbers are already a type, ip. For example,

:put (1.1 + 0.1)  
1.0.0.2

RouterOS inherits from BSD that assume a .0 for missing octets in IP address, as a shortened address similar to :: in IPv6.

Now for some countries, using , be more natural so I suppose they could support math on 2 element array where both values are numbers...

:put ((1,1) +(0,1)) 
1;2

while "safe", not sure that helps

15

Divide with bc using Pi-hole container (can be any with shell and bc package) :slight_smile:

:local div do={
  :local scl $scale
  :if ($scl = null) do={ :set scl 2 }
  :return [/container/shell cmd="bc <<< 'scale=$scl; $1/$2'" pihole as-value]
}
:put [$div 100 7]
# 14.28
:put [$div 100 7 scale=5]
# 14.28571

or just wrap function of bc command:

:local bc do={
  :return [/container/shell cmd="bc <<< '$1'" pihole as-value]
}
:local num1 "12.75"
:local num2 "15.22"
:put [$bc ("scale=2; $num1 + $num2")]
# 27.97
:set num1 "17.23534"
:set num2 "8.2345445411"
:put [$bc ("scale=10; $num1 - $num2")]
# 9.0007954589

It’s a hybrid approach but it can be useful for devices which have containers capability, generally any linux cli tool can be used like that for advanced/non rcs supported capabilities just by running some utility linux container for it.