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

*Subject*: **[OASIS Issue Tracker] Issue Comment Edited: (OFFICE-2449) IMSUMComplexSequence and Portability**

*From*:**OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>***To*: office@lists.oasis-open.org*Date*: Thu, 1 Apr 2010 16:54:15 -0400 (EDT)

[ http://tools.oasis-open.org/issues/browse/OFFICE-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18263#action_18263 ] David Wheeler edited comment on OFFICE-2449 at 4/1/10 4:52 PM: ---------------------------------------------------------------- > The IMSUM function has a claim about applications accepting zero parameters for this function.... > If it is one or more complex numbers, by definition, then applications *cannot* allow zero complex numbers as a value, it would be a parameter type error and therefore zero complex numbers would return an error. That's the point of the "Applications may..." text. It permits, through "may", an evaluator to accept zero parameters (and return 0), without *requiring* that evaluators accept zero parameters. Whether or not 0 parameters is acceptable is implementation-defined. Obviously that's not clear enough. The same thing happens in SUM, by the way, so whatever we do to IMSUM should probably also happen to SUM. The BIN2DEC function has text that explicitly notes that something is implementation-defined, and I think I'll use wording similar to that. Doing it that way eliminates the need to talk about "portable documents", since obviously anything that is "implementation-defined" is no longer "portable". Perhaps most importantly, we can clearly limit the set of possible values, even though they are implementation-defined (in this case only an Error or 0 are acceptable). > However, it has a production that includes "ComplexSequence," which as far as I can determine isn't defined in the draft. > I suspect it means a set of complex numbers but we don't say that. Yes. The definition of IMSUM is intentionally *very* similar to SUM. Basically, IMSUM accepts "ComplexSequence" instead of "NumberSequence". So clearly we need to define "ComplexSequence"!! PROPOSAL: 1. In the "Semantics" section for function IMSUM, replace: "Applications may allow IMSUM to receive 0 parameters (and return 0), but portable documents shall not depend on IMSUM() with zero parameters returning 0. Delete: Should be inconsistent with the definition of ComplexSequence." with: "It is implementation-defined what happens if this function is given zero parameters; an evaluator may either produce an Error or the Number 0 if it is given zero parameters." 2. In the "Semantics" section for function SUM, replace: "Applications may allow SUM to receive 0 parameters (and return 0), but portable documents must not depend on SUM() with zero parameters returning 0. Delete: Implementation dependent." with: "It is implementation-defined what happens if this function is given zero parameters; an evaluator may either produce an Error or the Number 0 if it is given zero parameters." 3. Add a new section, "Conversion to ComplexSequence", immediately after the section "Conversion to Complex Number" (currently 5.3.10). Thus, the new section will start as 5.3.11. I propose the following text for this new section, which is very similar to the current text for "Conversion to NumberSequence" but modified by the text for "Conversion to Complex Number". === If the expected type is ComplexSequence, then if value is of type: * Number, Text, or Logical, handle as Conversion to Complex Number (creating a sequence of length 1). * Reference, create a sequence of complex numbers from the values of the referenced cells that only includes the values of type Number, Text, and Error. Empty cells are not included in a complex number sequence. If the logical type is a distinguished type from the Number type, it should not be included in the sequence of numbers; if the logical type is not a distinguished type, then such values will (of course) be included in the number sequence. === I believe this will resolve the issue. I've reused a lot of existing material, and I believe it simple clarifies the already-existing intent. Discussion welcome!! PROPOSE-RESOLVED was (Author: david.wheeler): > The IMSUM function has a claim about applications accepting zero parameters for this function.... > If it is one or more complex numbers, by definition, then applications *cannot* allow zero complex numbers as a value, it would be a parameter type error and therefore zero complex numbers would return an error. That's the point of the "Applications may..." text. It permits, through "may", an evaluator to accept zero parameters (and return 0), without *requiring* that evaluators accept zero parameters. Whether or not 0 parameters is acceptable is implementation-defined. Obviously that's not clear enough. The same thing happens in SUM, by the way, so whatever we do to IMSUM should probably also happen to SUM. The BIN2DEC function has text that explicitly notes that something is implementation-defined, and I think I'll use wording similar to that. Doing it that way eliminates the need to talk about "portable documents", since obviously anything that is "implementation-defined" is no longer "portable". Perhaps most importantly, we can clearly limit the set of possible values, even though they are implementation-defined (in this case only an Error or 0 are acceptable). > However, it has a production that includes "ComplexSequence," which as far as I can determine isn't defined in the draft. > I suspect it means a set of complex numbers but we don't say that. Yes. The definition of IMSUM is intentionally *very* similar to SUM. Basically, IMSUM accepts "ComplexSequence" instead of "NumberSequence". So clearly we need to define "ComplexSequence"!! PROPOSAL: 1. In the "Semantics" section for function IMSUM, replace: "Applications may allow IMSUM to receive 0 parameters (and return 0), but portable documents shall not depend on IMSUM() with zero parameters returning 0. Delete: Should be inconsistent with the definition of ComplexSequence." with: "It is implementation-defined what happens if this function is given zero parameters; an evaluator may either produce an Error or the Number 0 if it is given zero parameters." 2. In the "Semantics" section for function SUM, replace: "Applications may allow SUM to receive 0 parameters (and return 0), but portable documents must not depend on SUM() with zero parameters returning 0. Delete: Implementation dependent." with: "It is implementation-defined what happens if this function is given zero parameters; an evaluator may either produce an Error or the Number 0 if it is given zero parameters." 3. Add a new section, "Conversion to ComplexSequence", immediately after the section "Conversion to Complex Number" (currently 5.3.10). Thus, the new section will start as 5.3.11. I propose the following text for this new section, which is very similar to the current text for "Conversion to NumberSequence" but modified by the text for "Conversion to Complex Number". === If the expected type is ComplexSequence, then if value is of type: * Number, Text, or Logical, handle as Conversion to Complex Number (creating a sequence of length 1). * Reference, create a sequence of complex numbers from the values of the referenced cells that only includes the values of type Number, Text, and Error. Empty cells are not included in a complex number sequence. If the logical type is a distinguished type from the Number type, it should not be included in the sequence of numbers; if the logical type is not a distinguished type, then such values will (of course) be included in the number sequence. === I believe this will resolve the issue. I've reused a lot of existing material, and I believe it simple clarifies the already-existing intent. Discussion welcome!! > IMSUM ComplexSequence and Portability > ------------------------------------- > > Key: OFFICE-2449 > URL: http://tools.oasis-open.org/issues/browse/OFFICE-2449 > Project: OASIS Open Document Format for Office Applications (OpenDocument) TC > Issue Type: Bug > Components: OpenFormula > Reporter: Patrick Durusau > Assignee: David Wheeler > Fix For: ODF 1.2 Part 2 CD 2 > > > The IMSUM function has a claim about applications accepting zero parameters for this function. However, it has a production that includes "ComplexSequence," which as far as I can determine isn't defined in the draft. > I suspect it means a set of complex numbers but we don't say that. > If it is one or more complex numbers, by definition, then applications *cannot* allow zero complex numbers as a value, it would be a parameter type error and therefore zero complex numbers would return an error. -- 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]