[FEEDBACK] The :math function should be better-specified

[sffc]

As far as I can tell, in registry.md, the :math function allows for arbitrary addition and subtraction.

I think this is a problem: it can run into the floating-point math problems well known to most programmers, such as 0.1 + 0.2 != 0.3. For example, a message of the following form does not have well-defined behavior:

.input {$num :number}
.local $num_adjusted = {$num :math subtract=0.1}
.match $num_adjusted
0.1 {{...}}
0.2 {{...}}
0.3 {{...}}
*   {{...}}

Are there any use cases for this function other than adding or subtracting integers?

I suggest changing the function to restrict the domain to integers and defining that the math operates as if on decimal values. So, for example, {1.234 :math subtract=1} should be guaranteed to return 0.234.

[eemeli]

The add and subtract option values are digit size options, which have integer values and for which e.g. subtract=0.1 would result in a Bad Option error.

Furthermore, the :math resolved value is defined by incrementing or decrementing "the numeric value of the operand by the integer value of the digit size option value".

Is there some specific change that you think should be applied to this specification?

[aphillips]

I could certainly visualize having :math be extended to handle other math operations. And the ability to do arbitrary math transforms on arbitrary values certainly seems reasonable. As @eemeli points out, we carefully ducked this issue. Implementers should probably be warned about how clever we've been 🙈 in doing this, lest they try to extend the function in anticipation of future standardization. We might have used a less-suggestive name instead of :math as well.

We have outstanding issues with matching floating point values in a selector which are probably related. But these are out of scope currently.

[sffc]

If you can't select on floating point values, the risk here is lower. It might still cause the wrong plural form to be chosen or for floating point artifacts to be shown in the rendered message.

[aphillips]

If you can't select on floating point values, the risk here is lower. It might still cause the wrong plural form to be chosen or for floating point artifacts to be shown in the rendered message.

We don't currently "precisely define" how exact matching is done for floating point values. Note that plural rules still apply and can work on non-integer values. It's also permissible that implementations match the value 1.2 to the key 1.2 (or similar). We just have not agreed on the key syntax for non-integer values.

And obviously there are potential issues with floating point representations and their interaction with any such specification.