Hi Patrick,
On Tue, 2009-01-13 at 13:40 -0500, Patrick Durusau wrote:
> Andreas J Guelzow wrote:
>
> <snip>
> >> According to your reading, we have prohibited 0^0 and then in a
> >> following paragraph mandated it but don't define the result.
> >>
> >> If it is prohibited, there is no valid result. (full stop)
> >>
> >
> > There has to be a result.
> >
> > If a user uses 0^0 some value _must_ be returned.
> >
> >
> Note that I said "no valid result." What result it should return is up
> to the formula standard to define.
I guess we are just disagreeing on language. To me, an "error" is a
valid result.
> > Since it violates the constraint imho it should be an Error. I guess the
> > draft wants to allow other values (namely 0 or 1 as continuous
> > continuations of related functions) but prohibit anything else.
> >
> > Personally I think it should always return an error.
> >
> >
> OK, but the draft also says (6.1, under constraints):
>
> > *
> >
> > If a constraint is not met, the function/operator *should*
> > return an Error unless otherwise noted.
> >
> That makes it appear (whether intended or not) that
> applications/implementations when executing a function/operator defined
> by OpenFormula can violate any constraint and not return an error.
> Unless the definition of a function/operator gives a specific
> instruction on what to do in the case of a constraint violation.
>
> That seems like an odd result. As I say, that is probably a mis-reading
> but it is one allowed by the text as written.
I think we may in fact be agreeing: the draft as currently written
allows virtually arbitrary return values if the constraints are not
satisfied. It seems that neither you nor I think that that is a good
idea.
Note that for this little expression 0^0 we currently have the following
return values in:
Gnumeric 1.9.4 and earlier #NUM! (so it returns an error)
Openoffice3 1 (well...)
Kspread 1.6.3 1 (well...)
Andreas
--
Andreas J Guelzow <>
Concordia University College of Alberta