[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

*Subject*: **Re: [office-formula] Semantics**

*From*:**Daniel Carrera <daniel.carrera@zmsl.com>***To*: office-formula@lists.oasis-open.org*Date*: Tue, 28 Feb 2006 10:08:04 +0000

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?

**References**:**RE: [office-formula] Proposal: Work ONLY electronically after initial telecomm, except when we decide otherwise***From:*Mary McRae <marypmcrae@gmail.com>

**Re: [office-formula] Proposal: Work ONLY electronically after initialtelecomm, except when we decide otherwise***From:*Daniel Carrera <daniel.carrera@zmsl.com>

**Re: [office-formula] Proposal: Work ONLY electronically afterinitial telecomm, except when we decide otherwise***From:*"David A. Wheeler" <dwheeler@dwheeler.com>

**Key Issues***From:*"David A. Wheeler" <dwheeler@dwheeler.com>

**Re: [office-formula] Key Issues***From:*"Tomas Mecir" <mecirt@gmail.com>

**Semantics***From:*"David A. Wheeler" <dwheeler@dwheeler.com>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]