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
prod
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 in decimal mode
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 look
https://bugs.kde.org/show_bug.cgi?id=405548
Evan Teran changed:
What|Removed |Added
CC||ete...@alum.rit.edu
--
You are receiving
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 "pasting s
https://bugs.kde.org/show_bug.cgi?id=382391
--- Comment #4 from Evan Teran <ete...@alum.rit.edu> ---
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 f
https://bugs.kde.org/show_bug.cgi?id=376655
Evan Teran <ete...@alum.rit.edu> changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #
https://bugs.kde.org/show_bug.cgi?id=376655
Evan Teran <ete...@alum.rit.edu> changed:
What|Removed |Added
Resolution|--- |INVALID
https://bugs.kde.org/show_bug.cgi?id=375681
--- Comment #3 from Evan Teran <ete...@alum.rit.edu> ---
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 ... b
https://bugs.kde.org/show_bug.cgi?id=375681
--- Comment #1 from Evan Teran <ete...@alum.rit.edu> ---
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.
https://bugs.kde.org/show_bug.cgi?id=368697
--- Comment #1 from Evan Teran <ete...@alum.rit.edu> ---
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 c
13 matches
Mail list logo
