[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*: Wed, 21 Jan 2009 08:55:57 -0500

Andreas, Andreas J Guelzow wrote: > On Wed, 2009-01-21 at 06:25 -0500, Patrick Durusau wrote: > >>> "Implementation-defined" means that the implementation is free to >>> pick from a set of possibilities, as long as that selection meets the >>> other requirements of the spec. If the spec limits the set of >>> permissible returns, then it must be one of those possible returns. >>> >>> >> Oh, no, sorry, at least as I experience standards writing that simply >> isn't true. >> >> If I wanted to say that, I would say: >> >> "There are three (or whatever number) answers to X. Those answers are: >> (list here). For purposes of this standard, each of these answers is >> equivalent to the others for all purposes." >> >> That gets you applications that recognize all the possible answers while >> allowing them to return which ever one they prefer. But they have to >> recognize the others. >> > > All of this arose from the discussion which value the formula 0^0 should > return. In this context"recognizing the oterhs doesn't make any sense > whatsoever. > > Well, I am assuming that an application can recognize the case where the formula 0^0 occurs in order for us to say anything about it at all. If that is the case, then surely an application can also recognize one of the three results that David wants to define. That is if an application gets a document with the formula 0^0 and the *recorded* result #1, or #2, or #3, why can't it recognize that result as being one of the three that we define? Unless you are presuming that all formulas will be calculated every time a document is loaded, which seems like a lot of overhead to me. Or really for that matter, we could say that since all three results are the same, simply replace whatever is found with the one your application prefers. Well, but I do suspect there are places where substitution may not be appropriate but if that is the case, then we need to fall back to implementation defined and let it go at that. What am I missing? Hope you are having a great day! Patrick -- 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)

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

**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:*"David A. Wheeler" <dwheeler@dwheeler.com>

**Re: [office-formula] Constraints and infix ^***From:*robert_weir@us.ibm.com

**Re: [office-formula] Constraints and infix ^***From:*"David A. Wheeler" <dwheeler@dwheeler.com>

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

**Re: [office-formula] Constraints and infix ^***From:*"David A. Wheeler" <dwheeler@dwheeler.com>

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