Resolved the bug related to valid_value generation in constrained parameters for IS-12/14 (MS-05)

[lo-simon]

The current logic for calculating valid_value has a mathematical flaw when dealing with a range that includes zero, especially with signed integers like the NcInt16 (16-bit) range (minimum=-32768, maximum=32767, step=1).

value_value = floor(((maximum -minimum) /2) + minimum) / step) * step + mimimum

Original formula (buggy)

valid_value = floor((((32767 - (-32768)) / 2) + (-32768)) / 1) * 1 + (-32768)
            = floor(((65535 / 2) - 32768)) * 1 - 32768
            = floor(-0.5) - 32768
            = -1 - 32768
            = -32769  # Out of range

Because the formula adds the minimum back at the very end, after already adding it inside the parentheses, that effectively doubles-counts the offset. In this specific case, the valid_value it generates is actually outside the allowed range (less than -32768).

Corrected Calculation

To find a valid midpoint that respects the step and stays within bounds, calculate the midpoint of the span, then align it with the step, starting from the minimum.

value_value = floor(((maximum - minimum) / 2) / step) * step + minimum

valid_value = floor(((32767 - (-32768)) / 2) / 1) * 1 + (-32768)
            = floor(65535 / 2) - 32768
            = 32767 - 32768
            = -1  # Within range

This result (-1) is perfectly valid and sits right in the middle of the range.