(*** This bug was imported into bugs.kde.org ***) Package: kcalc Version: KDE 2.2.1 Severity: wishlist Installed from: Slackware Packages Compiler: Not Specified OS: Not Specified OS/Compiler notes: Not Specified It would be nice if kcalc would have a higher precision when calculating. For example it is not possible to calculate things like: 123445^1000000 bc can do that. So why doesn't kcalc take advantage of the bc maths libraries? In other words why reinvent the wheel? kcalk as a gui for bc that would be perfect. IMHO i think you wanted to have a calculater for kde that is independent (like kcalc is now). So i think the best would be having both things of those two worlds. That could be solve with an option called "make use of bc" in the option menu of kcalc when activated kcalc works as a gui for bc and uses bc to calculate things that would give kcalc the ability to calculate at a very high precsision level. If this "make use of bc" option is deactivated kcalc calculates on his own without bc. (Submitted via bugs.kde.org)
I agree kcalc needs higher precision. calc on windows has for some time been able to do 2^106 without resorting to exponential notation (kcalc at 2^56). Having this much precision also makes working with 64bit numbers much better. What's the use of building with 96bit long-double types if you're not going to display them?
*** Bug 73760 has been marked as a duplicate of this bug. ***
Yes, and there's other things that make bc great that could be 'imported' if kcalc has the abiliy to include bc, for example working with nearly arbitrary bases, not just the standard ones. Really a great idea.
> for example working with nearly arbitrary bases This would be possible, but I cannot make up a real application... but if you give me one, maybe... Kluas
Uses for nearly arbitrary bases - usefull when teaching/learning the workings of notational systems - easy to implement - could be usefull when testing own implementations of algorithms that use a specific notational system - we've got a subject (in my study of information sciences) called 'Theoretische Informatik' that makes use of notational systems with nonstandard bases
*** Bug 94265 has been marked as a duplicate of this bug. ***
We need to have this because otherwise we end up making mistakes with floating point numbers. We can't have the calculator giving the wrong answers!
*** Bug 97561 has been marked as a duplicate of this bug. ***
*** Bug 104700 has been marked as a duplicate of this bug. ***
*** Bug 103256 has been marked as a duplicate of this bug. ***
*** Bug 109029 has been marked as a duplicate of this bug. ***
I have no idea why my bug has been marked a duplicate of this wish. I don't care for a high-precision calculator, I would just like kcalc to not produce faulty output (see Bug 109029) - if that means sacrificing precision, or just copying the calculator display instead of the complete (and often wrong) result, that'd be fine with me and most users, too.
I agree that this is not a duplicate of Bug 109029 - so I think someone hit the wrong button. So if someone that has the necessary rights reads this: please set Bug 109029 to open again, it's something quite different.
The reassigning of all the complaints about kcalc to this wish is absurd. There's no magic in making a calculator application not more precision-hungry than what the respective libraries can provide. Want proof? Run xcalc.
I'm trying to implement arbitrary precision support for KDE 3.5. With some luck, this will work out. In a few weeks, I hope I'm far enough to ask people for help by testing it. The changes are very large and I'm afraid that otherwise the first release will be a mess. Klaus
Michael, on the Solaris box here at the institute, I type "ldd /usr/openwin/bin/xcalc", and I get ... libmp.so.2 => /usr/lib/libmp.so.2 ... I.e. they also use a multiprecision library. On the other hand, on "Red Hat Enterprise Linux WS release 3 (Taroon Update 2)" xcalc I type in 1.000000010 - 1 and I get 9.999999e-9 which is a rounding error... Float or double is no good for a calculator... Klaus
Hi, In case any of you is using the svn-sources. Could you please play a bit with the new kcalc (for KDE 3.5 not for KDE 4.0), and tell me what you think about it. I have been hacking KCalc now for too long, without any outside reviewer. Though there are still many things not working, I just need some feed-back (or I'm going crazy) Things not working: Hex/Bin/Oct-mode has errors Trig-functions, Log,exp, etc. only work parially Cube root, and power does not work, but for the rest I hope everything is fine. If you find anything else, or have comments please tell me. Thanks Klaus
I will close this wishlist-bug now. Arbitrary precision has been implemented for KDE 3.5 and it seems to more or less work. There are some issues still left (e.g. that Sine/Cosine etc. still do not use arbitrary precision), but I would prefer these to be reported in new bug reports, which are more specific than this one. Klaus