OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

# office-formula message

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

Subject: Re: [office-formula] Formula Terminology

• From: Andreas J Guelzow <aguelzow@math.concordia.ab.ca>
• To: office-formula@lists.oasis-open.org
• Date: Wed, 13 Jan 2010 19:03:45 -0700

```On Wed, 2010-01-13 at 20:31 -0500, Patrick Durusau wrote:
> Andreas,
>
> Andreas J. Guelzow wrote:
> > On Wed, 2010-01-13 at 17:29 -0500, robert_weir@us.ibm.com wrote:
> >
> >> 2) What happens if the constraints are violated?
> >>
> >> Compare to RATE():
> >>
> >>  If Nper is 0 or less than 0, the result is an error.
> >>
> >> Do we really mean to say that constraint violations are errors in some
> >> functions, but not in others?
> >>
> >
> > please see  5.2: "If a constraint is not met, the function/operator
> > should return an Error unless otherwise noted." This issue comes up
> > again and again. I guess that is the drawback of mentioning common
> > properties and behaviour only once!
> >
> >

There are surely lots of places in the description where we should have
constraints rather than talking about error returns.

>
> 5.4.5 Infix Operator "/" - "Dividing by zero returns an Error.
>
> Note that this operator is reported to have Constraints: *none*

This of course would be a perfect place for a constraint!

>
> 5.4.12 Infix Operator Reference Intersection ("!")
>
> > If for all intersections there are no cells in common and the result
> > list is empty, error #NULL! is returned.

This is really bad: We never define the #NULL! error (nor should we). In
fact the only error that we require is #NA!

> >
> 5.5.3 MINVERSE
>
> > If the matrix is not invertible, this function *should* return an
> > error value.

I am not quite sure whether we can/should formulate this as a
constraint.
> >
> That is just a sampling.

I didn;t say that we should never talk about errors, but failure to
satisfy a constraint should yield an error unless stated otherwise.
>
> Please assign the issue to me.
>
> I am less certain about the resolution, although obviously we need to be
> consistent, sometimes the difference in what is said may be meaningful.
>
> Suggest that we add an issue to JIRA to make a special effort to check
> the use of "error."
>
> Hope you are having a great evening!

And I hope you  do too!

Andreas

--
Andreas J. Guelzow
Concordia University College of Alberta

```

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