Bug 330979 - while calculating x*(10^y) if value of y>1000000 then kcalc gets hanged sometime ,sometime its crashes for large value of y
Summary: while calculating x*(10^y) if value of y>1000000 then kcalc gets hanged somet...
Status: RESOLVED WORKSFORME
Alias: None
Product: kcalc
Classification: Applications
Component: general (show other bugs)
Version: 2.13
Platform: Mint (Ubuntu based) Linux
: NOR crash
Target Milestone: ---
Assignee: Evan Teran
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-10 10:47 UTC by Raushan Kumar
Modified: 2020-12-18 22:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
after applying this patch , kcalc will not consider the if y is very very large (1.84 KB, text/plain)
2014-02-10 10:47 UTC, Raushan Kumar
Details
i suppose this will solve the above problem (1.78 KB, patch)
2014-02-10 14:55 UTC, Raushan Kumar
Details
this patch solves the above bug if y value is positive (792 bytes, patch)
2014-02-28 18:20 UTC, Raushan Kumar
Details
attachment-16163-0.html (1.60 KB, text/html)
2020-12-18 08:36 UTC, Raushan Kumar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Raushan Kumar 2014-02-10 10:47:04 UTC
Created attachment 85077 [details]
after applying this patch , kcalc will not consider the if y is very very large

after applying this patch , kcalc will not consider the if y is very very large .It will set value accordingly either infinity, -ve infinity or
eg: zero in case of x*(10^(-ve large number))
infinity in case of +ve x*(10^(+ve large number))
And -ve infinity in case of -ve x*(10^(+ve large number))
Comment 1 Raushan Kumar 2014-02-10 13:22:27 UTC
Sir, what about my patch of Floor/Ceil button and ideas for GSoC 2014
Comment 2 Raushan Kumar 2014-02-10 14:55:25 UTC
Created attachment 85079 [details]
i suppose this will solve the above problem
Comment 3 Evan Teran 2014-02-10 19:25:41 UTC
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.
Comment 4 Evan Teran 2014-02-14 19:58:26 UTC
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.
Comment 5 Raushan Kumar 2014-02-28 18:20:41 UTC
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
Comment 6 Evan Teran 2014-03-03 20:42:00 UTC
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.
Comment 7 Justin Zobel 2020-12-17 05:23:11 UTC
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.
Comment 8 Raushan Kumar 2020-12-18 08:36:20 UTC
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.
Comment 9 Christoph Feck 2020-12-18 22:20:37 UTC
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.