CMDHELPER-3166 - Reported by Алексей.Положенцев

Code:

/clamp = >>>
@x = 0.1
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
@x = clamp(@x + 0.1, 0.1, 1)
msg('x = '.@x)
<<<

Result:

[22:51:09 INFO]: x = 0.2
[22:51:09 INFO]: x = 0.30000000000000004
[22:51:09 INFO]: x = 0.4
[22:51:09 INFO]: x = 0.5
[22:51:09 INFO]: x = 0.6
[22:51:09 INFO]: x = 0.7
[22:51:09 INFO]: x = 0.7999999999999999
[22:51:09 INFO]: x = 0.8999999999999999
[22:51:09 INFO]: x = 0.9999999999999999

Comment by PseudoKnight

The floating point precision errors? That's in Java itself. Read here:

http://forum.enginehub.org/threads/is-this-a-bug.8961/#post-15085

You can use round() if you need a nicer output.

Comment by LadyCailin

Yep, this has nothing to do with clamp, or methodscript, for that matter. One solution I have considered implementing is making the underlying data type for floats be BigDecimal, but that would seriously slow down any math related operations. Might be an additional data type in the future. C# has a data type decimal, which is probably what I would add, and make it transparently usable for most purposes, but would ultimately be a BigDecimal under the hood.

Anyways, closing this issue, because it has nothing to do with clamp, and is a larger architectural problem anyways.