macro values can be a cycle behind when clocking #90

New Issue

glen · 2023-04-30T01:48:46Z

glen commented

2023-04-30 01:48:46 +00:00

It seems as though the problem is the evaluate_at does not force the newly clocked values and can be evaluated on the previous cycle's values.

glen commented

2023-04-30 04:07:39 +00:00

Actually that's not the problem. The difficulty is that cross-references, even in the "base" contents of a cell, refer to the previous cycle's values in a clock update. The simplest example is R(up). This is the value of the cell directly above. In the base state, it correctly reflects the updated/current value of the cell above. When "clocking", however, all references, including this one, produce the value on the last cycle. So if the above cell has clocked contents like @+1 that will make it increment by 1, after clocking once the R(up) cell will still show the base contents of the above cell. Only after clocking twice will the R(up) cell show the above cell after being clocked once, and so on for all further iterations, the R(up) cell will always show the contents of the above cell on the previous cycle.

The problem only becomes worse with further links in the reference chain, e.g. an R(up) referring to R(up) referring to a cell with clocked contents will end up perpetually two clock cycles behind.

The solution seems conceptually simple although the implementation is not entirely clear: references inside the clocked cell contents should be to the previous clock cycle whereas inside the base cell contents should be to the current clock cycle.

Actually that's not the problem. The difficulty is that cross-references, even in the "base" contents of a cell, refer to the previous cycle's values in a clock update. The simplest example is `R(up)`. This is the value of the cell directly above. In the base state, it correctly reflects the updated/current value of the cell above. When "clocking", however, all references, including this one, produce the value on the last cycle. So if the above cell has clocked contents like `@+1` that will make it increment by 1, after clocking once the `R(up)` cell will still show the base contents of the above cell. Only after clocking twice will the `R(up)` cell show the above cell after being clocked once, and so on for all further iterations, the `R(up)` cell will always show the contents of the above cell on the previous cycle. The problem only becomes worse with further links in the reference chain, e.g. an `R(up)` referring to `R(up)` referring to a cell with clocked contents will end up perpetually two clock cycles behind. The solution seems conceptually simple although the implementation is not entirely clear: references inside the clocked cell contents should be to the _previous_ clock cycle whereas inside the base cell contents should be to the _current_ clock cycle.

glen referenced a pull request that will close this issue

2023-04-30 16:18:53 +00:00

fix: Always compute cells without clocked expressions using current values #91

glen closed this issue

2023-04-30 16:19:13 +00:00

glen referenced this issue from a commit

2023-04-30 16:19:13 +00:00

fix: Always compute cells without clocked expressions using current values (#91)

Sign in to join this conversation.