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

*Subject*: **[OASIS Issue Tracker] Updated: (OFFICE-2470) 3.2 ExpressionCalculation is a mixure of observations, rules and possible suggestions**

*From*:**OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>***To*: office@lists.oasis-open.org*Date*: Wed, 27 Oct 2010 12:37:24 -0400 (EDT)

[ http://tools.oasis-open.org/issues/browse/OFFICE-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eike Rathke updated OFFICE-2470: -------------------------------- Proposal: Change entire section 3.2 Expression Calculation to: Expressions in OpenFormula *shall* be evaluated by application of the following rules: 1. If an expression consists entirely of a Number, Text or Error, the Number, Text or Error is returned. 2. If an expression consists entirely of a Reference, the resolved Reference is returned if the Reference refers a single cell. If the Reference does not refer a single cell, the rules of section 3.3 (Non-Scalar Evaluation) 1.2) apply. 3. If an expression consists entirely of an Array, the Array is returned. For the display area the rules of section 3.3 (Non-Scalar Evaluation) 1.1) apply. 4. If an expression consists of one or more operations, apply operators in order of precedence and associativity. Precedence of operators may be altered by the use of "(" (LEFT PARENTHESES, U+0028) and ")" (RIGHT PARENTHESES, U+0029) to group operators. NOTE: Precedence and associativity of operators are defined by Table 1 in 5.5 (Operators). Operators and functions in OpenFormula are evaluated according to their definitions by application of the following rules: 1. The values of all argument expressions are computed, that is, formulas are normally "eagerly" evaluated. Exceptions to eager evaluation are noted in the function's specification. 2. If an argument expression evaluates to Error, calculation of the operator or function may short-circuit and return the Error if the function does not suppress error propagation as noted in the function's specification. 3. If an operator or function is passed a value of incorrect type, call the appropriate implicit conversion function to convert the value to the correct type. If conversion is not possible, generate an Error. was: Expressions in OpenFormula *shall* be evaluated by application of the following rules until no further evaluations remain: 1. If an expression consists entirely of a number, string or error, the number, string, or error is returned. 2. If an expression consist entirely of a reference, the reference is returned. 3. If an expression consists of one or more operations, apply operators in order of precedence and associativity. Precedence of operators may be altered by the use of "(" (LEFT PARENTHESES, U+0028) and ")" (RIGHT PARENTHESES, U_0029) to group operators. NOTE: Precedence and associativity of operators are defined by Table 1. 4. If an operator is passed a value of incorrect type, the appropriate implicit conversion function is called to convert the value to the correct type. Functions in OpenFormula are evaluated according to their definitions, and *shall*: 1. Evaluate function parameters in left to right order. 2. If a function is passed a value of incorrect type, call the appropriate implicit conversion function to convert the value to the correct type. Description: 3.2 Expression Calculation is a mixture of observations, rules and possible suggestions. For example, it starts by saying formulas are recalculated from "outside in," only to confess a few paragraphs later that is how it "appears to the end user." There is one really glaring hole in my proposal, that also exists in the current language. We describe the ordering of operators but as far as I can tell, we don't address the situation where there is a mixture of operators and functions. Note that I changed #1 from constant number/string and added error. As near as I can determine, the only possible outcomes of any expression are: 1) a number 2) a string 3) an error 4) a reference So, application of these rules self-terminates when any of those conditions obtain. Yes, that removes "constant number," "constant string" but those are defined elsewhere anyway. was: Change entire section 3.2 Expression Calculation to: Expressions in OpenFormula *shall* be evaluated by application of the following rules: 1. If an expression consists entirely of a Number, Text or Error, the Number, Text or Error is returned. 2. If an expression consists entirely of a Reference, the resolved Reference is returned if the Reference refers a single cell. If the Reference does not refer a single cell, the rules of section 3.3 (Non-Scalar Evaluation) 1.2) apply. 3. If an expression consists entirely of an Array, the Array is returned. For the display area the rules of section 3.3 (Non-Scalar Evaluation) 1.1) apply. 4. If an expression consists of one or more operations, apply operators in order of precedence and associativity. Precedence of operators may be altered by the use of "(" (LEFT PARENTHESES, U+0028) and ")" (RIGHT PARENTHESES, U+0029) to group operators. NOTE: Precedence and associativity of operators are defined by Table 1 in 5.5 (Operators). Operators and functions in OpenFormula are evaluated according to their definitions by application of the following rules: 1. The values of all argument expressions are computed, that is, formulas are normally "eagerly" evaluated. Exceptions to eager evaluation are noted in the function's specification. 2. If an argument expression evaluates to Error, calculation of the operator or function may short-circuit and return the Error if the function does not suppress error propagation as noted in the function's specification. 3. If an operator or function is passed a value of incorrect type, call the appropriate implicit conversion function to convert the value to the correct type. If conversion is not possible, generate an Error. > 3.2 Expression Calculation is a mixure of observations, rules and possible suggestions > -------------------------------------------------------------------------------------- > > Key: OFFICE-2470 > URL: http://tools.oasis-open.org/issues/browse/OFFICE-2470 > Project: OASIS Open Document Format for Office Applications (OpenDocument) TC > Issue Type: Bug > Components: OpenFormula > Affects Versions: ODF 1.2 CD 05 > Reporter: Patrick Durusau > Assignee: Eike Rathke > Fix For: ODF 1.2 CD 06 > > > 3.2 Expression Calculation is a mixture of observations, rules and possible suggestions. > For example, it starts by saying formulas are recalculated from "outside in," only to confess a few paragraphs later that is how it "appears to the end user." > There is one really glaring hole in my proposal, that also exists in the current language. > We describe the ordering of operators but as far as I can tell, we don't address the situation where there is a mixture of operators and functions. > Note that I changed #1 from constant number/string and added error. > As near as I can determine, the only possible outcomes of any expression are: > 1) a number > 2) a string > 3) an error > 4) a reference > So, application of these rules self-terminates when any of those conditions obtain. > Yes, that removes "constant number," "constant string" but those are defined elsewhere anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

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