Hi, kcalc cannot correctly handle binary data. Insert binary number with ctrl+v 00111100 and you get 1001001001000000, huge difference. With best regards Radius
So, the issue here is that the number is being interpreted as Octal due to the string format. Typical conventions (that are used by kcalc) echo those of programming languages. Which are that numbers which start with "0x" are hexdecimal, "0" are octal", "0b" binary. Otherwise, it assumes the current mode. So there are two workarounds for this behavior: 1. prepend a leading 0b 2. omit the leading 0's and paste while in binary mode
Hi, thanks for answer, but it is really bad behavior. I have tested windows calc -GOOD and galculator - GOOD (Are anothers? Will test them, find only 2 with this functionality). If I'm in binary mode, all inserted data (OK maybe as string) is binary, very easy and functional. With best regards Radius
Yea, this one is tough because I can see both implementations as being reasonable. As a programmer, I would expect a value of 0777 to be interpreted as octal no matter what ... because it is an octal number by convention. But you may a good point, and not everyone is a programmer. Perhaps a compromise would be to prefer using the current mode, but if that produces an invalid number (like 0x12345 in decimal mode), then fallback on the current behavior. I dunno, I'm not sure if I love that either :-/ Certainly, it is possible to make this a configurable option. So maybe that's reasonable. I'd been a while since I have been terribly active in kcalc, so bear with me while I get a bit reacquainted with the source :-).
(In reply to Evan Teran from comment #3) > Yea, this one is tough because I can see both implementations as being > reasonable. As a programmer, I would expect a value of 0777 to be > interpreted as octal no matter what ... because it is an octal number by > convention. The 0777 and similar cases could be easily handled: it contains different characters than 0-s and 1-s. I would propose the following: - If the calculator is in binary mode - And the pasted string contains only 0-s and 1-s - Then the pasted string should be interpreted as binary number If I got thumbs up for this I will came up with a patch.
Related bug: https://bugs.kde.org/show_bug.cgi?id=398849 It might be good if both cases could be handled at the same time.
Marking this confirmed, I can reproduce and agree at least an option should be present. As a network engineer, I would expect it to behave in binary, and assume leading zeros.
*** Bug 407009 has been marked as a duplicate of this bug. ***
*** Bug 410346 has been marked as a duplicate of this bug. ***
(In reply to Evan Teran from comment #3) > Yea, this one is tough because I can see both implementations as being > reasonable. As a programmer, I would expect a value of 0777 to be > interpreted as octal no matter what ... because it is an octal number by > convention. I wonder if Kcalc should try to guess what type of number was inputted at all. Hidden behavior like that can be quite confusing. By default, I would rather have to manually select the type of number I'm inputting every time over possibly committing a mistake because Kcalc guessed the number format wrong.
There's definitely a bug here. Test case: In 'numeral system mode', select 'Bin' for binary. Try pasting a string like "5". It fails with 'nan'. This indicates that the pasted number is expected to be in binary. In that case, why is a number like "011" interpreted in octal? If that was the logic, then "5" too should've been interpreted as decimal and converted to binary. In short, in binary mode, the pasted string is expected to be a binary number (since "5" is not accepted). So treating "011" as octal is definitely a bug.
*** This bug has been marked as a duplicate of bug 447347 ***