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

List:       koffice-devel
Subject:    Re: KSpread 2.0: some issues
From:       "Tomas Mecir" <mecirt () gmail ! com>
Date:       2006-12-24 9:33:21
Message-ID: 492258b10612240133m191aefe0t4c0f7a93f01f8368 () mail ! gmail ! com
[Download RAW message or body]

2006/12/23, Ariya Hidayat <ariya@kde.org>:
> > It's not perfect, but at least it won't cause problems with extensibility :)
> The consequence is obvious: primitive calculations like addition and
> multiplication should be done the way they are done now, i.e using
> double, if no external library is used. That's why this idea of Float
> class came to mind:
>
> #ifdef KSPREAD_USING_FANCY_ARITHMETIC_LIBRARY
>
> class Float
> {
> public:
>   // IMPLEMENT the wrapper for doing math operations using the favourite library
>
> };

Hmm. Yes, now that I read it again, it might work, if we do the
conversion from text at the beginning. Still, I have some issues with
that, although none of them would likely count as a show-stopper.

- by having a separate Float class, we are essentially duplicating a
part of the already existing Value class
- I was hoping that we could have more ValueCalc back-ends than just
float/double and GnuMP - in particular, complex numbers come to mind.
The Float class would have to be able to handle these things all
- array values, including arrays in arrays and other wonders: what
with these ? ValueCalc has its arrayWalk functions which are capable
of handling all this, including automated conversions. Do we simply
keep the current functionality there ?

Just a bit of brainstorming here, to come up with something that would
solve your issues, allow the compile-time things, whilst also being as
flexible as I like it, thus keeping everyone happy:
- the Float class will be called Number
- ValueCalc will receive a new method, toNumber, which will be
returning an instance of Number (or double if #defined that way)
- the Number class, once it exists, will be capable of handling all
numerical datatypes that we will want to use - integer, double,
high-precision, complex numbers, whatever else
- there will be operators overloaded for Number (ignored if double is used)
- things like sin will still be handled using ValueCalc, but ValueCalc
will be receiving instances of Number, not Value
- the KSpread::Value class will be holding a Number instance instead
of the current int/double
- functions doing numeric calculations will first obtain Number class
instances by calling ValueCalc::toNumber, then they'll do what they
need to do, and finally they'll return an instance of KSpread::Value
generated from the resulting Number
- ValueCalc will still hold the more advanced operations like
factorials, arrayWalk and such, but these will be handled using the
Number class where possible, not Value
- arrayWalk will stay the same, receiving a Value containing an array,
it will internally convert to Number when needed

Right. Any comments ?

I guess that if I keep on thinking about that, I'll eventually get so
interested that I'll find myself some time to actually implement this.

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