[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-formula] Forced Recalculation?
Interesting, Patrick, I think the distinctions in 4.2 are incorrect. A. In my analysis, below, am certain I have missed some cases, and this might not be what the proposers of the forced-recalculate flag had in mind at all. However, I think this is enough to establish that we need a better explanation of what the flag is intended to accomplish and how it accomplishes it. B. Having done all that thinking out loud, below, I would say that maybe we want to say something like this: B.1 In a situation where forced-calculate cannot matter (or cannot even occur, as when a formula is not one that another formula can depend on in any way), it would seem appropriate to say that the evaluator shall ignore the flag. (Also, when already evaluating a formula, it certainly doesn't matter whether or not the flag is there: the decision to evaluate has been made.) B.2 In other situations where there would be a difference, but forced-recalculation is not required to be honored by the hosting (implementation), I suspect the behavior of the flag being encountered where it might matter is something that the hosting must specify, e.g., that it shall be ignored, that it shall be treated as a non-fatal error condition (because the author of the formula has a requirement that is not going to be satisfied), or that the behavior is implementation-defined/-dependent. The hosting (implementation) might deal with this differently in different contexts where an OpenFormula formula is permitted. - Dennis INSTANT ANALYSIS: 1. First, consider that a cell whose value is determined by a formula is "volatile" (separate from being directly modified/updated) if the determining formula is volatile - that is, the formula can have a different result each time its value is established. (The prospect of read-only or locked cells adds variations I am not going to even think about here.) 2. A formula can have a different value each time it is evaluated -- a (re-)calculation event -- because it directly relies on a number of functions that are explicitly *always* volatile (e.g., "=RAND()", however actually written). Such functions are not well-defined, in the mathematical sense. Mathematically well-defined functions always determine the same value whenever their parameters have the same values. 3. A formula can also be determined to have a different value because there are operands that depend on current values of cells that are themselves volatile. The volatility of cells referenced as operands can be because they are determined by volatile formulas themselves or because they are subject to direct modification of their values or their formulas by other means and such modifications have occured since any previous evaluation. 4. In general, it does not matter whether a recalculation occurs when the result cannot be different. 5. The problem of recalculation control has to do with when a recalculation *need* *not* *be* *done* even though the result could be different. Then there's the matter of it being *undesirable* (according to what the user has in mind) to do a particular recalculation because a stable value is wanted despite the volatility. 6. (Unfortunately, we don't have a need-not-recalculate flag, but even if we did we would be stuck with the fact that it is not enough to impose one more binary choice.) 7. There are two interdependent conditions that are not clear here. I think these need to be covered sufficiently to allow us to specify what a hosting of OpenFormula in a document format (and then implementations of processors for that hosting) must decide: when dependencies are resolved and when alterations lead to updating of dependent situations. 7.1. We know we are evaluating the formula that is "in hand" because we are describing how that value shall be determined. We don't know or care how it came to pass that this is happening. We are describing what value is determined whenever that is the case. 7.2. So we know that the occurrences of volatile functions will be evaluated if we are already evaluating a formula. The interesting case is when there is a reference to a cell (or array) and there is already a value for that cell and it was determined by a formula. (This is not an exhaustive analysis. My head hurts already.) 7.3 If the processing model is based on the assumption that volatile cells are always "current" then we don't have to consider determining the value for that cell, we can use the value that is there (since there should always be one.) 7.4 If we know that volatile cells are not automatically current (or we have a way of telling that a volatile cell is caching a value that is not necessarily current), then the (current) value determined by the formula for that cell must be (re-)established and then used for the formula we are working on. This can, of course lead recursively into determining the value of a formula other than the one we are working on and it is not OK if that leads to a dependency on a formula that is in the process of being recalculated. [Note that a workaround for that case is to use the not-updated value if one is known, try iteration through the cycle again if it makes any difference, and other heuristics that one can imagine.] 7.5 In a world where (7.3) is assumed, I am not sure what the "always recalculate" flag accomplishes except for one case. When a formula whose volatility is entirely internal to the formula (ie., "=NOW()" there is no "recalculate event" on some other cell or formula that would naturally trigger determination of the value of this formula except whenever there is not a retained value for it. That is, we can only count on this being determined the first time it is needed to determine a value that is persisted for a cell. We also know that we don't intend for this formula to be continuously evaluated in real time. So at what other times will this formula have its then-current value determined or delivered or whatever? In a world where (2.1) is the assumption, I think "==NOW()" is how that assumption is over-ridden. Note that this is honored in a recalculation we are already doing that would normally use a referenced cells established value and not recalculate that cells formula, but for the presence of the forced-recalculate flag. 7.6 I can see this also being meaningful in a world where (7.4) holds, since one would not want to automatically and repetitively recalculate an internally-volatile formula on which some other formula depends indirectly. There might be a default assumption that you only redo internally-volatile formulas because you are forced to. -----Original Message----- From: Patrick Durusau [mailto:patrick@durusau.net] Sent: Sunday, January 24, 2010 07:24 To: office-formula@lists.oasis-open.org Subject: [office-formula] Forced Recalculation? Greetings! Is it fair to say that all of current section 2.5 is non-normative? It doesn't appear to specify any required behavior and consists entirely of observations about behavior of current evaluators of OpenFormula expressions. Yes? But that leads me to: 4.2 Basic Expressions where we say: > If a formula is marked as a "forced recalculation" formula, then it > *should* be recalculated whenever one of its predecessors it depends > on changes. > Doesn't seem much like a "forced recalculation" if it is only a *should* does it? Not to mention that the apparently non-normative language in 2.5 contradicts itself: "Functions that are /always/ recalculated whenever a recalculation occurs are termed /volatile/ functions. Functions that are often volatile functions...." Well, but either a function is "always" recalculated or it is "often volatile...." but surely it can't be both. It may take some doing but my suggestion is that we determine which functions *shall* to use the standards terminology recalculate when changed. Moreover, we need to decide if formulas, when marked as "forced recalculation" are a "should" or "shall" recalculate. Separate case from functions. Hope everyone is having a great weekend! 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) --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]