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

List:       koffice-devel
Subject:    Re: KSpread: Number class - some issues
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2007-05-27 16:29:54
Message-ID: 200705271829.57147.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 27 May 2007 18:01:42 Tomas Mecir wrote:
> 2007/5/27, Stefan Nikolaus <stefan.nikolaus@kdemail.net>:
> > If you keep different data types in Number, even if it's just double and
> > complex, you will again get the type conversions, which should have
> > actually vanished.
>
> With the alternative being ... ? If you keep complex in Value instead
> of Number, you end up either calling ValueCalc for complex numbers
> (same as now), making the app not work with complex numbers (not the
> best way to go), or end up with the complexity moved into each and
> every function.

(Currently ValueCalc's methods are never called for complex numbers.)

For KSpread's IMFOO functions you'll keep using Value::asComplex(). The only 
difference is, that you have to change all occurences of	complex<double> to 
complex<Number> in Value.

For all other functions it looks like:
Value func_foo(valVector args, ValueCalc *calc, FuncExtra *)
{
    Number var1 = args[0].asNumber();
    Number var2 = args[1].asNumber();
    Number result;
    // do the calculation
    return Value(result);
}

You have to replace the Value constructor taking double as argument by one 
taking Number and replace double with Number appropiately in Value. That's 
all.

> Note that if the complex stuff is done right, the whole type
> conversions in the proposed Number class would look like this:
> if (imag() == 0 && number2.imag() == 0) performOperationOnRealNumbers;
> else performOperationOnComplexNumbers
>
> which is certainly not that much of an overhead, and can still be
> collapsed into typedef Number double if you don't mind also losing
> complex numbers (well, you won't lose them, you'll just have to use
> them with IMADD, ...).

Right! You carry the imaginary part along in all KSpread functions even if 
it's just used in the IMFOO ones. Besides you have the minor, but unnecessary 
overhead due to the type distinction. I assume, compilers try to optimize 
adjacent FPU instructions, which may get prevented by these distinctions. But 
I'm not sure about the latter.

Regards,
Stefan

["signature.asc" (application/pgp-signature)]

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