Create linear half comparison bloqs #1408
Conversation
|
|
||
| @cached_property | ||
| @abc.abstractmethod | ||
| def _half_greater_than_bloq(self) -> Bloq: |
There was a problem hiding this comment.
why can't this just be an attribute of _HalfComparison[Base]
There was a problem hiding this comment.
it will differ between different falvours ... the ones I'm implementing here have linear depth and linear complexity, this is why their names start with LinearDepth.... There is another variant with log depth but nlog complexity which we might want to add later (we already have one instance of it in LessThanEqual)
There was a problem hiding this comment.
Got it. For these sorts of things (for future reference) I find it useful to follow the "YAGNI" principle. You can design your abstractions to be easily refactorable when (and only when) you want to support a new configuration. Otherwise the levels of indirection can fester. As a concrete example: when I implemented CtrlSpec I developed it as an AbstractCtrlSpec and a concrete CtrlSpec with the idea that you might want different types of control (other than and-ing bits and ints). But since there was only one implementation, I squished the hierarchy.
Anyways: please provide docstrings for these classes that tell the reader how they're supposed to interact.
e.g.: "_HalfLinearDepthGreaterThan: The actual (half-)circuit for doing greater than. This can be returned by the _HalfComparisonBase._half_greater_than_bloq abstract property"
"_HalfComparisonBase: an adapter to support all comparison ops given one comparison (half-)circuit implmentation. Used to support the LinearDepthHalf{GreaterThan, LessThan, GE, LTE} public bloqs"
You should probably include the note that one could also support LogDepth. I don't know where the best place to put that note would be.
| References: | ||
| [Halving the cost of quantum addition](https://arxiv.org/abs/1709.06648). | ||
| """ | ||
| comparison_dtype: str = attrs.field(default='>', init=False) |
There was a problem hiding this comment.
I'm not sure this is how we want to do this sort of inheritance. It's a little confusing. And presumably this attribute will show up in the repr and when you tab complete on available attributes.
There was a problem hiding this comment.
how is this different from the ZeroState bloq? both set the value of a property of a base class and hide it
There was a problem hiding this comment.
well at the time of my comment it wasn't hidden. There's also the secondary level of indirection where the halfcomparisonbase delegates to another class.
|
See |
|
@NoureldinYosri any updates here? |
There was a problem hiding this comment.
@mpharrigan ptal.
as for the ZeroState example. I don't see how it and this implementation differ?
|
|
||
| @cached_property | ||
| @abc.abstractmethod | ||
| def _half_greater_than_bloq(self) -> Bloq: |
There was a problem hiding this comment.
it will differ between different falvours ... the ones I'm implementing here have linear depth and linear complexity, this is why their names start with LinearDepth.... There is another variant with log depth but nlog complexity which we might want to add later (we already have one instance of it in LessThanEqual)
| References: | ||
| [Halving the cost of quantum addition](https://arxiv.org/abs/1709.06648). | ||
| """ | ||
| comparison_dtype: str = attrs.field(default='>', init=False) |
There was a problem hiding this comment.
how is this different from the ZeroState bloq? both set the value of a property of a base class and hide it
|
|
||
| @cached_property | ||
| @abc.abstractmethod | ||
| def _half_greater_than_bloq(self) -> Bloq: |
There was a problem hiding this comment.
Got it. For these sorts of things (for future reference) I find it useful to follow the "YAGNI" principle. You can design your abstractions to be easily refactorable when (and only when) you want to support a new configuration. Otherwise the levels of indirection can fester. As a concrete example: when I implemented CtrlSpec I developed it as an AbstractCtrlSpec and a concrete CtrlSpec with the idea that you might want different types of control (other than and-ing bits and ints). But since there was only one implementation, I squished the hierarchy.
Anyways: please provide docstrings for these classes that tell the reader how they're supposed to interact.
e.g.: "_HalfLinearDepthGreaterThan: The actual (half-)circuit for doing greater than. This can be returned by the _HalfComparisonBase._half_greater_than_bloq abstract property"
"_HalfComparisonBase: an adapter to support all comparison ops given one comparison (half-)circuit implmentation. Used to support the LinearDepthHalf{GreaterThan, LessThan, GE, LTE} public bloqs"
You should probably include the note that one could also support LogDepth. I don't know where the best place to put that note would be.
| References: | ||
| [Halving the cost of quantum addition](https://arxiv.org/abs/1709.06648). | ||
| """ | ||
| comparison_dtype: str = attrs.field(default='>', init=False) |
There was a problem hiding this comment.
well at the time of my comment it wasn't hidden. There's also the secondary level of indirection where the halfcomparisonbase delegates to another class.
NoureldinYosri
force-pushed
the
comparison
branch
from
fac5d53 to
91c535f
Compare
This PR creates all versions of half a comparison operation in$n$ toffoli complexity. The uncomputation of these bloqs has zero cost.
The half comparason operation is needed in the modular inversion bloq.
I also modify the OutOfPlaceAdder to allow it to not compute the extra And when it's not needed
This PR also shows how we can implement all versions of comparison by implementing just one. for example creating a half greater than bloq that use logarithmic depth is enough to implement all the others.