[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-24 13:29:07
Message-ID: ba035dd10612240529k2f971aa6v608d275faa01dde2 () mail ! gmail ! com
[Download RAW message or body]

> Well that's pretty much the same as what I'm suggesting, the only
> difference being, that complex numbers will have to be handled
> separately somehow, which I don't like :) Hence I would prefer my
> solution.

C'mon, we're here not for doing things *only* because personally we like it.

So far I don't think it is necessary to generalize numbers into
complex numbers here. Like Stefan wrote, not all functions deal with
complex anyway. So for those e.g. financial functions, just convert
the parameters to double-like Float and for the math functions,
convert them to complex-like e.g. Complex. I can't see the reason why
we would need four FMULs (as in complex) for multiplying scalars,
which are the most common case anyway. Sure, the difference is
minuscule, but why "penalizing" the users unnecessarily?

And if one wants to create a complex number class, better to stick it
as close as possible to standard C++ complex type. Thus, for those who
don't care/don't want/choose NOT to use GNU MP or other fancy
libraries, they still have a nice fall-back solution.

That's why I proposed the name "Float", to signifies that this is
about floating-point drop-in replacement for double. This is not about
complex number, irrational numbers, quaternions, or
<insert-your-favourite> domain.

And the reason I propose using the namespace Math (vs putting in
ValueCalc) to hold math-related functions is because, well, these
functions are math functions. They make sense only with numbers, not
generalized value.


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]