[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Semantics
David A. Wheeler wrote:
> Okay, here's an email specifically about semantics; please reply to this
> email to discuss semantics. That way, those of us with threading email
> clients can follow the discussion. (Those of you without a threading
> client... good luck :-) ).
Well, you started your email by replying to a previous one, so
Thunderbird shows it as a sub-thread of an existing, large, thread.
> The real test should be, "will typical spreadsheets with formulas
> interchange correctly?"
I think that the real test should be, "will *compliant* spreadsheets
interchange correctly?".
If I give you a compliant spreadsheet and you open it on your compliant
program and look at cell D7 you should see the same value that I see on
my compliant program. If the spec can't guarantee this, it's broken.
(except for an allowable margin of error)
Hence, I disagree with being fuzzy at low levels. If you give me a level
1 spreadsheet and I see a sheet full of errors we do not have
interoperability and the spec failed.
What should happen is that if you type "3"+3 in Gnumeric, the formula
gets saved as VALUE("3")+3 so that when I open it in OOo I get the same
result you do.
> Oh, why that particular semantic at level 3?
> One advantage of this particular semantic is that naive users either get
> what they were probably expecting, OR they get a warning message
> that there's a problem (instead of silently getting the wrong answer).
I don't see this. How does leaving scemantics to level 3 ensure that
level 1 users get what they were expecting?
>> There should also be formal definitions of what the functions compute,
>> and a reference algorithm should be provided, if possible.
>
> A formal definition in terms of a mathematical expression would be good.
> I don't think we should mandate a particular algorithm, but mandating
> particular
> test case results are fair game,
I wouldn't /mandate/ an algorithm, but a /reference/ algorithm seems
alright. In other words, "your function must give the same values as
this function within the allowed margin of error". At least in theory, a
reference algorithm is the strictest test case, because it allows
testing against any value permitted by the spec.
I don't have strong feelings either way. If we did have reference
algorithms, it should only be for functions that really merit them. It's
stupid to have a reference algorithm for SUM.
Cheers,
Daniel.
--
/\/`) http://opendocumentfellowship.org
/\/_/
/\/_/ I'm not saying there should be a capital punishment for
\/_/ stupidity, but why don't we just take the safety labels
/ off of everything and let the problem solve itself?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]