Run this code:
using System;
public class App
{
public static void Main()
{
Decimal a = 57675350989891243676868034224m;
ShowModulus(a, 7);
Console.WriteLine();
ShowModulus(a, 8);
}
public static void ShowModulus(Decimal a, int m)
{
for (int i = 0; i < m; ++i)
{
a++;
Console.WriteLine("{0} % {1} = {2}", a, m, a % m);
}
}
}
And you'll get this output:
57675350989891243676868034225 % 7 = -2
57675350989891243676868034226 % 7 = -1
57675350989891243676868034227 % 7 = 0
57675350989891243676868034228 % 7 = 1
57675350989891243676868034229 % 7 = 2
57675350989891243676868034230 % 7 = 3
57675350989891243676868034231 % 7 = -3
57675350989891243676868034225 % 8 = 1
57675350989891243676868034226 % 8 = 2
57675350989891243676868034227 % 8 = 3
57675350989891243676868034228 % 8 = 4
57675350989891243676868034229 % 8 = 5
57675350989891243676868034230 % 8 = 6
57675350989891243676868034231 % 8 = 7
57675350989891243676868034232 % 8 = 0
I may not know much, but I know that something is wrong there: the way negative numbers are showing up is inconsistent. Frankly, I don't think they should be there at all, but if they are, you'd expect similar patterns between mod 7 and mod 8. Try it with numbers other than 57675350989891243676868034225, and for moduluses (moduli?) other than 7 and 8, too. It breaks for those as well.
This appears to be a bug in the Decimal.Modulus routine - caveat emptor. Oh, and it's still broken in the Whidbey version I'm running (40607). I tried to submit the bug over on the new MSDN Product Feedback Center, but I get an error every time I try to submit. D'oh!
Frankly, this would scare the crap out of me if I were writing financial or scientific software that relied on System.Decimal. In my case the apparent workaround is easy (add the modulus to the result if the result is less than zero), but my confidence in the algorithm is pretty low.