Version: 2.0.5 (using KDE KDE 3.5.5) Installed from: SuSE RPMs OS: Linux kcalc returns values of trigonometric functions which are inaccurate. How to reproduce this: kcalc: angular mode: degrees. settings (menu entry "Einstellungen" "kcalc einrichten" "Allgemein" "Genauigkeit"): maximum number of digits >= 16 sin 30°: expected answer: 0.5 kcalc gives: 0.4999999999999999445 cos 60°: expected answer: 0.5 kcalc gives: 0.500000000000000111 The value 0.5 could be accurately represented as a floating point number.
This bug seems solved in KDE 4.4.5
As Lisandro noted, the bug does not seem present in KDE 4.4.5. So I am marking it as resolved.
This Bug is still present in KDE 4.5.1 / Kubuntu 10.10. Sin 30° for a maximum number of digits of 20 gives 0.49999999999999994449 .
@Alois Maier: First of all, I'm sorry that I closed the bug, I didn't catch that maximum number of digits had to be set to >= 16 digits to demonstrate the issue. Unfortunately this issue is particularly hard to address. I'll explain why. Basically kcalc uses GMP as its core math engine, this allows arbitrary precision on all basic (and some advanced) math operations. However, trig functions are not implemented in GMP itself at all. This means that for every trig function, we need to perform the action itself. Currently this means doing the following: #1 convert GMP number to native type (long double/double) #2 call libc's trig function #3 convert back to GMP representation as you can imagine *all 3* of these steps can lose precision! There is only one solution that I can think of that would satisfy this bug. find or an implementation of the trig functions which has infinite precision (or at least enough precision to avoid any user visible errors) and use that instead, preferably one which supports working directly with GMP types to avoid conversion issues. I am not aware of any such library, but I will keep it on my TODO list of things to look out for.
As an update, (I know it's been a while). I am currently in the process of re-factoring the KNumber code (what kcalc uses to represent arbitrary precision numbers) to make use of the MPFR library (http://www.mpfr.org/). This library is *very* similar to GMP and in fact, is designed to work with GMP. It does provide all (as far as I can tell) of the trig functions kcalc offers and more. So I am hoping to have this bug squashed as some point in the near future.
Any progress, Evan?
Yes, the codebase that should be included in KDE 4.10 has a new "knumber" library which has been re-factored from the ground up. This code has some (currently disabled for testing) high precision trig functions implemented in it, and once I have confidence that there are no regressions in the new code, I plan to enable the higher precision code (which uses MPFR since it is designed to work with GMP)
KDE 4.10 wil ship with a kcalc which has the new knumber library. Once that is out the door, I will start work on using MPFR for the following release in order to support higher precision trig functions).
Git commit 2a05545830fdc9a2fe6a1d249d9eff52c53b7d1f by Christoph Feck, on behalf of Marcelo Mariano. Committed on 23/06/2019 at 10:21. Pushed by cfeck into branch 'master'. Use MPFR in knumber_float in order to improve floating-point precision Related: bug 132158, bug 407318 FIXED-IN: 19.08.0 Differential Revision: https://phabricator.kde.org/D21495 M +8 -0 CMakeLists.txt M +2 -2 knumber/knumber.cpp M +0 -3 knumber/knumber_base.h M +80 -415 knumber/knumber_float.cpp M +14 -8 knumber/knumber_float.h M +8 -1 knumber/knumber_integer.cpp M +3 -2 knumber/tests/CMakeLists.txt https://commits.kde.org/kcalc/2a05545830fdc9a2fe6a1d249d9eff52c53b7d1f