When taking the modulus of a negative number, a result that should be 0 appears to be stored as -0, which scarpet reports as being equal to 0 and less than 0. This does not happen with positive numbers.
3 % 3 < 0 => false
-3 % 3 == 0 => true
-3 % 3 < 0 => true
number(-3 % 3) < 0 => false
Though the third output is the incorrect one, it would appear that, for now, using number() can alleviate this in scripts. A lower level fix would be appreciated, though.

lol thats funny. Imma see what causes it rq, cos thats definitely a bug.

Ok, It seems that the bug is not in the code for the modulo operator, it must be in the '<' operator, which is a it harder to debug, but I think im getting there

Ok Im confusd now the bug has stopped occurring. what?

Does the bug reoccur if you set /carpet scriptsOptimization false?

ok I fixed it accidentally. The problem is that in % operator it uses NumericValue.getDouble, which for -3%3 returns -0 which is a thing due to IEEE 754 standard. The fix would be to replace -0 with 0, which ought to be simple. I had managed to get the bug to disappear by using getLong, which confused me until I looked at git diff. That's the fix to this bug

Fixing #842 fixes #843. I understand that the nature of #843 is deeper, but I don't believe you can obtain -0 anywhere else, and if you can - so be it - suggest fixing them on individual level, unless its not possible.

451b35b