KCalc sometimes (yes, sometimes) thinks that FFFFFFFFFFFFFFFF*(-1)=0. Also thinks that -(FFFFFFFFFFFFFFFE)=0. Reproducible: Always Steps to Reproduce: Example 1: 1. Start KCalc 2.11 already in HEX mode. 2. Press "F" 16 times (cutting and pasting won't behave the same, so type). 3. Type "*". 4. Type "1". 5. Click "+/-". 6. Type "Enter". 7. Result is 0. Example 2: 1. Start KCalc 2.11 already in HEX mode. 2. Type (don't paste) FFFFFFFFFFFFFFFE. 3. Type "*". 4. Type "1". 5. Type "Enter", which displays the correct result. 6. Click "+/-" several times. 7. Note toggling between FFFFFFFFFFFFFFFE and 0. Actual Results: Explained above. Expected Results: Explained above. I might add that hexadecimal negation is inconsistent: sometimes it gives me the 2's complement negative, and sometimes gives me a minus sign. I don't know how to predict which one will happen in a given case. I think it would make more sense to do 2's complement, because that's how hex is used, and never show a minus sign. BTW you might want to call it "HEX64" instead of "HEX" on the radio button, because otherwise people might not realize that you're wrapping to 64 bits; decimal doesn't do that. Either that, or have a "WRAP" indicator light up. Also, when I first installed KCalc, I entered "1.3e33" as a test value, and it suddenly because some very different number ending in "e40" as soon as I hit "+" or "*". I repeated the same experiment with the same "e40" result 2 or 3 times. But then it suddenly went away, and never came back even after reinstall. Memory corruption? BTW, "e" doesn't do the same thing as "E", which is kind of an accident waiting to happen, but that's secondary.
EDIT: "it suddenly _became_ some very different number"
Well, believe that I know what the problem is, but I'm not 100% sure if the fix will be easy. When you do 0xFFFFFFFFFFFFFFFF * -1 (or something that is mathematically equivalent), depending on if you view this as signed or unsigned math, the result may require more than 64 bits. The way kcalc does it, it does, so it displays 0. You can verify this by doing the following: 1. Start KCalc 2.11 already in HEX mode. 2. Press "F" 16 times (cutting and pasting won't behave the same, so type). 3. Type "*". 4. Type "1". 5. Click "+/-". 6. Type "Enter". 7. Result is 0. 8. Switch to Dec Mode you notice that the calculator will display: -18,446,744,073,709,551,615. However, I assume that what you expect is the equivalent to: ~0xFFFFFFFFFFFFFFFF + 1, which == 1. and that makes sense to me, so I will look into fixing the bug.
OK, I've looked into it, and here's what it boils down to. When you enter 0xFFFFFFFFFFFFFFFF, there are 2 possible meanings. 18,446,744,073,709,551,615 or -1 so when you flip the sign you either end up with: -18,446,744,073,709,551,615 or 1 The problem is that because kcalc is an arbitrary prevision calculator, when you input a number, it tends to favor considering an unsigned value (so 18,446,744,073,709,551,615 in this case). When you negate it, it negates 18,446,744,073,709,551,615, not -1 which ends up with -18,446,744,073,709,551,615. This number requires 65 bits to represent. So kcalc will only display it in Dec (arbitrary sized math mode). Perhaps there should be an option to force conversion from HEX/OCT/BIN -> DEC to be 2's compliment signed. I dunno. This one is a tough one because there is arguably two right answers.
There could be 2 modes: two's complement, or always display the sign separately. In two's complement mode, you require the user to specify a bit length (precision), and possibly also display a Carry bit in the display. For the sign+number mode, you can use arbitrary precision (same as in decimal mode, just in base 16).
Thanks for looking into this, guys. So one of the reasons that I'm interested in Kcalc is because, otherwise, it's the closest thing to a "really useful but not overly complex" calculator I've ever seen. Hopefully, in that spirit, we can fix this in a reasonable way. I can appreciate the conflict that you've exposed, with multiple ways of interpreting the same hex number. I think a dropdown to the left of "Hex" is honestly necessary. Dropdown options (abbreviate as necessary): 1. unsigned 8-bit ("unsigned8"?) 2. signed 8-bit 3. unsigned 16-bit 4. signed 16-bit (Recommended default.) 5. unsigned 32-bit 6. signed 32-bit 7. unsigned 64-bit 8. signed 64-bit 9. scientific notation (with minus signs and 2 or 3 hex digits in signed exponent) 10. float-as-hex (This is a literal display of whatever value is in the calculator, truncated to a 32-bit single-precision float. Good for floating point bitfield verification. In other words, I can see the sign, exponent, and mantissa fields, literally.) 11. double-as-hex (Same but double precision at 64 bits.) Of course, you would need to consider doing the same for "Oct" and "Bin" (careful with having enough space for 64 0s and 1s). Instead, why not keep the dropdown to the left of all these radio buttons, and have it govern whatever mode is active (except decimal, of course, in which case you could temporarily hide the dropdown and ignore it). No other calculator does this. They all seem to make arbitrary (i.e. bad) assumptions about what the user actually means. If you do it this way, then the meaning of "x" and "+" and "-" and "XOR" etc. is perfectly clear. Also, it would be cool if the dropdown highlighted the part of the display that it's concerned with. For example, if I select "unsigned 16", the low 4 digits are highlighted in red, and the higher digits are unaffected by the calculation. Signed vs. unsigned changes the highlight color. Or something like that. Hex calculation is sooooo useful to programmers as you know. Here's a good excuse to make it work in a useful way that no one else does well, so far as I'm aware. I realize that this is easier said than done, and it's your baby, not mine. But thanks for taking the time to consider the above.
Sorry, "recommended default" would be signed 64-bit, not 16-bit.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Sorry for necromancing this one. But the errors still persist. The second one: inverting (+/-) 0xFFFF FFFF FFFF FFFE should result in 0x2 and not 0x0. And the first one: 0xFFFF FFFF FFFF FFFF * (-1) should result in 0x1 not 0x0. For the first one me thinks the calculator resolves 0xFFFF FFFF FFFF FFFF * (-1) into 0xFFFF FFFF FFFF FFFF * 1 (+/-) which results (wrongly) into 0x0, see the second error. So in conclusion there seems to be a calculation error 0xFFFF FFFF FFFF FFFF (+/-) => 0x0. And there seems to be an error in the GUI: if I use plus-minus (+/-) with my pocket calculator, the key just changes the currently displayed number. And in kcalc the plus-minus key seems to resolve the calculation and then negates the solution. Which I expect to be different. If the second error can not be fixed in the Calculator class, is it appropriate to let the calculator use a different Number class - i.e. BinNumber specialized on binary calculations? best regards J-