https://bugs.kde.org/show_bug.cgi?id=487837
--- Comment #7 from Jelle <snellejelle9...@gmail.com> ---
(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.
