Bug 330979

Sir, what about my patch of Floor/Ceil button and ideas for GSoC 2014

Created attachment 85079 [details]
i suppose this will solve the above problem

Raushan Kumar,

Firstly, thank you for the patch I'll take a look and see if it is the best solution for this particular problem.

As for your second question "Sir, what about my patch of Floor/Ceil button and ideas for GSoC 2014" I told you previously that I was out of town until today. That doesn't mean that you should ask again the moment it's Monday. It means that I will take a look at your request today (if I have the time). You REALLY need to learn to be patient. I don't want to be rude, but If you don't start using better "netiquette", I will have no choice but to consider future contact from you spam.

So here's the deal:

Some calculations will take an inordinate amount of time. The GUI isn't so much "frozen" as it is "busy for the foreseeable future". Some even bigger calculations will indeed crash (due to memory exhaustion).

So this is real problem in both cases. Perhaps there should be a wish list bug to have kcalc run calculations in a thread and prompt the user if it has been running a calculation a long time?

However, I do not believe that patching this probably at the display level is the "correct" place to do it. I would prefer to see it addressed at a more basic level in the knumber library.

So while I will say this bug is confirmed, I do not believe that this patch is the proper solution.

Created attachment 85365 [details]
this patch solves the above bug if y value is positive

this patch solves the above bug if y value is positive, and I think this one is better solution than perivious one.Please review it once

Hi Raushan,

Thank you for the patch. However, I must decline this one as well. To reiterate my thoughts in the previous patch:

I do not believe that patching this probably at the display level is the "correct" place to do it. I would prefer to see it addressed at a more basic level in the knumber library.

I understand that this bug is a little tricky to address because there are two operations going on:

First z = Pow(10,x) which can be troublesome if x is too large. Then y * z if the result (z) is too large. I feel that a lower level solution is most desirable.

Once again, thank you for your efforts, but for now I will have to stick with my assessment that a display level patch is sub-optimal.

Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Created attachment 134170 [details]
attachment-16163-0.html

Resolved

On Thu, 17 Dec, 2020, 10:53 AM Justin Zobel, <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=330979
>
> Justin Zobel <justin.zobel@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>          Resolution|---                         |WAITINGFORINFO
>              Status|CONFIRMED                   |NEEDSINFO
>
> --- Comment #7 from Justin Zobel <justin.zobel@gmail.com> ---
> Thank you for the crash report.
>
> As it has been a while since this was reported, can you please test and
> confirm
> if this issue is still occurring or if this bug report can be marked as
> resolved.
>
> I have set the bug status to "needsinfo" pending your response, please
> change
> back to "reported" or "resolved/worksforme" when you respond, thank you.
>
> --
> You are receiving this mail because:
> You reported the bug.

I tried:
999999^999999, two seconds to give result (near 1e+6000000)
10^123456789, about 30 seconds to give result (1e+123456789)

These are already insanely large, and you should use a CAS instead of a scientific calculator for anything larger than 10^100 anyway.