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

List:       koffice-devel
Subject:    Re: KSpread 2.0: some issues
From:       "Tomas Mecir" <mecirt () gmail ! com>
Date:       2006-12-24 15:36:31
Message-ID: 492258b10612240736t33c3f080gdab80c68da5d949c () mail ! gmail ! com
[Download RAW message or body]

2006/12/24, Stefan Nikolaus <stefan.nikolaus@kdemail.net>:
> The mentioned type distinctions are not necessary. Otherwise each operator
> will look something like:
>
> Float Float::operator*( Float o )
> {
>         if ( type() == TYPE_FLOAT && o.type() == TYPE_FLOAT )
>                 return f * o.f;
>         else if ( type() == TYPE_COMPLEX && o.type() == TYPE_FLOAT )
>                 return c * o.f;
>         else ...
> }
>
> Or how are you planning to avoid this?

Hmm, I don't. Is it an issue though ? If we have separated complex and
float types, then something like this is necessary somewhere too.
Either in the operator directly, or some sort of logic in each
function that would figure out which value is stored in a given Value
object and make an instance of type Complex or Float. For every
function that supports complex numbers. Sounds even more complex than
the situation that you describe.

> Another advantage is, that we can typedef Float to double, which is not
> possible, if it is also used for complex numbers. ;)

Hmm. Good point. Assuming that the only #defined-out thing would be
arbitrary precision, but complex numbers would still be there.

> The original idea of Float was, that, if we do not use any special arbitrary
> precision type for floating point numbers, but simply double, it falls back
> to the builtin operations for double without ANY kind of extra stuff, like
> type conversions or type distinctions.

Yes, but complex numbers are sort of spoiling it, for if you want to
have these, we either have to have a datatype that can hold both
things, or implement the logic for handling complex numbers
separately.

Hmm.

What about making it so that all functions which want to support
complex numbers will keep on using the current scenario with ValueCalc
(which will then be adjusted to transparently handle complex numbers),
and your Float type shall be storing just normal numbers, with
possibly #define Float double if needed. Float would be used to store
the numbers in the Value class.

That way, functions that don't support complex numbers can convert the
value to a Float type (ValueCalc would be providing a method that does
that), then use standard operations, and functions that do want to
support complex numbers will use ValueCalc, as they do now. The point
here is that most functions with a lot of calculation will not support
complex numbers, so only simply functions like +-*/, sin, abs and such
will be calling ValueCalc.

I believe this is fairly similar to Ariya's proposal.

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