I can confirm this, but actually it's not a wrong result as 0.99999... = 1  (http://en.wikipedia.org/wiki/0.999...#Proofs). It's just not the result that humans would expect. Maybe this could be solved by using higher precision data types for the calculation...

=8.2+1.1 for non-comma countries. This isn't IEEE, ergo, bug.

Actually. I lie.

it also says that 1*10^-15 is 1e-15 and 1e-15 is 1.

0.99999999999 is not 0.9999... (infinite nines).

It appears krunner is unable to understand exponential notation. Entering "=1/4e-3" produces 64 instead of 250. I entered 1/(4*10^-3) and got the correct answer. I had to put brackets around the denominator as it doesn't seem to respect the BODMAS/BEDMAS/PEDMAS/whatever rule (http://en.wikipedia.org/wiki/BODMAS), either. There definitely is something wicked going on here...

*** Bug 161555 has been marked as a duplicate of this bug. ***

I confim that the krunner outputs are wrong:
= 595056260442243700 + 1
  595056260442243700  (the same original value, "+1" didn't work)

I using the SVN:
kde4-config --version
Qt: 4.4.3
KDE: 4.1.82 (KDE 4.1.82 (KDE 4.2 >= 20081204))
kde4-config: 1.0

*** Bug 177464 has been marked as a duplicate of this bug. ***

When you do "=789.28-616.47" the result is "= 172.80999999999995" (WRONG). However when you do "=789.28-616.4" the result is "= 172.88" (CORRECT).

It also happens with =100*0.07 it returns 7.000000000000001 as a result which is wrong, pretty weird.

In KDE 4.2 krunner says that =4^2-2*4*9/2+(9/2)^2 is 2

*** Bug 188617 has been marked as a duplicate of this bug. ***

I think the problem comes because it doesn't round up the last digit.
Take =1/6 for example, It gives 0.16666(...) instead of 1.66(...)7

*** Bug 191834 has been marked as a duplicate of this bug. ***

=100*0.009 shows 0.900000000001 but =100*0.09 shows 9. =10*0.09 shows 0.90000000001 as well. Weird.

IMHO, it's not so bad. The gotten result is very near to the correct one.

Much wore when calculation result has nothing similar with correct one.
Like in example I shown above: "krunner says that =4^2-2*4*9/2+(9/2)^2 is 2" (while it must be 0.25 in reality).

Like I pointed out in my bug report (redirected here from https://bugs.kde.org/show_bug.cgi?id=177464), expressions with multiple exponents compute to whatever you get when you drop everything before the last exponent. For example:

=2^2*2 is 4*4, and correctly computes to 16. On the other hand, =2^2^2*2 computes to 4. It's just the 2*2 after the last ^.

Maybe krunner could use kcalc/knumber for calculations? Or maybe kalgebra?
Speedcrunch?

*** Bug 196506 has been marked as a duplicate of this bug. ***

6.6+0.8= 7.39999995 :)
KDE 4.2.4

> 6.6+0.8= 7.39999995 :)
> KDE 4.2.4

Woahh! Better stay with 3.5 until that is fixed.

bug confirmed with recent svn snapshot

any work on this?

I think it's quite ridiculous for a mature DE having a calc that isn't actually able to give the right answer

Krunner also has problems calculating Sin(2*PI)=-2.4492935982947064e-16.
But cos(2*PI)=1 gives what i would expect.

Sytsem: KDE 4.2.4 from Debian unstable on Linux amd64 2.6.30-1-amd64 with Qt 4.5.1.

Looks like the calculator runner is using the QScriptEngine::evaluate function to do its calculations (http://doc.trolltech.com/4.5/qscriptengine.html#evaluate)
So either this is a Qt bug or the calculator runner is abusing the function.

(In reply to comment #24)
> Looks like the calculator runner is using the QScriptEngine::evaluate function
> to do its calculations
> (http://doc.trolltech.com/4.5/qscriptengine.html#evaluate)
> So either this is a Qt bug or the calculator runner is abusing the function.

As I had said in my original bug report that got marked as a dupe for this one:
"Users expect a calculator to display precise values, for example 1.3+8.15 as 9.45 (as it does in kcalc) and not 9.450000000000001 because of floating point rounding errors."

You are right: QScriptEngine is being abused to implement this calculator, which leads to all these strange results.

*** Bug 204041 has been marked as a duplicate of this bug. ***

*** Bug 204354 has been marked as a duplicate of this bug. ***

If the calculator can't produce correct results then it needs to be removed.

System: KDE 4.3.1 from Debian testing.

in krunner: when entering =19.99-3.99=15.999999999999998 instead of 16.

But when entering =19.99-1.99=18.

Question: isn't it possible to somehow use Kcalc for Krunner calculation?

I've run into the same annoying rounding error with krunner in KDE 4.3.3.  For me, they key issue is that entering "8.2+1.1<9.3=" returns "true" in krunner, whereas the answer is clearly false.  

A piece of advice: some statistical programs such as Stata have dealt with similar issues in the past (particularly important with storage of data => algorithms for large numbers to not take up too much memory) but have generally been able to resolve this problem.  Looking at how they have dealt with these issues could lead to a possible solution.

Same with a recent SVN snapshot:

=0.01+0.2

0.21000000000000002


$ krunner -v
Qt: 4.6.0
KDE: 4.3.75 (KDE 4.3.75 (KDE 4.4 >= 20091113))
Run Command Interface: 0.1


kcalc calculates correctly.

*** Bug 211052 has been marked as a duplicate of this bug. ***

SVN commit 1072213 by jacopods:

Round off the last digit to avoid giving wrong results for simple computations
BUG: 167986


 M  +20 -2     calculatorrunner.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1072213

SVN commit 1072214 by jacopods:

round off the last digit to get rid of weird results performing simple computations
CCBUG:167986


 M  +20 -2     calculatorrunner.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1072214

All testcases reported in this br have been checked and they work apart from:

595056260442243700 + 1 
The problem with this is that we don't have infinite precision integer arithmetics; 

If you want that, file a wish :)

Well, if I understand it correctly my testcase would still not work (I posted it in bug 211052, a duplicate of this):

Enter 190.12 - 186.69 =

Expected result: 3.43

Actual result: 3.430000000000007
Actual result (after fix): 3.43000000000001


I think hiding only one digit is still too little, I don't think most people need 14 decimal digits anyway :-).
I would round hiding more digits (like 3, 5 or something like that) instead of the current 1 (after the fix).

SVN commit 1072222 by jacopods:

one more digit has to go, thanks Marco Poletti for pointing that out
CCBUG: 167986


 M  +1 -1      calculatorrunner.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1072222

r1072229 is needed as well. sorry for the 3 episodes patch :P

r1072229 is needed as well. sorry for the 3 episodes patch :P

KDE 4.3.5

=(700*(2^20))/(32*(2^10))
Expected result is 22400
Reported result is 2293760

KDE 4.4.x outputs 22400.

*** Bug 232693 has been marked as a duplicate of this bug. ***

*** Bug 234097 has been marked as a duplicate of this bug. ***

It is not completely fixed: 100.1 - 100 = 0.099999999999994

The problem is that 
Math.log(Math.abs(0.099999999999994))/Math.log(10)
is less than -1 and so the result with 14 significant digits is rounded to 15 digits :-( 

A simple fix could enclose it in Math.max(0,Math.floor(…)) but then: 
(100.1-100)*10=0.9999999999999
(100.01-100)*100=1.0000000000005
etc.
I think, there is no easy solution using Javascript (but I am not a programmer).

I would suggest to use another method to calculate the result; maybe make the qalculator default (and add a dependency on its lib) as it seems, that it handles this cases correct?

Try "12345678901234.1-12345678901234" on any calculator that does use IEEE double precision. You will have to live with it, or use a program that either uses unlimited precision (based on libgmp), or BCD arithmetic.

(In reply to Christoph Feck from comment #45)
> Try "12345678901234.1-12345678901234" on any calculator that does use IEEE
> double precision. You will have to live with it, or use a program that
> either uses unlimited precision (based on libgmp), or BCD arithmetic.

But as a user, I am not expecting rounding errors for “simple” numbers. By rounding to less digits (e.g. 7 for IEEE double precision) the errors could be hidden for more cases. I suggest a quick patch for javascript at:
https://phabricator.kde.org/D6845

It would better to use another method than javascript-evaluate. Why do not make libqalculate a dependency?

From a users perspective, the calculator should yield exact results whenever possible. This includes floating point numbers. Exceptions could be roots and functions, e.g., sin and log.

I was subscribed to this report, because another report was marked as duplicate of this one.
But that other report was about a more important thing: some formulas were evaluated absolutely wrong, e.g. =(2^2)^1 returned 1; now that bug is de-facto resolved.
So now I unsubscribe.