[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-25 12:34:12
Message-ID: ba035dd10612250434r22063af9hbdb826e98a9fe0cc () mail ! gmail ! com
[Download RAW message or body]

> 1. we don't mind hardcoding Float initially, then rewriting relevant
> functions to Complex, or start with having both Float and Complex
> right off

This is not a big deal. The number of functions which work with
Complex will be small compared to the common Float case. Beside,
somebody has to do that anyway because currently each of our IM-family
of functions does its own magic with the complex number.

> 2. we don't mind having to modify each function IF someone really
> writes that quaternion class, or something like that. Is this an issue
> ? At the moment, I do not see the need for anything other besided real
> numbers and complex ones, so with current state of things it's safe to
> proceed that way, but it might cause problems if we do see a reason to
> add a new datatype in the future. The whole point of ValueCalc is to
> provide an abstraction for datatypes, so that when we add a new one,
> only ValueCalc needs to change to get all the functions to work again.

I'm doubtful that spreadsheet users will need to work with
quaternions. Thus, floating-point and complex numbers seem to be good
enough in the mean time.

I'm of course aware of your point regarding the use of ValueCalc.
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 believe, until you are in full agreement with this, I'm not going to
be able to convince you any further, i.e. you'll keep repeating again
your point (on ValueCalc's rationale) and so will I.

Alternatively I start a branch where I work on my Float proposal and
then we can have a comparison. I prefer not to do this because it
requires more effort, but if there is no other resolution...


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]