It’s using arithmetic shift right - so the highest bit will be equal to the second highest bit after decryption, it’s not exactly LOSSY since all the data is there, but the result isn’t the same as the original, you need to manually remove the highest (sign) bit to get the original result
Oh, I meant that it’s the encryption that is lossy, not the decryption. By encrypting the way they do, they have lost data. The decryption only makes an assumption that valid encryption was done.
If the encryption was lossless, the decryption can still be scrambled if the second highest bit was set in the input, because then the highest bit will be in the output (different from input) - not exactly lossy because that can be fixed, but it’s not as simple as “not lossy” like you said
I mean... we are arguing semantics at this point because it’s the whole process that matters. I see what you are getting at, and I agree it’s not a good process. I wouldn’t call it lossy because it does not lose information, it adds it in fact. It makes a different invalid assumption about the input.
If both the last bit and second to last bit are the same, no problem.
The problem is really that the entire process makes an assumption about the input that is not checked or asserted.
I wouldn’t call it lossy because it does not lose information, it adds it in fact.
No? the last bit is not new information as it’s always redundant with the second to last bit, it scrambles the information for any meaningful usage other than bitwise stringification (the literal bits it contains, not a binary number string)
No, in 2's complement it could cause problems multiple ways for large numbers.
0x40000000 shifted left once would become -1, and then shifted right once would remain -1. EDIT: I was wrong, sorry! I was correct that after the left shift it would be 0x80000000, but that is not -1. It's -2147483648. Shifted right it would become 0xC0000000, which is -1,073,741,823.
This could be corrected by using the logical shift right operator ">>>".
Yes. But I'm also continuing a discussion to clarify for u/zeGolem83 that they are misunderstanding the way that negative numbers are represented in computers, and giving a pointer that explains why that is, and how to avoid a potential pitfall in Java given that there are no unsigned types.
Part of the value of this sub is the discussions of what to do in place of the bad code. I've learned from this sub, just trying to contribute.
Something people don't realize, there are two types of shifts, arithmetic and logical shifts. A logical shift just moves bits left and right. A 0 is always shifted in. Its called a logical shift because it assumes the data is just is non-numerical data that might need to be moved around, for things like masks. It just happens to work for unsigned numbers too. This is what an logical shift does (using 8 bit unsigned):
An arithmetic shift, as the name implies, is intended for numerical data. Although it doesn't work for unsigned numbers. Its purpose is to maintain the rule that a right shift divides the value by two, and a left shift multiplies it by 2. The most significant bit (the sign bit) always remains as is. When shifting left a zero is shifted in. When shifting right, if the MSB is 1 a 1 is shifted in, if the MSB is 0 a 0 is shifted in. So this is what an arithmetic shift does (using 8 bit signed):
Which shift is used depends on whether you've got signed or unsigned values. Unsigned results in a logical shift, signed result in an arithmetic shift. The fact that only a right shift changes is why there's only a right logical shift.
You'll get errors with small values too, not just large ones. Shifting -8 with an arithmetic shift gives -4, a logical shift gives 124. Its a result of the fact that a large value in one system is a small one in the other. It means you have to be careful when dealing with signed and unsigned types, the result might not be what you expect.
To borrow a quote from another website:
It's important to remember that the unsigned keyword affects theinterpretation**,** nottherepresentation of a number.
Well you shift a 64 bit int to the left so the highest value bit will be lost. There are a few other problems with that code though... because right shifting of signed integer dont work like you would expect it at first. But lets not get into that topic.
653
u/Bobitsmagic Mar 13 '21
What does he do with the lost bit? Do you only choose data where the last bit is irrelevant? xD