Calculation in kcalc

Development
1

Dear community,
while writing test cases for kcalc I came across a strange calculation result.

The equation that I wanted to be calculated is
2^(-1) + tan(-45) =

I expected -0.5 but I got -0,500000000004

Than split the calculation
First part: 2^(-1) , result 0.5
Second part: tan(-45), result -1

What goes wrong?

Regards,
Thomas

2

@thomas_hoe:

It’s because of the KCalc Precision setting – <What about Precision?>

The main factor determining the precision of KCalc is whether your libc and libmath supports the C data type long double.

In my case, I reduced the precision to 10 digits and got the correct answer.

3

Thank you for your reply.
After changing the precision I also got the result.

Nevertheless I’m just wondering because the equation is 0.5 - 1. For this I don’t need the precision of 10 digits.

I defined this test in appium and got an error because the expectation is -0.5 but the test result is -0,500000000004. Till now I have not implemented any tool settings.

4

2^−1 + tan−45 = 2^(−)^(1) + tan(−45 degrees)
= −1/2
= −0.5

Qalculate gets it with a bit of a rewrite… Qalculate-qt is nice.

Kcalc gave me: -0.50000000000000000000000000000001.

Basically, I’d be ok using it for simple arithmetic - but it’s not really good for much else.

5

@thomas_hoe:

I’m also wondering about this –

  • The “stdlib” and “math” libraries and other library header files in ‘/usr/include/’ shipped with openSUSE Leap offer support for “long double” in one form or another.
  • And, which ever way you look at it, “long double” is a floating point data type.

Therefore, the behaviour will depend on how the application defines this type at compile time.
And, it’ll also depend on the floating point processor behaviour of the hardware platform you’re currently using.

For the case of the GNU Compiler Collection, for X86 processors, the “long double” type is defined as being “80 bit extended precision” – assuming 8 bits per digit – 10 digits.

  • Therefore, for my Use Case, setting the KCalc precision to 10 digits should, usually, deliver the expected calculation results – hopefully, reliably … :smiling_face_with_horns: