RE: [office-formula] Forced Recalculation?

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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