[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 12:14:19
Message-ID: 492258b10612240414h82b7a5fo55e551884398608 () mail ! gmail ! com
[Download RAW message or body]

2006/12/24, Stefan Nikolaus <stefan.nikolaus@kdemail.net>:
> No, we just exchange/extend one part, the floating point type double, with a
> more flexible type, the Float class.

Yes, that's what I am suggesting here now. Although your comments
below indicate that you don't like it that way :)

> No, not all functions are capable to work with complex numbers. Hence, I see
> no need, that the Float class has to handle those.

But basic operations like +-*/ do support them, and if we have these
things in Number, these things will then work fully transparently, and
functions that do not support complex numbers or something could
auto-convert them into doubles or throw an error or whatever.

> Let the Value class handle the different types and use Float just for real
> number calculations and representation (the latter by replacing the stored
> double variable in Value with one of type Float).

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.

> I want the Value class handle all those type distinctions and want Float
> simply to become our floating point type, nothing more. It shall just provide
> transparency for different precisions. This way the operations stay clean
> from any type conversions.
> If we would ever get a distinct complex type, it should go into Value as
> further variable. For calculations we should then construct a similar class
> as Float (actually one consisting of two Floats) to provide arbitrary
> precision for complex numbers, too.

What is the advantage over my version though ? With the exception of
complex numbers, it's exactly the same thing, and if we would to add
them, we'd have to add them separately instead of just using Number
for that. Hence I believe my version would work better :)

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