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

*Subject*: **Re: [office-formula] Constraints and infix ^**

*From*:**Patrick Durusau <patrick@durusau.net>***To*: Andreas J Guelzow <aguelzow@math.concordia.ab.ca>*Date*: Tue, 13 Jan 2009 14:33:08 -0500

Andreas, From below: > 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. +1! Yes! Sorry, language can be really clumsy. I fear the same result obtains for other functions as well. Hope you are having a great day! Patrick Andreas J Guelzow wrote: > 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 > -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

**References**:**Constraints and infix ^***From:*Patrick Durusau <patrick@durusau.net>

**Re: [office-formula] Constraints and infix ^***From:*Andreas J Guelzow <aguelzow@math.concordia.ab.ca>

**Re: [office-formula] Constraints and infix ^***From:*Patrick Durusau <patrick@durusau.net>

**Re: [office-formula] Constraints and infix ^***From:*Andreas J Guelzow <aguelzow@math.concordia.ab.ca>

**Re: [office-formula] Constraints and infix ^***From:*Patrick Durusau <patrick@durusau.net>

**Re: [office-formula] Constraints and infix ^***From:*Andreas J Guelzow <aguelzow@math.concordia.ab.ca>

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