[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 #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 487493] kcalc miscalculates equasions
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 produce 150. If that's so, this is not a big as kcalc implements proper order of operations, making 200 NOT the correct answer. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 448769] KCalc becomes unresponsive during computationally complex calculations
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 kind of thing is to do the work in a background thread, and have that thread periodically check "did the user cancel"... But the library we use (GMP) just does the work, start to finish. It doesn't ask the caller "should I continue?" at any point during a long calculation. Killing a thread mid-process is considered so dangerous, that many OSes don't even provide clean APIs to do it... The other solution, which GMP also doesn't offer, is to have the work done in small bits you can call repeatedly until complete, allowing the caller an oportunity to run the event loop themselves (and/or just stop calling the "do some work" function if the user wishes to cancel). One can imagine the math being done in a virtual machine of sorts where the caller can run as many or as few instructions towards solving the problem at a time as they please. Either way, Neither of these are really easily options for us. So what's the solution? Well, probably to literally have the work done in a seperate process which CAN be killed via a signal and communicate the results with a pipe. It will be complicated to do this nicely, but it's doable and would fully address this issue of long running calculations freezing the UI. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 447347] pasting numbers starting with zero are parsed as octal
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. Perhaps kcalc could thread this needle by accepting 0o as an octal prefix, 0x as a hex prefix, 0b as a binary prefix and otherwise, assume decimal. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 447347] pasting numbers starting with zero are parsed as octal
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 Some people want the input data's apparent base to be ignored in favor of the user's selected mode. Unfortunately, I'm not sure there is a way to satisfy everyone on this one. But maybe we should lean towards the user's select mode :shrug: -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 407318] Finish MPFR support
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 into it! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405548] Dark breeze: invalid tooltip/widget colors with compositing enabled
https://bugs.kde.org/show_bug.cgi?id=405548 Evan Teran changed: What|Removed |Added CC||ete...@alum.rit.edu -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 398849] Unusual behavior with pasted numbers starting with zero
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 should have the same effect as typing", except that model doesn't fit pasting hex values such as 0x1234. Really, probably the ideal solution is to add a new set of options to manage this, I can imagine at least two: 1. "Use C conventions while pasting numbers with prefixes that indicate the base" (we can work on the wording :-P). Basically, just let the user shut this feature off, but default to on to maintain current behavior. 2. "Switch modes to match the base of pasted numbers", basically we can have it switch to hex if they paste "0x1234" automatically, which would be less confusing if expected as it would show the number they actually pasted. However, it could be VERY confusing if the user pastes 010, and expects to get 10 instead of 2... If this were to exist, it should of course default to off by default. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 382391] Accept both decimal separators (comma and dot) from clipboard with locales where it is straightforward
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 feeling about how to handle the separator issue. How shall we parse 1,234? 1234? Or 1 + (234/1000) You solution seems mostly reasonable, but we should be careful about the corner cases if any come up. Thanks for looking into this issue! On Thu, Feb 15, 2018, 3:19 PM martonmiklos <bugzilla_nore...@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=382391 > > --- Comment #3 from martonmiklos <martonmiklosq...@gmail.com> --- > Thanks Cristoph for the hint, I have created the D10555 phabricator issue. > I have no idea who should I add as reviewer. Evan Teran no longer seems to > be > active here and I have not been able to find him in the reviewer list. > > -- > You are receiving this mail because: > You are the assignee for the bug. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 376655] Operations on Modulus operator were causing other operators to be erroneous
https://bugs.kde.org/show_bug.cgi?id=376655 Evan Teran <ete...@alum.rit.edu> changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Evan Teran <ete...@alum.rit.edu> --- @Looserof7, One aspect of your report was that "What I mean to say is using Modulus operator is leading other calculations to be erroneous." While "%" is not the modulus operator in kcalc, it WAS in fact causing subsequent calculations to be wrong. A one line patch to resolve this has been approved, and should fix the next version of kcalc that is released. Thanks for your report :-) -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 376655] Operations on Modulus operator were causing other operators to be erroneous
https://bugs.kde.org/show_bug.cgi?id=376655 Evan Teran <ete...@alum.rit.edu> changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Evan Teran <ete...@alum.rit.edu> --- Ah, this is an understandable misunderstanding :-). In kcalc, % is the "percent" operator, not mod! If you want the actual modulus operator, please use the "Mod" button found in both Scientific and Statistic mode (top row, just left of center). For more information on the "percent" operator, please see the manual: https://docs.kde.org/trunk5/en/kdeutils/kcalc/percent.html -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 375681] Not correctly handle binary numbers
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 ... 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 :-). -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 375681] Not correctly handle binary numbers
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. 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 -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 368697] some float numbers raised to a power equal infinity
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 current implementation temporarily converts back and forth between the infinite precision and "long doubles" so that it can use libc's trig routines. I would love to switch this to an infinite precision trig library (particularly MPFR is my preference), but this is not implemented yet. -- You are receiving this mail because: You are watching all bug changes.
