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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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 11/26/09 3:24 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:] That's OFFICE-1187

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:] Broken out to OFFICE-2174


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:] Broken out to OFFICE-2175


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:] Broken out to OFFICE-2217


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:] Broken out to OFFICE-2218


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:] That's OFFICE-1187

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:] Broken out to OFFICE-2174


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:] Broken out to OFFICE-2175


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]