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.
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.
https://bugs.kde.org/show_bug.cgi?id=487493
--- Comment #2 from Evan Teran ---
(In reply to Antonio Rojas from comment #1)
> > 2. calculate 50 = 50 *2
>
> what exactly is this meant to compute?
I'm assuming that the reporter meant "50+50*2" because that would indeed
https://bugs.kde.org/show_bug.cgi?id=448769
--- Comment #3 from Evan Teran ---
Right. So addressing this "right" is suprisingly complex. Basically the issue
is that the code for doing arbitrary precision math has no "cancellation
points". The conventional solution to this ki
https://bugs.kde.org/show_bug.cgi?id=447347
--- Comment #3 from Evan Teran ---
Understood, unfortunately the convention for octal numbers is "starts with a
0". Admittedly, this is considered confusing to many, so much so that python
added 0o1234 as an alternative octal prefix. Per
https://bugs.kde.org/show_bug.cgi?id=447347
--- Comment #1 from Evan Teran ---
Yeah, this is a long standing thing where there's two camps.
Some people people want the input data's apparent base to be respected. So
pasting in `0x1234` will past in a hex value, even if you're
https://bugs.kde.org/show_bug.cgi?id=407318
--- Comment #5 from Evan Teran ---
I wrote the knumber library that wraps gmp in kcalc. It is definitely in need
of some modernization and perhaps arblib is worth looking into as a replacement
for it's big number capabilities.
I'll lo
https://bugs.kde.org/show_bug.cgi?id=405548
Evan Teran changed:
What|Removed |Added
CC||ete...@alum.rit.edu
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=398849
--- Comment #4 from Evan Teran ---
This particular feature has always been a bit of a sticking point because it
makes complete sense if you expect it, and is nothing but confusing if you
don't expect it.
I like S. Umar's logic in that "
https://bugs.kde.org/show_bug.cgi?id=382391
--- Comment #4 from Evan Teran ---
It has been a while since I was terribly active with kcalc. Fortunately,
Christopher has been awesome about handling the occasiobal issue that crops
up (thanks!).
I've always had mixed feeling about how to handl
https://bugs.kde.org/show_bug.cgi?id=376655
Evan Teran changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from Evan Teran
https://bugs.kde.org/show_bug.cgi?id=376655
Evan Teran changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=375681
--- Comment #3 from Evan Teran ---
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
https://bugs.kde.org/show_bug.cgi?id=375681
--- Comment #1 from Evan Teran ---
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
https://bugs.kde.org/show_bug.cgi?id=368697
--- Comment #1 from Evan Teran ---
I believe that this is an older version of kcalc as I cannot reproduce this on
my version.
However, it it worth noting that for many floating point operations, kcalc, in
its current implementation temporarily
15 matches
Mail list logo
