[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2209) When are exactnumerical results required?
[ http://tools.oasis-open.org/issues/browse/OFFICE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16921#action_16921 ] Dennis Hamilton commented on OFFICE-2209: ----------------------------------------- I noticed a related situation with regard to equalities and inequalities that are presented in the specification of operations and functions. For example, when a mathematical function is only defined for arguments -1 < x < 1, how strict is the inequality given in the Constraints entry when the argument representing x is of type Number and may have slight errors of approximation? Likewise, when there are constraints or ranges with limits based on the mathematical constant, pi, how does that relate to the value that is delivered as a representation of pi by the PI() constant function? - - - - - - Further observations: I have no idea what we can say around edge cases like these. I am even less clear how an user could create formulas that avoided edge-case misadentures (e.g., violation of a strict constrant and producing an error value because of a rounding/truncation that strikes a discontinuity in the mathematically-defined function). An easy example that comes to mind is the situation where LN(x) fails because the computation for x underflows to 0 (although mathematically, ln(x) is a representable value) and other places where mathematical identities fail computationally (e.g., x = EXP(LN(x)), x > 0). I don't think there is any safeguard for such situations. On the other hand, there might be something constructive to be said in the specification of what can be counted on (or not) in the implementations of such functions. Perhaps we can handle this with observations concerning the ±ε vicinity in most cases. > When are exact numerical results required? > ------------------------------------------ > > Key: OFFICE-2209 > URL: http://tools.oasis-open.org/issues/browse/OFFICE-2209 > Project: OASIS Open Document Format for Office Applications (OpenDocument) TC > Issue Type: Bug > Components: OpenFormula Test Cases > Affects Versions: ODF 1.2 > Reporter: Robert Weir > Fix For: Task > > > Test case for TAN() currently is: > =TAN(PI()/4.0) > with an expected result of: > 1±ε > However a test case for LOG() is: > =LOG(8*8*8; 8) > with expected result of 3 (with no epsilon). > Is this intentional? I suspect that few implementations are going to be optimized to produce exact results here. > Do we have a general rule here? Shouldn't it be that any function that has a domain of real numbers should be allowed an epsilon on test results? And only functions whose domain consists of the integers should be required to give exact results? -- 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