[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 15:19:15
Message-ID: 200705271719.19074.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Tomas,

On Sunday 27 May 2007 15:34:26 Tomas Mecir wrote:
> I am implementing a Number class for KSpread, which will be used to
> store all the numbers, and will be used within the formula engine and
> such. The class at the moment is supports integer, floating-point and
> complex values. No GnuMP functionality as of yet, but I'm leaving the
> door open for that.

I can't help, but this sounds as if you haven't got Ariya's idea of "the class 
formerly known as Float" straight. It's whole purpose is to use it for 
calculations and just for that. Number should not store different data types, 
like the mentioned double, integer or complex - that's the task of Value. 

If I remember the discussion correctly, there was no change in the plan to 
typedef Number to double in order to get ordinary precision and to implement 
it and the necessary functions (sin, cos, ...) for arbitrary precision 
(GnuMP).
So, Number will 'store' just double or its GnuMP equivalent.

> The questions are as follows:
>
> - do we want to store integers separately, or would it be acceptable
> to simply convert them all to double and be done with it ? Operations
> with doubles are somewhat slower, but that'd be compensated by easier
> algorithms (no need to distinguish between int+double, double+double,
> int+int, and so on)

The plan for double precision is:
	typedef double Number;
-> No.

> - do we want to store complex numbers as std::complex or would if be
> sufficient to simply store two doubles ? The latter, again, would make
> for much simpler algorithms, at the cost of having to create
> std::complex instances for more complex functions like sin/... (this
> is a non-issue, because those are slow compared to object creation
> anyway)

As Number is intended to 'store' just a floating point representation, I don't 
see a simplification here.
Even storing (in Value!) two Number instances has no advantage over using 
complex<Number>.

> - do we want to use std::complex at all ? I could implement the
> complex sin/... functions, which would be a bit of a code duplication,
> but the advantage would be that it'd make things easier once I delve
> into precision support (GnuMP and all).

For GnuMP and the more complex functions the template has to be specialized, 
e.g. for 'cos' the function with the signature
	template<> complex<Number> cos(const complex<Number&);
has to be implemented.

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]