[kde-edu]: KNumber-Library

[Klaus Niederkrueger]

> Kstars may potentially find this useful.  What can you tell us about the
> memory/cpu performace compared to using long doubles and long ints?

I don't really know. My knumber-library is just a wrapper class around the
GNU multiprecision library. Hence there is a small overhead (compared to
GMP) that may turn out to be significant if one is handling small numbers
(I guess the class structure must be around 8-16 byte around each
gmp-number). The gmp-number itself can be very large: Yesterday I played
around with numbers with 16 million decimal digits, and the memory usage
of kcalc grew to more than 100 MB.

So is this large compared to a long int? I would say, definitely. But
otherwise I (just a wild guess) don't believe that a knumber is more than
5 times larger than a standard C-type of same precision.

About speed I don't have a clue. There is again some overhead from the
knumber-library (let's say I call around 2-5 methods for each operation
only containing a few "if-else"s), but if the numbers are sufficiently
large, then this does not matter at all, because GMP will use up most of
the time. About the speed of GMP I can not say anything.

What does KNumber contribute then? It handles transparently fracions,
ints, and floats (and infinity, -infinity) of arbitrary size.

Conclusion: For user input, KNumber-lib is certainly fast and memory
efficient enough. If I had to solve a PDE numerically (or do a
3D-shooter), I would probably use standard doubles (SSE-floats in the
second case), and if this is not enough use "long long doubles", and if
this is still not enough use the raw-GMP without my own wrapper class. But
in the last case, something would be wrong anyway with the whole concept.

For what do you need large precision numbers in kstars?

Klaus