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

*Subject*: **RE: [office-formula] constraint of ACOT**

*From*:**"Dennis E. Hamilton" <dennis.hamilton@acm.org>***To*: <robert_weir@us.ibm.com>,<office-formula@lists.oasis-open.org>*Date*: Wed, 6 Jan 2010 11:53:12 -0800

CAVEAT: It is probably not in scope to require that OpenFormula be usable for astronomical and physics-based computations of great precision (and the great Java disclaimer on use in life-critical situations comes to mind). It *is* probably appropriate to have boundary conditions dealt with in a way where those folks who need to work near discontinuities and domain boundaries (or stumble over them inadvertently) are on notice to provide their own safeguards against failing computations and are at least notified that failure is an option. There is a degree to which the OpenFormula specification needs to delimit what can be counted on and what is expected in that regard, especially in how computations are expected to fail in extremities when fail they must. Even if we choose not to say, we must make that much explicit what it is we are choosing not to specify. Having said that, our best guidance is probably in areas of expert use that we need to somehow apply appropriately for OpenFormula. I am not proposing a solution, below. I think we need to get our heads around all aspects of the problem first, along with identifying the current state of the art with respect to spreadsheet formulas and seeing what reconciliation, if required, is practicable. - Dennis EXPLORATION OF THE ISSUES WHEN OPENFORMULA COLLIDES WITH (COMPUTATIONAL) MATHEMATICS I see at least four concerns in the ACOT case. 1. Specification of bounds on results are technically not constraints. It should be part of the definition of the function and what the implemented results are. One would not expect the function implementation to be such that it would have to raise an exception or report an error. An implementation is expected to produce its result in the stated range by definition. The exception is for results that are out of range for representation as Number, such as EXP(veryLargeArgument), and I notice that OpenFormula is mainly silent about that with regard to individual function implementations. 2. There are issues with sharp constraints that apply mathematically and how they are to be realized/expressed in terms of what a computational realization must accomplish. This applies to both constraints on (mathematical) values represented by (computational) parameters and the way a result is represented. This is already the subject of another thread and comments on a couple of other issues. (See, e.g., OFFICE-2209 and OFFICE-2246.) 3. Finally, this particular prose range specification is stated imprecisely with regard to "between-ness". I assume that it is 0 < r <= mathematical-pi in the manner used elsewhere in OpenFormula (but see 4, below). Alternatively, it might be saying that it is a characteristic of the computational realization, using OpenFormula to say AND(0 < ACOT(x); ACOT(x) <= PI()) is always true for any expressible Number x. I think this is not helpful with regard to computational imprecision/rounders/underflows/overflows and how that applies in the vicinity of (mathematical) boundary/discontinuity cases. We are passing the buck to "<" and "<=" and that may be unsavory. 4. Specifically with regard to the principal values of non-unique inverses: Since cot(x) has no unique inverse, the convention is to produce a principal value for arccot(x). 4.1 The conventional definition of that principle value avoids discontinuity at arccot(x) -> 0 (and arccot(x) -> pi) by having 0 <= arccot(x) <= pi/2 when 0 <= x, and pi/2 < arccot(x) <= pi when x < 0. [Abramowitz and Stegun (1965), Handbook of Mathematical Functions. Available via <http://www.math.ucla.edu/~cbm/aands/>] 4.2 Notice that 0 and pi are only approachable in the limit in the mathematical case. To define 0 < ACOT(x) < pi strictly might be inadvisable considering that there are values of x for which arccot(x) is closer to 0 (or mathematical pi) than to any representable 0+epsilon or pi-epsilon. 4.3 I SUSPECT that there may be answers to this question in the standard mathematical libraries that numerical analysts and mathematicians are satisfied with. If the functions have hardware implementations in accordance with IEEE-754 and related work (i.e., <http://grouper.ieee.org/groups/754/>), we might want to take a lead from there too, adjusting for the fact that OpenFormula does not provide for representation of NaN, -Inf, and +Inf. This might even answer important questions on how PI() should approach mathematical pi. [4.4 ASIDE: The use of bounds -pi/2 to +pi/2 might be technically interesting because the density of approximation is a little better (by the subtraction of pi) in contrast to representing results in the pi/2 < .. <= pi range for x < 0. On the other hand, it appears to be awful for arccot(x) when x is in the neighborhood of 0, making small errors in x into big problems, a feature that is dramatically visible at <http://mathworld.wolfram.com/InverseCotangent.html>. I guess you choose your poison. [4.5 For OpenFormula, smoothness around x = 0 seems more prudent to consider in comparison with squeaking out a little more precision in the answer for x < 0), especially considering how much work it takes to successfully capture that extra precision. [4.6 I haven't looked at the added complexities around how the choice impacts which cases of COT(ACOT(x)) = x and ACOT(COT(y)) = y (approximately) arise easily and most intuitively and which might be preferable for easily testing/demonstrating/confirming the quality of an implementation, yet further considerations for the desirability of a particular approach in OpenFormula. [4.7 Finally, I have ignored the need for any harmony with IMCOT(z) and how a IMACOT(z) might be defined for Complex z since we don't seem to be taking OpenFormula to such heights. Whew.] - Dennis -----Original Message----- From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] Sent: Wednesday, January 06, 2010 09:05 To: office-formula@lists.oasis-open.org Subject: Re: [office-formula] constraint of ACOT Is the objection over the reference to PI() rather than directly using the Greek letter Pi? Or is the choice of convention the problem? According to http://mathworld.wolfram.com/InverseCotangent.html there are two conventions: (0,Pi) or (-Pi/2, Pi/2). The former is continuous, while that later has a discontinuity at 0. -Rob "Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca> wrote on 01/06/2010 11:15:44 AM: > > ACOT has the constraint "The result must be between 0 and PI()." This > doe snot look like a valid constraint to me. > > ANdreas > -- > Andreas J. Guelzow, PhD, FTICA > Mathematical & Computing Sciences > Concordia University College of Alberta > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

**References**:**constraint of ACOT***From:*"Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca>

**Re: [office-formula] constraint of ACOT***From:*robert_weir@us.ibm.com

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