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

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

*From*:**"Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca>***To*: office-formula@lists.oasis-open.org*Date*: Wed, 06 Jan 2010 12:28:29 -0700

On Wed, 2010-01-06 at 13:00 -0500, robert_weir@us.ibm.com wrote: > In other words, what is the behavior when a constraint is violated? Do we > simply say this is non conforming? We address the issue of constraint violation in 5.2. This has nothing to do with nonconforming since constraint violation is a result of users/calculation. Typically these constraints act on the input, e.g. SQRT has the constraint that its parameter is non-negative. SO if it happens to be passed a negative number a conforming evaluator is supposed to return an error. My problem with ACOT is that the constraint given does not act on the input. > That it is implementation-dependent, > or implementation-defined? That it returns an error? That it returns a > specific error? An error (see 5.2) There are no specific errors defined, we only know that there is at least NA(). > > Ideally we'd want to be specific about what the constraint is and describe > these uniformly. I imagine we have domain constraints, data type > constraints, range constraints, ordering constaints, syntactical > constraints, etc. Ideally we'd have a clear taxonomy of these types of > constraints, apply them clearly, and map violation of each of these > constraints to a unique error class: domain error, data type error, range > error, etc. > > However, we're a bit hampered by the restricted and illogical error codes > used by legacy spreadsheets. For example in Excel #NUM! conflates > entirely different errors types including numeric overflow like in > EXP(1000) or violation or ordering constraints like RANDBETWEEN(5,0). > Other spreadsheets do equally strange things. > > Of course, it is possible to be more precise in OpenFormula, but if we did > we'd need to allow implementations to treat these error classes > interchangeably. This is unfortunate, but unless the vendors step up and > agree to rationalize their error codes, we have this legacy mess. That's why OpenFormula currently only says "some error". And the only special error is NA. > Andreas > > "Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca> wrote on 01/06/2010 > 12:19:50 PM: > > > > > Hi Rob, > > > > On Wed, 2010-01-06 at 12:04 -0500, robert_weir@us.ibm.com wrote: > > > 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. > > > > No, my problem is much more pedestrian: > > > > If a constraint is violated the function should return an error. So how > > can a constraint talk about the function result? > > > > Suppose the return value is a number not in the range from 0 to PI(), > > then by the return value must be an error, since the constraint is > > violated. But if it is an error then it doesn't violate teh constriant > > anymore.... > > > > I think that should not be a constraint. > > > > (We might want to add to the semantics that we are returning the > > principal value or the value derived from the branch through (1,PI()/4, > > but that wasn't my problem.) > > > > Andreas > > > > > "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 > > > > > > > > -- > > 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 > > > > > --------------------------------------------------------------------- > 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 > -- Andreas J. Guelzow, PhD, FTICA Mathematical & Computing Sciences Concordia University College of Alberta

**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

**Re: [office-formula] 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]