You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: