Add <lit_type> to std::vector

[Nick-Liou]

No description provided.

[hriener]

Thank you for your contribution.

Please merge the updated "master" branch first to fix the issues with CI actions.

Please add your "win10" target to ".github/workflows/windows.yml". Ideally, use a separate PR to show that the new target is currently broken, and will then be fixed with this PR.

[coveralls]

Pull Request Test Coverage Report for Build 9139282207

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 87.633%

---

Totals
Change from base Build 9138461161:	0.0%
Covered Lines:	992
Relevant Lines:	1132

---

💛 - Coveralls

[Nick-Liou]

You're welcome.

I wanted to clarify a few things. I made changes to compile the project locally on Windows 10.

As a side note, I found your project through your paper on ESOP (titled "Exact Synthesis of ESOP Forms"). Thanks for making it open source; it has been very helpful.

Currently, I am using const auto cubes = esop::esop_from_optimum_pkrm(tt); with a fully defined truth table. However, I noticed that when I use an inverted truth table and manually add the term "⊕(1)", the resulting expression sometimes has fewer terms (e.g., for the input auto const tt = from_hex<3>("fe");).

Is there another function that might provide better results, or perhaps multiple, slightly different results that could optimize the expression further?

[hriener]

The function synthesizes a PKRM (= a special case of an ESOP).

There are plenty of methods for synthesizing ESOPs. It's not so easy to suggest one without knowing the constraints and goal. The SAT-based exact synthesis approach is interesting for fundamental research --- one wants to find a minimum ESOP (in the number of terms) without being concerned of runtime. In practice, where runtime often matters, I would advise using a different, more scalable approach. Also, the number of terms is not always the desired cost function (e.g., ESOPs can be used to optimize quantum circuits --- in this context sometimes simplifying the cubes is "better" than reducing the number of terms).

[Nick-Liou]

Thank you for your response;, you are absolutely right. Currently, I haven't determined a specific cost function. My focus is on optimizing quantum circuits, particularly in basis encoding, as part of my master's thesis.

I must admit, I haven't grasped the concept of cubes yet, as my initial priority was to compile the project and get it working. If you have any recommendations for functions or approaches that might be better suited for my use case, I would greatly appreciate it.

[hriener]

I would suggest the following approach then:

1. Generate a PKRM as a starting point and write it into a PLA file.
2. Run ABC's &exorcism command ([1]) to compress the PKRM into an ESOP.
3. Optional: Implement a post-processing algorithm that deals with quantum cost.

To my understanding until today, excorsim [2] still offers the best trade-off (if you don't really know your cost function and the ESOP has more than just a few terms). If you look for an engineering/research challenge, then try to parallelize the algorithm or incorporate some newer ideas from WalkSAT.

[1] https://github.com/berkeley-abc/abc/blob/3616fd8fb5423003fd75ab2d3a09a18f6b02e374/src/base/exor/exor.c#L927
[2] https://people.eecs.berkeley.edu/~alanmi/publications/2001/rm01_heu.pdf