Right now, some ArithmeticCircuit operations have unchecked variants, such as the method add and its counterpart add_unchecked. Unchecked methods simply don't check whether the operands one passes are already in the circuit. For instance, add(a, b) would panic if a and b are not (the indices of nodes) in the circuit.
This is a very cheap check, since it only compares the inputs (which are secretly usizes) to the length of the node vector. However, if one adds many gates (e.g. by calling existing_node.pow(something_big)), it is unnecessary to check that condition for each (multiplication, in this case) gate - hence why the unchecked methods were introduced.
There are two things to polish in relation to this:
Since we ended up deciding that a node can actually depend on nodes that come after it in the node list, the checked methods might no longer make sense. Having said that, this kind of forward-dependency will likely only happen when converting Expressions to ArithmeticCircuits. It is unlikely that a user creating the circuit with circuit methods, such as add, will introduce nodes with forward-dependencies (unless they are coding a circuit whose description they have obtained some other way). One way or another, let's think whether to keep the check and/or differentiation between checked and unchecked methods.
If we do keep them, let's be a bit finer and more consistent in when we use which (in the already-existing functionality).
Right now, some
ArithmeticCircuitoperations have unchecked variants, such as the methodaddand its counterpartadd_unchecked. Unchecked methods simply don't check whether the operands one passes are already in the circuit. For instance,add(a, b)would panic ifaandbare not (the indices of nodes) in the circuit.This is a very cheap check, since it only compares the inputs (which are secretly
usizes) to the length of the node vector. However, if one adds many gates (e.g. by callingexisting_node.pow(something_big)), it is unnecessary to check that condition for each (multiplication, in this case) gate - hence why the unchecked methods were introduced.There are two things to polish in relation to this:
Expressions toArithmeticCircuits. It is unlikely that a user creating the circuit with circuit methods, such asadd, will introduce nodes with forward-dependencies (unless they are coding a circuit whose description they have obtained some other way). One way or another, let's think whether to keep the check and/or differentiation between checked and unchecked methods.