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

List:       koffice-devel
Subject:    Re: Spreadsheet formulas
From:       "Ariya Hidayat" <ariya () kde ! org>
Date:       2005-06-07 7:29:47
Message-ID: 2033584716 () web ! de
[Download RAW message or body]

> This, once done, would require a whole new Technical
> Committee and serieas of formal reviews/discussions to become another
> OASIS standard with the same weight as OpenDocument, right? Or do you
> see any reason why it should not be endorsed by OASIS ?

In my opinion, it is more difficult and not practical to standardize the formula 
names because each different uses might not overlap to each other. It is OK 
for document format because these format will allow people (and machines) 
to exchange the important content/presentation. I can't imagine how 
a business man or a financial report generator needs to care on how function 
like BESSELJ should behave.

But of course I have no depth no knowledge about OASIS, so this may be 
complete wrong. Perhaps David can give some more hints here.

> 1) This is probably where end users can give an excellent
>    contribution, that is create their own small spreadsheet with the
>    formula and corner case that they have found in their own work. If
>    I suggest in the article that they do it:
> 
> 	     a) what are your requirements for such test cases
> 	     	     (format, size, attached docs & comments,
> 		     everything)
>              b) where should these files be sent?
>    however....

This must decided and someone must be responsible to coordinate the 
tasks. A suggestion would be to produce a simple spreadsheet file that 
has column 1 as a textual representation of the expression, stored as 
string,e.g. "=SIN(0.5)", column 2 contains the real expression, and 
column 3 contains the expected calculation result (could be column 2 
pasted as value here). Each row then can be one testcase.
For database functions which require some data, another area in the 
sheet can be reserved for sample data. No need to create one file 
per one function, but rather (like in Gnumeric) one file can contain 
the whole functions in a group, e.g. SIN, COS, etc can be combined 
together as "math" group.

As for storing the testcase, we can always save it in KSpread working 
directory in SVN server. For submission, bugs.kde.org is adequate 
(I believe).

> 2) Do they have to be in .xls format? Why not .sxc and/or whatever
>    replaces it in OpenDocument? Isn't the whole point to create a
>    complete alternative to proprietary file formats? (Not to mention
>    that this avoids any differences between different versions of MS
>    Excel).

Perhaps I did not explain more clearly.
The reason is because we want to achieve 100% compatibility with 
Excel and last time I check OO.o is still not there (albeit very close).
Of course I'd be happy to be proven wrong. So unless we are sure 
that FOOBAR function in OO.o gives the same result as in Excel 
(and you must check not only one function, but all of them), then 
the easiest and pragmatic way to do it is to use Excel format.
Otherwise if we use e.g. ods format, the values that are saved 
are calculated by OO.o, not by Excel.

We can define some guidelines like: check with Excel, if in doubt 
then check OO.o. This does not apply for functions that OO.o has and 
Excel does not have.

As with problem in Excel accuracy, this should be investigated further. 
IIRC only one (or two?) new version has this precision problem, and 
that is not for all functions of course. In doubt, Gnumeric can be 
checked as well as it excels in this precision matter.

> Same as above. Why start from MSO instead of the set of functions already
> common to KOffice/OO.o, then look at Gnumeric, etc...? Just curious.

Same reason: 100% Excel compatibility. It is OK if we have functions not 
supported in Excel, but if we do not support something Excel already has, 
it is not good for the users. Imagine the whole mess if Excel, OO.o, Gnumeric, 
and KSpread give different result for some functions.

> *THIS* is how the general public (OK, that minority of it that
> couldn't code to save their lives, but realizes how much freedom is at
> stake) reads all the talk of open standards. But then the goal is not
> to always run after closed formats, which would be changed every so
> often just to keep you running. The point is to make them not
> necessary anymore. From your comments, I fear that the best way to
> exchange complex spreadsheets between OO.o and KOffice users will
> remain .xls, not OpenDocument, for quite some time. Is this true?

It is indeed very easy to get confused here. 
I have nothing against OpenDocument format, in fact I take it for granted 
that this is the standard file format that we adopt and continue to support.
However, this matter is not about the file format (the "container") but rather 
on the application behaviour (the "content").

Once OpenDocument becomes the default file format for KOffice then 
KOffice users and OO.o can always exchange spreadsheets. But what if  
there are discrepancies in the numbers inside the spreadsheet (which 
AFAICT will annoy business people) which one is to be believed? Or if one 
guy receives a report from his subordinate (in Excel) and opens it in 
OO.o/KSpread and suddenly sees that his company has lost $1M because 
different behaviour between Excel and Oo.o/KSpread? (Of course this is 
extreme example).

IMHO the best approach would be to stay 1:1 compatible with Excel 
where Excel does it right. This means for first step we would need many 
test cases (compared against Excel), and since we need to know what 
Excel calculates, means that we need to store them in .xls format.
Of course, when Excel does it wrong, then we need to deviate. 


Best regards,

Ariya Hidayat

PS: No need to cc me, I'm on the list.


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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