[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-19 8:45:13
Message-ID: Pine.GSO.4.44.0508191029410.5992-100000 () Thales
[Download RAW message or body]

> > Now I was thinking whether it might be useful for other projects, too.
>
> Yes. It can be useful here - I plan to add arbitrary precision support
> to KSpread, and having something like this would make things much
> easier.

This would be great - especially, if you used my library ;-)

> > I would appreciate any comments: Could this be useful for you? What can be
> > enhanced? How should the API look like etc. etc.
>
> Basically, four things are missing before I can consider using it.
>
> 1. ability to set precision (as a number of digits). I assume there's
> some default one, or else calculating 1/3 will use up all your memory
> and still won't have enough :D

One can set the floating point precision with "setDefaultFloatPrecision".
In the test-program for example I compute (with precision 1000 digits)

(1+1e-990) - 1

and it gives 1e-990. This was really stunning (kudos to the GMP
developers), probably such a precision does not make sense for nothing,
but cool.

Regarding 1/3, this is solved differently, because a "KNumber" can
encapsulate either a float or a fraction, so 1/3 would have an exact
representation in KNumber.

>
> 2. pre-defined high-precision constants. Most importantly, pi and e.
> Also, functions like sin/cos/acos/... would be necessary.

I already had predefined KNumber::Pi with a few digits (though I don't
have a routine to compute it at run-time with arbitrary precision). I
could easily add KNumber::e. With sin/cos/acos etc. there is no support in
GMP for this. There is an additional library, which could be included, but
for now I had refrained from doing so, because I did not want to create
more dependancies. I'm implementing this in KCalc anyway (for now a
wrapper: convert KNumber --> double --> compute sin --> convert KNumber).

Maybe I could add a second library called KNumberTools with sin/cos etc.

> 3. conversion routine to double - this is necessary to support
> functions which want to do things more complex than what the lib can
> handle. Same for int (although once ->double works, this can be done
> with one cast).

O.k., I will do this.

> 4. Conversion to string needs to have precision set - number of digits
> or length of resulting string (rounding if too long, or using
> scientific notation).

This is very important for my calculator, too. But I don't know how a nice
API would look like. If you have any comments... Somehow I feel that
adding one thousands methods, like

setScientificNotation(bool)
setNumberofDigitsforScientificNotation(int)

etc. does not sound like a good idea.

Thanks for your comments

	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]