[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 Gabriel Barrantes changed: What|Removed |Added CC||guimarcalsi...@gmail.com --- Comment #8 from Gabriel Barrantes --- *** Bug 465200 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 Gabriel Barrantes changed: What|Removed |Added CC||gabriel.barrantes.dev@outlo ||ok.com Assignee|evan.te...@gmail.com|gabriel.barrantes.dev@outlo ||ok.com -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #7 from Jelle --- (In reply to Evan Teran from comment #6) > I wouldn't say it is a "bug" as it is working as expected, but perhaps a > mis-feature since you're not the first to report this behavior as > undesirable, for example, 020 in octal *is* 16 decimal. > > The reason for this behavior is that conventionally the following prefixes > mean: > > 0xNNN -> hex > 0bNNN -> binary > 0NNN -> octal > 0oNNN -> a new, less ambiguous notation for octal, but not universally > prevalent > > The reason for this behavior is that people copy and paste numbers and > previously we've had bug reports where people said "I pasting 0x1234 in > decimal mode results in NaN!" So there unfortunately seems to be no behavior > that will be intuitive for everyone. Some people want it to respect the > source input format, some want to respect the chosen mode. > > All of that being said, while I was the maintainer for kcalc 20 years ago, > it's been a LONG time since I've even looked at the code. I just wanted to > chime in since I saw the email and thought I could shed light on WHY it is > happening so that other contributors who are more active will know where to > start. I could understand this in the case for Hex and binary. But I have never seen a calculator that accepts 0 as a prefix for octal. In that case is would suggest the following: * Remove the octal prefix from simple, science and statistic mode altogether. (People using these modes probably aren't using octals) * When in numeral system mode: Disable the octal prefix when binary, hex, or decimal is selected. (You already can't use the hex prefix when binary is selected and vice versa) -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #6 from Evan Teran --- I wouldn't say it is a "bug" as it is working as expected, but perhaps a mis-feature since you're not the first to report this behavior as undesirable, for example, 020 in octal *is* 16 decimal. The reason for this behavior is that conventionally the following prefixes mean: 0xNNN -> hex 0bNNN -> binary 0NNN -> octal 0oNNN -> a new, less ambiguous notation for octal, but not universally prevalent The reason for this behavior is that people copy and paste numbers and previously we've had bug reports where people said "I pasting 0x1234 in decimal mode results in NaN!" So there unfortunately seems to be no behavior that will be intuitive for everyone. Some people want it to respect the source input format, some want to respect the chosen mode. All of that being said, while I was the maintainer for kcalc 20 years ago, it's been a LONG time since I've even looked at the code. I just wanted to chime in since I saw the email and thought I could shed light on WHY it is happening so that other contributors who are more active will know where to start. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #5 from Jelle --- The problem seems to originate here: https://invent.kde.org/utilities/kcalc/-/blob/master/kcalc_parser.h?ref_type=heads#L59 The prefix for an octal number should probably be "0O" or "0o". To me it seems extremely confusing to have "0" be the octal prefix. Especially to users unfamiliar with number systems different from regular decimal. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #4 from Jelle --- (In reply to Evan Teran from comment #3) > It is interpreting the string "0101" as the OCTAL value "101", which is 64 > decimal, or 0100 0001 binary. So this means its a confirmed bug? If not why? Its also doing this in decimal 020 + 020 results in 32. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #3 from Evan Teran --- It is interpreting the string "0101" as the OCTAL value "101", which is 64 decimal, or 0100 0001 binary. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #2 from Jelle --- "010 + 1" and "1+010" also have these issues and results in "1001" just "01" strangely does not present this issue. "01 + 1" results in "10" as expected. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487837] Starting a binary number with zero shifts the first '1' 2 positions to the left
https://bugs.kde.org/show_bug.cgi?id=487837 --- Comment #1 from Jelle --- This might be related to https://bugs.kde.org/show_bug.cgi?id=485319 Inputting 00AB and pressing '=' results in 0 for me. -- You are receiving this mail because: You are watching all bug changes.
