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

List:       koffice-devel
Subject:    Re: KNumber-Library
From:       Michael Pyne <pynm0001 () comcast ! net>
Date:       2005-08-20 21:12:43
Message-ID: 200508201712.43900.pynm0001 () comcast ! net
[Download RAW message or body]

On Saturday 20 August 2005 12:08, Klaus Niederkrueger wrote:
> 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.

Agreed, no use in breaking something that's working, especially with so little 
time in which to fix things.

> 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 also agree that the projects should be joined as much as possible.  The 
reason I chose Ariya's HMath is because its bc roots mean that the underlying 
library is more or less well scoured for bugs.  In addition, it had good 
support for functions, although I had to add the arc hyperbolic functions 
IIRC.

Also the API was nice, as you mentioned.

> 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.)

bc is not required, Ariya merely forked the appropriate code from bc.  As far 
as GNU MP is concerned, to be usable it seems to require an add-on library 
called MPFR which will supply the mathematics functions needed for a 
calculator.  I wouldn't mind requiring GMP, but requiring two libs is a bit 
much.

Now, as far as how do I go about using both, I wrapped the types in a number<> 
template which is specialized at compile time to use either HMath or GNU MP.  
That's pretty much just an implementation detail though, there's any number 
of ways to do so.

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

I'm pretty sure that HNumber does not, but I'm honestly not sure about MPFR.  
And either way most operations I do using either don't seem to experience the 
issue.  Fractional support would be nice to add however.

> unhappy). Somehow I'm not able to explain very clearly what I mean.

I think it's clear enough.  Things like 1 / 3 * (2 + 1) should return 1, not 
0.999999 or 1.00000001.  I don't seem to have this issue with MPFR, and 
HNumber handles it fine as well.

> 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.

Sounds good.  I guess this indicates that perhaps it would be useful to have a 
high/arbitrary precision library in kdelibs?

The thing I think we should add is that we haven't answered the question of 
how to handle localization with these libraries.  abakus doesn't support 
anything but US Decimal at this point, and we need to keep this in mind when 
working on integrating the libraries.  MPFR seems like it would be easy to 
output numbers correctly since it doesn't give out decimal points.  It seems 
to require US Decimal for input though I could be mistaken.

Regards,
 - Michael Pyne
_______________________________________________
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]