-
Notifications
You must be signed in to change notification settings - Fork 370
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
QubitOperator and FermionOperator should inherit from same parent #43
Comments
As a smaller part of this - FermionOperator has the static methods identity and zero, but QubitOperator doesn't have these methods. |
Hey, I was thinking of working on this issue. Reading through the definitions of Also, compress may be able to be done in place to save on unnecessary construction of new terms, although it may not be a bottleneck in any common applications, so I'm not sure if it'd be worth it. Anyway, I'll get started on implementing a |
Awesome! I agree completely with you that compress should also remove the small real components. If you'd like, email me at my github username @google.com and I can send you some very old code that might be helpful. As I said in comment, in the early days of the code (before this GitRepo), we did have things setup this way. So I do have some old code implementing the SymbolicOperator that also has a bunch of tests that come with it. Of course, a number of things have changed since then but it still might be useful. |
@idk3 What do you think about removing those static methods completely? I think our code would look nicer if there's only one way to initialize the zero and identity operator. |
IMO the static methods are the only definitive way to initialize zero and identity, and My basic problem is that @Strilanc might have other reasons beyond these. |
Hmm I see your concerns @idk3 . I guess what I'm proposing is that we agree here that the meaning of |
Hi guys, quick update on where I'm at. I've changed the Up next will be messing with behavior a bit (adding static methods After that will be trying to further reduce code duplication (moving identical code blocks into helper functions in Feel free to check out the changes in my fork. Edit: For now, |
This sounds like great progress. The first thing I will mention though is that you might want to check in the SymbolicOperator class once it is essentially "done". After that, you can check in the change that alters the FermionOperator and QubitOperator classes to inherit from the SymbolicOperator class. I suggest doing things this way to keep the pull requests manageable. This is going to be a big one and I anticipate it being rather confusing if you try to merge everything at once. This also gives us a nice forum to provide feedback in the context of the actual code (easier than flipping back and forth to look at your fork). You asked me an interesting question offline which I would like to repeat and address here since I don't have a great solution but others might have input. You wrote: If I understand the documentation generation correctly, it basically formats nicely the comments from the code itself, reading which class/function the documentation is referring to from the code itself. So in the current release, QubitOperator and FermionOperator have a lot of overlapping documentation. In my fork, many of the overlapping functions are moved into SymbolicOperator, so I think they will be documented under SymbolicOperator and not appear under FermionOperator and QubitOperator. I think this might be difficult to follow, especially if it isn't clear when constructing Qubit or Fermion operators that they both inherit from SymbolicOperator. I'm not exactly sure how the documentation process works, so I'd like to hear your thoughts. The ideal solution would be if we had some way for the documentation to inherit as well! But I don't think that can be done. I suppose my recommendation would just be to make it very clear all over the FermionOperator / QubitOperator documentation that those classes inherit a lot of functionality. One should be able to then click a link in the web docs to see the parent class documentation. |
With the change I proposed in #190 it would be made clear in the automatically generated online documentation that FermionOperator and QubitOperator inherit from SymbolicOperator. |
All right, I've submitted 2 separate PRs, one only containing the SymbolicOperator declaration file and another containing only the changes to QubitOperator and FermionOperator. Of course, the latter will fail tests right now, but I wanted to make the code simple to get to. Once the first one is accepted I can update the second one to include the SymbolicOperator declaration. I did notice a potential issue: in For now, |
@bgimby nice catch in |
@bgimby I noticed your change to |
It passes tests because in your merged PR the behavior was overridden by the definition in
In the version of PR #192 that removed the checking out this commit or checking out the PR #192 branch and manually changing the behavior back should reproduce the bug. |
Ah I see. Hmm we'll need to come up with a better solution than fudging with |
IMO the best solution is to only remove identically zero terms in functions that do not explicitly state that they remove small terms (like The user probably has a better idea than us when it is safe to remove or reduce small terms. So we can either only remove identically zero terms in |
Closed by #192 We should perhaps also write something about this in the arXiv paper... |
In a very early version of this library (known then as OpenPQRS), we had a parent class from which both QubitOperator and FermionOperator inherited. This was an obvious design choice because the classes are extremely similar and differ in only a few places. However, when making FermiLib (the predecessor to OpenFermion) we decided that the QubitOperator class should be embedded in ProjectQ and so we removed this inheritance structure. But in OpenFermion, we have again moved both QubitOperator and FermionOperator into the same library.
There are many advantages to having both of these classes inherit from the same parent. For one thing, we'd need many fewer tests to cover the same functionality. More importantly, there are a variety of methods I would like to add to these classes but it would be annoying to need to add essentially the same function to both. For instance, I would like to add the abs method to both classes which returns the L1 norm of the operators by summing the absolute value of the coefficients. This should be added to the parent class. I think the parent should be called SymbolicOperator.
This is not an easy change it will likely take significant effort. However, fortunately, one will likely only need to change the files which define the QubitOperator and FermionOperator and test them since all other parts of the library will still import QubitOperator and FermionOperator the same.
The text was updated successfully, but these errors were encountered: