[BUG?] Modulus not working properly

[JelleDekkers]

When I do (7-40)%12, the answer should be 3 (according to both Google and the calculator built into Windows 10). However, Rainmeter says it's -9.

[JelleDekkers]

Is this one of those things that has been known for years but you don't fix it bcs that would break backwards compatibility for skins that take advantage of this error?

[Yincognito]

When I do (7-40)%12, the answer should be 3 (according to both Google and the calculator built into Windows 10). However, Rainmeter says it's -9.

Windows 10 calculator:

CalcMod.jpg

Mathematically, considering also the integer division operation - let's use / for that - the following MUST be true:
(a / b) * b + a % b = a (or, if you like, dividend = quotient * divisor + remainder)
Since in your case, the dividend a = (7 - 40) = -33, the divisor b = 12 and the quotient -33 / 12 = INT(-2.75) = -2, we get:
(-33 / 12) * 12 + (-33) % 12 = (-2) * 12 + (-9) = - 24 - 9 = -33
That being said, the modulo result depends on other factors as well, see below.

Google yields 3 on this one probably because the programming language its calculator is built in uses the "rule" that the modulo / remainder would have the same sign as the divisor, instead of same sign as the dividend like other languages. Bottom line, it depends on things like the remainder convention used by the programming language, the way the language rounds a negative number to get its integer part with respect to division (i.e. whether -3 or -2 would be used for -2.75), and so on. You can read about this here or here.

Rainmeter is programmed mainly in C++, thus the result, IMHO.

[JelleDekkers]

Windows 10 calculator:
CalcMod.jpg
Mathematically, considering also the integer division operation - let's use / for that - the following MUST be true:
(a / b) * b + a % b = a (or, if you like, dividend = quotient * divisor + remainder)
Since in your case, the dividend a = (7 - 40) = -33, the divisor b = 12 and the quotient -33 / 12 = INT(-2.75) = -2, we get:
(-33 / 12) * 12 + (-33) % 12 = (-2) * 12 + (-9) = - 24 - 9 = -33
That being said, the modulo result depends on other factors as well, see below.

Google yields 3 on this one probably because the programming language its calculator is built in uses the "rule" that the modulo / remainder would have the same sign as the divisor, instead of same sign as the dividend like other languages. Bottom line, it depends on things like the remainder convention used by the programming language, the way the language rounds a negative number to get its integer part with respect to division (i.e. whether -3 or -2 would be used for -2.75), and so on. You can read about this here or here.

Rainmeter is programmed mainly in C++, thus the result, IMHO.

EDIT: What version of the calculator do you have? I'm on 10.2103.8.0. I found a thread on Github from 2019 that addressed this issue, so I think you might be on a very old version.

[Yincognito]

EDIT: What version of the calculator do you have? I'm on 10.2103.8.0. I found a thread on Github from 2019 that addressed this issue, so I think you might be on a very old version.

I'm on the 10.1809.2731.0 version, so you are probably right that they "addressed" the issue in the meantime. IMHO, there is nothing to address, because both results are correct when it comes to computing, only the convention and other minor things that are used by the programming are different. Newer is not always better, and just because some calculator says so doesn't make it the only possible or correct choice.

That being said, I agree that an option to do the operation "the other way" (just as valid as the current one, in a programming environment) would be welcomed. Not sure if a different operator would be feasible, perhaps some option in the [Rainmeter] section along the lines of PositiveModulus = 0 ... 1 could be a variant that satisfies both conventions. In the meantime, getting what you want is possible by doing (I know, longer formula, but this accounts for positive dividends as well, leaving the result unchanged in that case):
(((1-Sgn(7-40))/2)*12+(7-40)%12)
or, if your dividend is always negative, just:
(12+(7-40)%12)

Other than that, I always avoid negative dividends, just for consistency, so if by any chance you have a "counter-like" operation like:
((#Value#+#Step#)%#MaxValue#)
I always write that like:
((#MaxValue#+#Value#+#Step#)%#MaxValue#)
to allow negative steps to always yield positive dividends, assuming that the absolute value of the step is less than the maximum value.

Or, the devs could just change how this works if backwards compatibility allows it and be done with it. Personally, I don't mind any variant, since as I said, I never use (and probably will never use) negative dividends in a modulus operation - it just feels "weird" to me.

[JelleDekkers]

or, if your dividend is always negative, just:
(12+(7-40)%12)

I ended up just making a conditional expression that does this when the value is negative. It's an easy fix but I was just wondering.

[Yincognito]

I ended up just making a conditional expression that does this when the value is negative. It's an easy fix but I was just wondering.

Yeah, somehow I avoided mentioning that approach since it seemed longer to me compared to the Sgn() approach at the time of writing, but I was wrong, you can't avoid repeating the tested value in something like a hypothetically longer ((7-4-13-21-2)<0:12:0)+(7-4-13-21-2)%12) or any other similar expression. A bit uncomfortable, but formulas are bound to get longer anyway, so it is what it is.