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

*Subject*: **[OASIS Issue Tracker] Commented: (OFFICE-2585) Pseudotypes and thereturn of errors**

*From*:**OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>***To*: office@lists.oasis-open.org*Date*: Sat, 6 Mar 2010 18:22:15 -0500 (EST)

[ http://tools.oasis-open.org/issues/browse/OFFICE-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890#action_17890 ] Dennis Hamilton commented on OFFICE-2585: ----------------------------------------- I think what these are consist of restrictions on types. For example, Integer is essentially a restriction on the Number type. Restrictions can lead to implicit conversions. There is also the situation where, apart from the mathematical definition of a function, there are limitations on how that applies as a computational definition. In the simple case of number-theoretic functions and operations, the difference between what is computationally definable and what is mathematically definable can be acute. For example, a very large Integer value represents an exact integer, but it doesn't behave as a mathematical integer. The function ISODD may be meaningless, because the large values are not precise to the units position, just and n+1 and n-1 may be no different than n. The function MOD(n,10) may similarly be meaningless, and so on. There are cases where we need to say that a function is computationally specified only within some tolerance and there is nothing said about what the results are beyond the specified region. Sometimes the specified computation and the constraints will agree, but I think that is often not the case. The mathematical functions that don't demand discrete precision do better, but there are still isues of scale. For example, SIN(x) becomes ridiculous at some large-enough value of x where range reduction to something like -π/2 < x < +π/2 becomes so inaccurate as to be useless. Some type restrictions (e.g., for Precise Integer) need to be introduced because there are many functions that are only computationally specified for arguments that are in a restricted subset, even though the actual subset is implementation-dependent. But, even though the subset may be implementation-dependent, the limitation that a function is specified in OpenFormula only for that computationally-limited case seems like a wise thing to do. I also believe that these restrictions can be defined sharply enough that an user and any other expert can inspect an implementation to determine what the facts of the matter are. (I offered the NumCheck 0.10 upload as a demonstration that this seems to be clearly possible for Precise Integer and Strict Integer, as defined there, and I think it is clear that this is valuable and important.) > Pseudotypes and the return of errors > ------------------------------------ > > Key: OFFICE-2585 > URL: http://tools.oasis-open.org/issues/browse/OFFICE-2585 > Project: OASIS Open Document Format for Office Applications (OpenDocument) TC > Issue Type: Bug > Reporter: Patrick Durusau > > In 5.2, under Semantics we say: "If a parameter is a pseudotype, but the provided value fails to meet the requirements for that type, a function/operator may return an Error value." > If a value doesn't meet the requirements for the pseudotype, what result could there be other than error? > If there are different results, how does this "standard" enable interoperability? -- 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

**References**:**[OASIS Issue Tracker] Created: (OFFICE-2585) Pseudotypes and thereturn of errors***From:*OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>

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