在Python（Hill Cipher）中将float转换为int

Question

I am getting different results for conversion of float to int in my Hill Cipher code (during decryption).

Code : https://github.com/krshrimali/Hill-Cipher/blob/master/hill_cipher.py

Issue : https://github.com/krshrimali/Hill-Cipher/issues/1

Code :

# create empty plain text string
plain_text = ""
# result is a matrix [[260. 574. 439.]]
# addition of 65 because inputs are uppercase letters
for i in range(dimensions):
    plain_text += chr(int(result[0][i]) % 26 + 65)

Output : ABS

(the cipher text - encrypted text - was POH)

Result Matrix : (after multiplication of inverse with cipher key matrix)

[[ 260. 574. 539.]]

After conversion to int:

[260, 573, 538]

Can anyone explain why this happens and give a fix on this? Thanks.

Answer 1

The problem is that you're using int , which truncates toward zero.

Math with float values is inherently imprecise. If you don't understand why, the classic explanation is in What Every Computer Scientist Should Know About Floating-Point Numbers . But the short version is that every conversion and every intermediate calculation gets rounded to the nearest 52-bit fraction to the actual number. And that may mean that a calculation that would yield exactly 574 if performed with real numbers actually yields a number a tiny bit more or less than 574 when performed with float s. And if you end up with a number a tiny bit less than 574 and truncate it toward zero with int , you get 573 .

In this case, what you want to do is use round instead, which rounds to the nearest integer. As long as you can be sure that your accumulated error is never as large as 0.5, that will do what you want. And, as long as you don't pick ridiculously huge key values (which would be pointless, because you don't get any more security that way), you can be sure of that.

However, there are two things worth considering here.

From a brief scan of the Hill cipher article at Wikipedia: It designed to be performed with quick pencil-and-paper operation. First, you don't need the inverse matrix, just a matrix that's inverse mod 26, which is easier to calculate, and means you stay in smaller numbers that are less likely to have this problem. And it means you can do all the math in integers, so the problem doesn't arise in the first place: create your matrix as an array with dtype=int , and there will be no rounding issues. And, as a bonus, if you do pick ridiculously huge key values, you'll get an error instead of incorrect results. (If you want to allow such values, you'd want to store Python unlimited-size int values in a dtype=object array. But if you don't need that, it just makes things slower and more complicated.)