Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Circuit cost module and methods #165

Merged
merged 3 commits into from
Oct 4, 2023
Merged

feat: Circuit cost module and methods #165

merged 3 commits into from
Oct 4, 2023

Conversation

aborgna-q
Copy link
Collaborator

Extracts the circuit cost definitions from rewrite::strategy into circuit::cost, and adds methods Circuit::nodes_cost and Circuit::circuit_cost.

With this we can use the cost logic for CircuitChunks::split_with_cost.

Drive-by: There are some CircuitChunks QoL updates extracted from #149 that I didn't separate from this PR.

@aborgna-q aborgna-q requested a review from lmondada October 3, 2023 16:13
Copy link
Contributor

@lmondada lmondada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the refactor!


/// The cost for a group of operations in a circuit, each with cost `OpCost`.
pub trait CircuitCost: Add<Output = Self> + Sum<Self> + Debug + Default + Clone + Ord {
/// Returns true if the cost is above the threshold.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// Returns true if the cost is above the threshold.
/// Returns true if the cost is above the threshold.
///
/// It must hold that if `a.check_threshold(b)` then `a > b` but the reverse is not necessarily true.

Is there a better name for this? I find gt_plus_epsilon an ugly but somewhat more descriptive name of what we want...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with a sub_cost(self, rhs: Self) -> isize method, since it doesn't make sense for distance to return a negative number.

@@ -44,6 +45,9 @@ pub trait RewriteStrategy {

/// The cost of a circuit.
fn circuit_cost(&self, circ: &Hugr) -> Self::Cost;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fn circuit_cost(&self, circ: &Hugr) -> Self::Cost;
fn circuit_cost(&self, circ: &Hugr) -> Self::Cost {
circ.circuit_cost(|op| self.op_cost(op)
}

Does this not work?

Comment on lines 97 to 99
fn circuit_cost(&self, circ: &Hugr) -> Self::Cost {
circ.num_gates()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you can add the default implementation above, you should be able to remove this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case in particular the overload is better, since it doesn't require a node traversal.

/// Whether the rewrite is allowed or not, based on the cost of the pattern and target.
fn threshold(&self, pattern_cost: &Self::SumOpCost, target_cost: &Self::SumOpCost) -> bool;
/// Returns true if the rewrite is allowed, based on the cost of the pattern and target.
fn under_threshold(&self, pattern_cost: &Self::OpCost, target_cost: &Self::OpCost) -> bool;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here again you should be able to give a default implementation, given that you have the bound OpCost: CircuitCost

@@ -150,7 +153,11 @@ where
}

fn circuit_cost(&self, circ: &Hugr) -> Self::Cost {
cost(circ.nodes(), circ, |op| self.op_cost(op))
circ.nodes_cost(circ.nodes(), |op| self.op_cost(op))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this different from circ.circuit_cost()?


fn threshold(&self, &pattern_cost: &Self::SumOpCost, &target_cost: &Self::SumOpCost) -> bool {
fn under_threshold(&self, &pattern_cost: &Self::OpCost, &target_cost: &Self::OpCost) -> bool {
(target_cost as f64) < self.gamma * (pattern_cost as f64)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess here a default impl would give the wrong thing, but you could just override it.

@lmondada
Copy link
Contributor

lmondada commented Oct 4, 2023

Sorry to get back to this, but

IDEA: What if in trait CircuitCost we replace the threshold function with a distance function? This threshold idea isn't really a property of the circuit cost, but rather of the rewrite strategy. We could define the threshold based on being "far away enough" in the distance metric.

fn distance(&self, other: &Self) -> isize/f64

@aborgna-q aborgna-q merged commit 61be578 into main Oct 4, 2023
7 checks passed
@aborgna-q aborgna-q deleted the feat/circuit-cost branch October 4, 2023 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants