In hamming calculations, integers are treated as bits. The hamming distance is the number of bit differences, which can be calculated as the number of non-zero bits in the xor of the two values. For the two integers you provide, the bitwise hamming distance is indeed 40.
14714557628763197901=
1100110000110100100111000011001111001001011100011101000111001101
15383788748848265778=
1101010101111110001100100101110000111010110000000111101000110010
^= 0001100101001010101011100110111111110011101100011010101111111111
which is 40 non-zero bits. The C# shown is just a fancy way of counting them.
This is not the case with strings. In the TSQL you are performing string hamming, which is classically just the number of positions at which the characters are different. Performing a classic hamming distance on those two values as strings gives:
"14714557628763197901"
"15383788748848265778"
01111111110111111111 = 18
Youre example TSQL code is performing a modified hamming calculation; to get the classic hamming distance, just remove the last two when
clauses.
To perform a binary hamming distance on bigint
in TSQL will be very hard, because TSQL does not support bitwise operations on bigint. You could, however, perform the calculation on the left and right halves separately using integer arithmetic, and then add them. The only tricky part is that damned MSB and the impact on shifting.
Performing hamming distance on a decimal is not well-defined. You would need to be more specific about what you think that means.