[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KNumber-Library
From:       Klaus Niederkrueger <kniederk () math ! uni-koeln ! de>
Date:       2005-08-20 16:08:57
Message-ID: Pine.GSO.4.44.0508201742281.10231-100000 () Thales
[Download RAW message or body]

> I hate to write this again (looks like a cheap advertisement!), but have
> you both checked high-precision math routines which I implemented for
> SpeedCrunch (http://speedcrunch.berlios.de)? Basically it is a wrapper
> around GNU bc routines with added functions (e.g. sin, cos, ...), slower
> than GNU MP, less precise (not arbritray, but high-enough) but does not
> depend on anything.  It is being used also in Michael Pyne's abakus
> calculator (http://grammarian.homelinux.net/abakus/). Future
> collaboration with Michael will allow more back-end (e.g. MPFR via GNU
> MP, or MAPM) without changing the interface.

Ok, this is now hard. Of course, first this is an ego-problem.  After
having almost finished my own library, it is difficult to judge something
objectively, and then decide to throw my own stuff away.

Following comments are probably true:

Soon there will be the kde-3.5 release. Exchanging now my whole
Knumber-library with yours would be too much work in too little time.
So for now, things have to continue like they are.

After the release one should definitely join the two projects. It does not
make any sense to develop more or less the same thing completely
independently. The question is of course, how this "unification" can
happen: from completely throwing away one of the two to taking bits of
both and combining.

I only had a brief look at your library, and I will tell you what I think
about it:

It seems to have a very easy API. Good!

Having different back-ends sounds like a good idea (but maybe it ain't:
Is bc a more common software than GMP? I don't know. Why not just require
GMP. If some user reports a bug, you have to discover in which part of the
software is the bug, what configuration the user uses etc.)

It is already working.


Does it have support for fractions? KNumber has internally four types of
numbers integers, fractions, floats, and errors (infinity, undefined
etc.).

I believe this is the most important thing for such a library (though it
could be enough to have decimal fractions: What I mean is, whether 0.1 is
represented internally as a decimal number or as a binary number. There
were many rounding problems with kcalc, because of the decimal
representation, e.g. "1.1" is maybe represented in binary form, i.e. it is
rounded in binary form and hence it maybe internally equal to
1.099999999995 or something, and no matter how many binary digits you add,
it will never be equal to the exact value "1.1").  This can then give
terrible output (numerically there is no difference between
1.0999999999999999995 and 1.1, but if the user gets the first result
instead of the second one on the calculator screen he will be really
unhappy). Somehow I'm not able to explain very clearly what I mean.

Until the KDE-3.5 release, I think I will stick to my own library, but we
should really discuss, what we could do afterwards.

Cheers

	Klaus

> Klaus: did you get my e-mail about this before?

No... which one?

Klaus

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]