Circular Dependency Issue

Something’s not working the way it seems like it should.

When I try to disable a table cell after a particular value has been entered the script is rejected as having a “circular dependency” but I don’t see a loop in code of form:

“cellEditable(1,1): not(this.cellNumericValue(1,1)=666)”

Update Note: A similar operation setting the suffix is accepted and seems to work okay?
"cellSuffix(1,1): “${this.cellNumericValue(1,1)}”

Here’s an activity illustrating the problem:

CL doesn’t allow loops so you’re seeing the correct error message. In this case you can’t set whether or not a cell is editable based on what’s in that cell.

This forum may have some alternatives to explore if you post your need in the form of an inquiry using the questions category.

Sorry Jay, I really don’t see why setting ‘editable’ is any more a loop that setting the ‘suffix’ of a cell, which is allowed? I’ve updated the example to demonstrate that point.

1 Like

Here’s the loop:

A student needs to edit a cell in order to set its value
That value determines whether or not the cell can be edited.

Changing the suffix of a cell doesn’t affect a student’s ability to interact with that cell.

Sorry Jay, I’m still here trying to explain why I have reported this as a ‘bug’! Essentially my argument is that Desmos seems to be flagging an error unnecessarily. There is certainly an inter-dependency between the value in a cell and an ability to edit it, but I don’t see how that is a problem for Desmos? …as there doesn’t appear to be any ambiguity or indeterminacy to worry about? …as would be the case for something of the form:
table.elementAt(1,1) = table.elementAt(1,1) + 1

An ability to ask students to complete cells of a table, closing off values that are correct, and encouraging another attempt on those that are wrong does seem like a generally useful facility, which this apparently unnecessary check is preventing.


It is most certainly a circular dependency in the sense that the thing you’re trying to update relies on whether or not it can be updated (which relies on the update itself).

What you’re describing is not a shortcoming of the system, but the result of a conscious decision to block all co-dependencies of this type.

Yes, but the value itself is not in a circular dependency and so doesn’t appear to be a threat?

If this block is there to protect Desmos for some implementation reason that is fair enough, but is that the reasoning behind the decision?

Note that a similar dependency exists when using ‘hidden’ which isn’t blocked? So a math input object can include a script of the form: “hidden: this.numericValue=666” which seems equivalent to the cell case (sample activity updated to demonstrate).

1 Like

What you’re describing is starting to sound like a feature request. I recommend emailing support for all such requests.

Though I do agree, hidden based on content is in the same vein and is doing a good job of tricking the system. We’ll look into that one.

1 Like