[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-790) PublicComment: ODFF: more suggestions
[ http://tools.oasis-open.org/issues/browse/OFFICE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109#action_15109 ] Eike Rathke edited comment on OFFICE-790 at 8/12/09 5:01 PM: ------------------------------------------------------------- The comment lists several topics, marking my comments on them with [ed:] POISSON: - I suggest further Constraints: 'x and lambda should be integer'. [ed:] current draft hast it, no action needed. FORECAST: - parameters given in the wrong order (at least for Calc, Excel) [ed:] has been corrected, no action needed. NumberSequence: - is a type, but undefined. There ought to be a plain list of parameter types in the index - section 6.2.6 defines conversion to this type, not the type itself. In other words, the function descriptions should give parameter types which can be looked up in one place in the index. [ed:] NEEDS-DISCUSSION: Do we really need to define parameter types as distinct types? Parameter types such as NumberSequence are placeholders, the actual argument types are converted in a defined way. See OFFICE-1187 for a separate issue about this. NumberSequence: - 6.2.6 makes no reference to how the sequence is generated - rows before columns? columns before rows? Order is vital for example in CORREL. [ed:] the order in which the sequence is generated does not matter if not stated otherwise for specific function's parameters. [ed:] TODO: state order dependency for CORREL, PEARSON, and possibly other functions. CORREL: - NumberSequence could be generated by ignoring eg text. Say 2 columns of numbers with some text entries, in different rows. As currently defined CORREL would happily correlate that nonsensical data, as long as the lengths were the same. Should be defined to return an error. [ed:] TODO: check how applications handle that. ZTEST: - Calc has had a bug - with 3 parameters it simply gave an incorrect result. Excel produces a result which I contend is 'one-sided' (not 'one-tailed'). It's a ridiculous result, but can be used. There's a back-to-basics review at http://qa.openoffice.org/issues/show_bug.cgi?id=90759 that might help to put this one to rest. [ed:] actually that issue does not put the one-sided vs. two-sided debate to rest. TODO: does anyone have insights on this? MATCH: - Doesn't currently say anything about what type of error is returned. Shouldn't a failed search always return #N/A, which is testable? From Section 4.5: "one error value in particular is distinct: #N/A" [ed:] current draft specifies #N/A to be returned, no action needed. DDE: - "mode 0 - Data converted to number(s) using the default cell style" - actually data is only converted to number (singular I think) if possible, otherwise text is returned. - Is it converted using VALUE, or some other way? - The "default cell style" is mentioned here for the first and only time - does this imply this function is only for spreadsheets? Shouldn't there be a bit more about the "default cell style"? [ed:] TODO: check details. CHOOSE: - In 3.1 Expression Syntax: " 3a The values of all argument expressions are computed, that is, formulas are normally "eagerly" evaluated. Exceptions to eager evaluation are noted in the function or operation's specification;" =CHOOSE(1;SQRT(4);STYLE("Heading")) in Calc does *not* evaluate the STYLE function. Might be a problem with Calc, but I suspect that we need to note an exception to eager evaluation for CHOOSE. (STYLE is specific to Calc - it's simply the example I found.) [ed:] current draft says in the definition of CHOOSE "Expression paths of parameters other than the one chosen are not calculated or evaluated for side effects.", no action needed. was (Author: erack): The comment lists several topics, marking my comments on them with [ed:] POISSON: - I suggest further Constraints: 'x and lambda should be integer'. [ed:] current draft hast it, no action needed. FORECAST: - parameters given in the wrong order (at least for Calc, Excel) [ed:] has been corrected, no action needed. NumberSequence: - is a type, but undefined. There ought to be a plain list of parameter types in the index - section 6.2.6 defines conversion to this type, not the type itself. In other words, the function descriptions should give parameter types which can be looked up in one place in the index. [ed:] NEEDS-DISCUSSION: Do we really need to define parameter types as distinct types? Parameter types such as NumberSequence are placeholders, the actual argument types are converted in a defined way. - 6.2.6 makes no reference to how the sequence is generated - rows before columns? columns before rows? Order is vital for example in CORREL. [ed:] the order in which the sequence is generated does not matter if not stated otherwise for specific function's parameters. [ed:] TODO: state order dependency for CORREL, PEARSON, and possibly other functions. CORREL: - NumberSequence could be generated by ignoring eg text. Say 2 columns of numbers with some text entries, in different rows. As currently defined CORREL would happily correlate that nonsensical data, as long as the lengths were the same. Should be defined to return an error. [ed:] TODO: check how applications handle that. ZTEST: - Calc has had a bug - with 3 parameters it simply gave an incorrect result. Excel produces a result which I contend is 'one-sided' (not 'one-tailed'). It's a ridiculous result, but can be used. There's a back-to-basics review at http://qa.openoffice.org/issues/show_bug.cgi?id=90759 that might help to put this one to rest. [ed:] actually that issue does not put the one-sided vs. two-sided debate to rest. TODO: does anyone have insights on this? MATCH: - Doesn't currently say anything about what type of error is returned. Shouldn't a failed search always return #N/A, which is testable? From Section 4.5: "one error value in particular is distinct: #N/A" [ed:] current draft specifies #N/A to be returned, no action needed. DDE: - "mode 0 - Data converted to number(s) using the default cell style" - actually data is only converted to number (singular I think) if possible, otherwise text is returned. - Is it converted using VALUE, or some other way? - The "default cell style" is mentioned here for the first and only time - does this imply this function is only for spreadsheets? Shouldn't there be a bit more about the "default cell style"? [ed:] TODO: check details. CHOOSE: - In 3.1 Expression Syntax: " 3a The values of all argument expressions are computed, that is, formulas are normally "eagerly" evaluated. Exceptions to eager evaluation are noted in the function or operation's specification;" =CHOOSE(1;SQRT(4);STYLE("Heading")) in Calc does *not* evaluate the STYLE function. Might be a problem with Calc, but I suspect that we need to note an exception to eager evaluation for CHOOSE. (STYLE is specific to Calc - it's simply the example I found.) [ed:] current draft says in the definition of CHOOSE "Expression paths of parameters other than the one chosen are not calculated or evaluated for side effects.", no action needed. > Public Comment: ODFF: more suggestions > -------------------------------------- > > Key: OFFICE-790 > URL: http://tools.oasis-open.org/issues/browse/OFFICE-790 > Project: OASIS Open Document Format for Office Applications (OpenDocument) TC > Issue Type: Bug > Components: OpenFormula > Affects Versions: ODF 1.2 > Reporter: Robert Weir > Assignee: Eike Rathke > Priority: Blocker > Fix For: ODF 1.2 > > > Copied from office-comment list > Original author: "David King" <openoffice@drking.plus.com> > Original date: 25 Jun 2008 07:32:37 -0000 > Original URL: http://lists.oasis-open.org/archives/office-comment/200806/msg00059.html -- 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]