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

[Attachment #2 (multipart/signed)]


On Sunday 27 May 2007 17:27:22 Tomas Mecir wrote:
> No, you got it wrong. This is not about multiple precision, this is
> about making the functions code not suck. Ie., replacing ValueCalc
> calls where possible, with a unified Number class, so that instead of
> calc->add (a, b), we can simply use a + b. There would be other
> advantages, but this is the primary one.

http://lists.kde.org/?l=koffice-devel&m=116705006214083&w=2 :
> However, after witnessing the less-readable and inefficiency in the
> implementation of functions using ValueCalc, I came with the idea of
> the Float class.
> 
> I guess it goes back again to the basic thing I wrote in the first
> post of this thread: it's pity that few FPU instructions are replaced
> by lots of potentially unneeded value conversions and pointer
> dereferences. I don't mind extensibility, but my pragmatic brain says
> that it's a disservice if we sacrifice the "most common use cases" in
> the name of extensibility while we still _can_ stil avoid that.

I think this summarizes it very well.

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.

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]