OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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

Subject: Re: [office-formula] 3.1 Expression calculation

Patrick Durusau <patrick@durusau.net> wrote on 01/15/2009 07:59:14 PM:
> robert_weir@us.ibm.com wrote:
> > Patrick Durusau <patrick@durusau.net> wrote on 01/15/2009 05:50:21 PM:
> >
> > 
> >> I suppose what triggered my original interest was why we would be 
> >> describing anything as it "appears to the end-user." ?
> >>
> >> 
> >
> > There is probably a better way to restate the idea rather than 
"appears to 
> > the end user".
> >
> > The main idea is that we describe a deterministic method of evaluating 

> > expressions.  A conforming implementation may use other methods of 
> > evaluating expressions, but they shall yield the same results as the 
> > method described. 
> >
> > 
> Err, but do we describe a deterministic *method* or do we describe a 
> deterministic set of conditions?

Same thing, different words.  But I want us to avoid the phrase "user 
visible" since that may trick the reader into think that we're talking 
about user interface, which we are not.  Better would be "observable 
behavior" or something similar.

> Seems to me the latter, which could be done with an abstract machine, it 

> the desired result. Yes?
> In this particular case, we describe the inputs, the output (all by 
> type) and the algorithm to apply.
> Its actual application could be accomplished by any number of "methods," 

> which any one would be free to choose.
> Yes?
> Are we just using different terminologies for nearly the same thing?

It is a different formalism but yields the same thing.  Standards that use 
an abstract machine approach tend to first lay out the capabilities of 
that abstract machine:  takes Unicode strings as input, returns Unicode 
strings as output, has access to the following atomic mathematical and 
string, operations, etc., and then defines each function as set of 
operations on that abstract machine.  Then conformance is defined simply 
as an application that has the same externally observable behavior as the 
abstract machine defined, i.e., given the same inputs yields the same 
outputs.  So it forces you to make that clear distinction.  And you have 
99% definitions and then 1% conformance language that merely says an 
implementation must have the same observable behavior.  I personally think 
this is an elegant way of defining an expression language, though there 
are certainly alternative and equivalent approaches.  But without the 
abstract machine, we'll need to be careful throughout that we are stating 
restrictions on behavior only, not restrictions on method of evaluation.

> Patrick
> > We make this allowance for sake of differing computational models. For 

> > example a spreadsheet running on a multi-processor machine might use 
> > different algorithms for calculating some functions than a 
> > single-processor machine might, although they will give the same 
> > Similarly, a smart implementation might parse an expression and decide 
> > shortcut the evaluation.  So an implementation could conceivably 
> > "sin(.1)*cos(.5)*0.0" to 0.0 without actually calculating each part of 
> > expression. We don't care what actually goes on inside, so long as it 
> > gives the same answer as the method OpenFormula describes.  In other 
> > words, we specify constraints on the output, not on the 
> >
> > For example, ISO C++ puts it like this:
> >
> > "This International Standard places no requirement on the structure of 

> > conforming implementations. In particular, they need
> > not copy or emulate the structure of the abstract machine. Rather, 
> > conforming implementations are required to emulate
> > (only) the observable behavior of the abstract machine as explained 
> > below".
> >
> > Maybe that language could be adopted? 
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

> >
> >
> > 
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

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