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

List:       koffice-devel
Subject:    Re: RFC: Arbitrary precision in KSpread ?
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2005-01-21 16:51:15
Message-ID: 492258b105012108513acdbabf () mail ! gmail ! com
[Download RAW message or body]

On Fri, 21 Jan 2005 16:22:06 +0100, Nicolas Goutte <nicolasg@snafu.de> wrote:

> > Would it be a good idea to have arbitrary precision support in KSpread
> > (I've seen it mentioned in the TODO file, or something like that -
> > with GnuMP or however was that library called).
> 
> I personally think that it would be a good idea. Something that will be
> specific to KSpread. So perhaps scientific users would prefer to use KSpread.

Hmmm...

> (If I remember, this was a bug too. I do not have the number at hand. Sorry!)

For the record, it's #52359 :)

> Yes, that is also a question that I had asked myself. Should all the
> calculations be done with arbitrary precision (still not sure of the answer)

If not, then how would we decide, whether a particular number should
be GnuMP-ized or not  ? In the parser I mean...

> (There was also the idea of extra functions but that is now a little problem
> with OASIS, even if OASIS does not norm the functions but we would wish to
> remain near OOo Calc.)

Ummm... what? Like, having extra functions for GnuMP-based
computations? Not sure if this is a good idea... How would we tell
KSpread that number A is to be represented using GnuMP, and number B
is not? Also, having to use something like HIGHPREC_ADD(x1,x2) for
adding, instead of x1+x2, doesn't really sound like the very best
possible thing to do... :-/

> > Now then, herein lies my question - would it be worth the trouble,
> > trying to put in this arbitrary precision support ? Would there be
> > enough interest from the users in having this feature ?
> 
> Nice question too. :-)
> 
> Until now, it was *solved* that nobody had time to implement it anyway. So the
> feature remained a wish.

I see. Well, to put things into perspective...

I want to create a class for computations, with all the basic
operations and the like. It should be able to handle format
conversions and stuff (so that we could use it for things like "5"*5
and obtain 25 instead of a parse error).

Now, the question was, how much things should go to that class ?
Should it be so that any and each computation will be enforced to
happen within this class? E.g., the factorial function would have to
call multiplication from that class to calculate its result ?

There are only two reasons for enforcing this.
First, to simplify the code.
We could simply get the KSpreadValue passed to the function, pass it
to the computing routines, and they would spit out some result, and we
would have no need to care about whether we got a string or a number
or anything.

Second, to allow new datatypes - only GnuMP stuff comes to mind at the moment.
This, however, has one drawback.
If we want to go abstract enough (and we should!), then all the math
functions (including stuff like sine, or maybe also random numbers),
would have to be wrapped in this class, so that adding GnuMP support
would simply mean to extend KSpreadValue and this class.
This would mean some performance hit, but it would allow us to add
GnuMP support very easily, once all functions get converted (and since
I'll be converting all the functions to the new parser architecture
anyway, this won't be a problem).

So, in short, it's all about whether having increased precision would
be worth the slower execution...

/ Tomas
_______________________________________________
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]