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

List:       koffice-devel
Subject:    Re: KSpread 2.0: some issues
From:       "Ariya Hidayat" <ariya () kde ! org>
Date:       2006-12-23 20:41:47
Message-ID: ba035dd10612231241r46f03505u3645d06353ecfb1c () mail ! gmail ! com
[Download RAW message or body]

> It's not perfect, but at least it won't cause problems with extensibility :)

And what kind of extensibility is that?

If you read again my previous post, what I proposed was based on two
simple premises:

(A) the possibility of high-precision calculation (IF finally someone
has time & effort to implement and test that stuff, which is doubtful
given the lack of manpower we have now) is moved from run-time option
to compile-time option.

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

};

#else

typedef double Float;

#endif

You can of course choose to implement Float as a wrapper for double,
but simple typedef should work, require no effort, and the math
operations will be definitely compiled into FPU instructions (that is
why I wrote "it's a pity..." before).

(B) automatic conversion, if we still want this feature, can be done
only when we are about to get the parameter values for the functions.
After that, you know what kind of values we're working with, so why
use ValueCalc all time?

As an example, take a look at our implementation of function PMT (in
functions/financial.cpp). This function accepts a bunch of parameters,
which are - except the last one that just a flag - numbers. So IMO we
convert all of them to Float instances at the beginning of the
function (remember, this Float can be just normal double or a wrapper
to GMP or any other libraries). Thus, the helper function getPay()
works only with normal number, aka Float, not the heavier Value class
anymore. It does not need to perform any conversion magic.

This improves readability and yet does not block the locale-aware
automatic value conversions.


So far I can't see the reason(s) why (A) and (B) can not work. Nor I
think it would reduce any potential extensibility compared to the
current state.


Regards,

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