[Libreoffice-bugs] [Bug 129199] AutoCalculate silent, deceptive fail. Indicative pattern of one edit step lag in AC update noticed.

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=129199

--- Comment #8 from R. Bingham <rdbingham at verizon.net> ---
A more coherent mental model below. No claim this is the implementation logic.

Excluding behavior interception by macro code, each formula cell having
predecessor dependencies  has a FIFO output queue with the front-most slot the
cell GUI displayed-value slot. In the context of an Auto Calculate sweep
instance, AutoCalc calculates a new cell formula value for cell GUI display if
any predecessors have been modified, even if the modification did not
ultimately change the value of a predecessor, such as manual re-entry of the
same value. AutoCalc then pushes the new display value in the back of the FIFO
queue.

The “standard” AutoCalc behavior is that all such FIFO output queues are
trivially single-slot such that a push of a new value displaces the prior value
from the front-most cell GUI display-value slot. Thus all display-value slots
are logically coherent for a given AutoCalc sweep instance.

As demonstrated in the example .ods, the formula cell N20 behaves as if it has
a TWO-SLOT output FIFO behaving as:

A) (CASE 1) Initialize the example .ods per its embedded instruction. N20
displays 602.21 which is correct for the given predecessor values.

B) (CASE 2) Manually change cell C20 to 70%. Cell N20 display does NOT change
from 602.21 to the expected value of 526.89.

C) Manually enter ANY value, even an error inducing value such as “foo”, in
either of the input cells D19 or C20. Cell N20 now displays 526.89.

The two-slot FIFO queue interpretation is:

Step A using RECALCULATE HARD (or equivalent at file open time) initialized the
N20 output queue to a display-slot value of 602.21 and an empty queue slot
behind the display-slot.

Step B AutoCalc DID calculate a new value and pushed it in to the N20 queue,
but since there was at least one empty slot behind the display-value slot in
the queue, the existing display value was not displaced. Predecessor cell value
displays and N20 display are no longer logically coherent.

Step C AutoCalc DID calculate a new value and pushed it in to the N20 queue,
but unlike Step B, the queue was already full, thus the existing display value
was displaced by the value from the Step B AutoCalc sweep instance sitting in
the queue, not the newly pushed value from the current Step C sweep instance.

Note that what matters for N20 display after Step C is that an AutoCalc sweep
was triggered that visited N20 and pushed it output queue along by one. What
was entered to trigger the sweep is logically irrelevant to the value display
by N20 for a given sweep but you can still have a deceptive coincidence of
predecessor entry value and N20 display that appears logically coherent.

Note that this two-slot queue model appears to work even when AutoCalc posts a
“#VALUE!” cell-in-error condition for N20. The display of “#VALUE!” is delayed
by one AutoCalc sweep.

The apparent ability of RECALCULATE HARD to force logical coherence suggests
that it could be offered as a temporary, user-options checkbox substitute for
the existing AutoCalculate until root cause identification and remediation is
achieved.

Regards.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191209/f2469f10/attachment.html>