RE: [office-formula] constraint of ACOT

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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