Malfunctions of Construction Protocol & wrong construction order

Will LE shared this problem 10 months ago

New

I'm using Spreadsheet view to implement Euclidean algorithm, but the construction steps of cells in spreadsheet and of other objects depending on those cells are messed up.

In g5nvybju, the number depth = CountIf(x > 0, A1:A10) is place at #8 before all A cells (A2 at #14 to A10 at #73). Initially, I constructed in the following order: a, b, A1 = a, B1 = b, C1 = f(A1, B1), A2 = B1, B2 = C1(1), C2 = f(A2, B2), ... C10 = f(A10, B10), depth = f(A1:A10). It remained in that order well until I add more objects using the number depth, then the construction order was messed up. Even though depth is placed before A1:A10, the final value of depth is still correct, while the other objects depending on depth, like rs = Sequence(Object("A" + (k)), k, 1, depth) (remainders) are incorrect.
==> depth is re-computed many times while its dependents are not updated (enough)
==> I work around with depth's script OnUpdate{ UpdateConstruction() } to make sure its dependents are all updated. You can remove that script to see the malconstruction of rs.
Please note that in Construction Protocol view, I've tried to move the rows of depth, rs and ss down but it just keeps saying "Drop not possible"!?!.
In order to debug g5nvybju, I copy it to duddth2x and delete all objects except the cells in spreadsheet and a, b. Then I re-add depth = CountIf(x > 0, A1:A10) and remainders = Sequence(Object("A" + (k)), k, 1, depth), but then the Construction Protocol view disappeared (no way can I open that view again)!?!
Finally, I've found a way to solve the problem in g5nvybju without workaround, by downloading its GGB file, extracting & manually editing its XML file, then reuploading to bwygxbzp!!! What a hacky way to deal with the problem! :D

Note that as the links above, I've always used the online "classic GeoGebra".

I think somehow the dependency tree of the objects are miscomputed so that the construction steps are messed up and the app keeps refusing to reorder them. I've not set up a dev environment for GeoGebra, so I don't know clearly what's wrong with the dependency tree.

Files: bwygxbzp.ggb g5nvybju.ggb duddth2x.ggb

The same problem

Comments (2)

Michael Borcherds ● 10 months ago

Instead of

Sequence(Object("A" + (k)), k, 1, depth)

try

list = A1:A100
First(list, depth)

Reply URL

Will LE ● 10 months ago

Thank you! I see the point.

So the idiom is "Use static list instead of on-the-fly list [A1:A10] and dynamic Object() query."

But there are many points I don't understand:

The construction steps are topologically sorted based on dependency tree, aren't they? It should be topo-sorted as I understand, but it seems not. It's weird that when I add remList=A1:A100, it's placed before all A cells in the Construction Protocol. I can see clearly that remList is a static list dependent on A cells, and right after I added it, there's no object dependent on it ==> Why it's placed at the very beginning? That high position is against both dependency (leaf node) and the natural construction order (being added last).
Object update (triggered by an object A change) is carried out following the dependency tree traversal without topological sort, isn't it? Eg. in this instance we have the following DAG:
A --> depth
| . . . . . ↓
+----> rs
It seems that the update was carried out in this order: A --> rs, then A --> depth, which misses the dep [depth --> rs].
Even after I add remList=A1:A100 and redefine rs=First(remList, depth) (while depth is still "CountIf(x>0, A1:A10)"), the situation doesn't change:
A -------------> depth
| . . . . . . . . . . . . . . ↓
+-> remList --> rs
And the update was carried out in this order: A --> remList --> rs, then A --> depth, which misses the dep [depth --> rs].
Only after I redefined depth to be "CountIf(x>0, remList)", the object "rs" seemed correctly computed. But the deps are still in a DAG, not a tree:
A --> remList --> rs
. . . . . . . . ↓ . . . . . . . ↑
. . . . . depth -------+
So maybe the correctness is just a luck?! (As long as the update order is not based on topo-sort)

URL