Using JS to compute can lead to rounding problems (e.g.: 100.1-100 < 0.1) when the exponent is >=14.
This fix solves some problems (more as before, but not all). See https://bugs.kde.org/show_bug.cgi?id=167986
Details
- Reviewers
- None
- Group Reviewers
Plasma: Workspaces
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Although this example would work (the result is 0.0000333333333), I see your point. I've been wrong: 1/30000000000000 returns 0 with this modification.
But the problem is, that most users wouldn’t expect rounding errors for “simple” calculations as 100.1-100. I would suggest to use another method than javascript evaluation to calculate the value. Why don’t use qalculate always (making it a dependency) as it doesn’t have the problem? Or even do exact calculations?
I take a quick look a Javascript and I see only one thing you can do easily: reduce the precision at least to half of the precision of the numbers (64-bit doubles => 7 digits; the default in C/C++ would be 6 digits).
P.S.: I did edit the patch accordingly.
Off topic: Is there a more simple way to test the calculatorrunner than to recompile the plasma-workspace (make install && killall krunner; kquitapp5 krunner and start krunner again)?
I did not do any more work as I do not know, what is the preferred way. I would see three options:
- Leave it as it is: use Javascript's internal functions (if qalculate is not present, else use that). Then I would suggest the above patch (or similar) to round to less digits to avoid some rounding problems.
- Make qalculate a dependency and always use that.
- Do exact calculations for floating point numbers (convert them to base10-fractions. Then all calculations without functions like sin, log, … are integer calculations, which can be done exactly; in the end put a point at the right place in the integer). Then qalculate would not be a dependency, but some functionality of qalculate would be implemented here.