Add RUS sample (#12394)

[guenp]

Initial new version of RUS sample that breaks up circuit into two parts (red and blue, see image) and only runs second (blue) part if ancilla measurement in the first part (red) returns Zero.
Draft version todo's
[x] docs
[x] unit tests
[o] add hardware-compatible sample -> moving this to follow up deliverable (TBD)

[cgranade]

I think this looks really good so far! I've made some initial suggestions, but I think once those are addressed, and once a README.md is added, this should be in good shape!

[swernli]

This seems like an excellent sample for demonstrating the algorithm on Q#, but I don't think this would work as written when targeting partner execution due to some translation limitations. Is the goal here to produce a sample that works across both simulation and execution or is this more focused on a sample of clean, efficient Q#? I just want to make sure I understand the goal before I get too deep into feedback along the wrong axis :).

[guenp]

This seems like an excellent sample for demonstrating the algorithm on Q#, but I don't think this would work as written when targeting partner execution due to some translation limitations. Is the goal here to produce a sample that works across both simulation and execution or is this more focused on a sample of clean, efficient Q#? I just want to make sure I understand the goal before I get too deep into feedback along the wrong axis :).

@swernli Is there documentation anywhere on these translation limitations? I suggest we could make two versions.

[swernli]

We don't have the documentation yet, though there is work ongoing to capture the supported features as quantum processor capabilities (see microsoft/qsharp-compiler#488), which would allow developers to get compile time feedback on whether their code would work as-written for a particular target. As for two samples vs one, I'll let @cgranade weigh in there. I think the samples included here have thus far been primarily for pure Q#, but I don't know if there is any expectation around shifting that focus to also include hardware compatible samples.

[guenp]

We don't have the documentation yet, though there is work ongoing to capture the supported features as quantum processor capabilities (see microsoft/qsharp-compiler#488), which would allow developers to get compile time feedback on whether their code would work as-written for a particular target. As for two samples vs one, I'll let @cgranade weigh in there. I think the samples included here have thus far been primarily for pure Q#, but I don't know if there is any expectation around shifting that focus to also include hardware compatible samples.

@cgranade I think it would be useful to have hardware-compatible examples in the samples for those running stuff on Azure quantum. My suggestion would be to make two versions and have an input argument --hw-compatible or so. Any thoughts?

[cgranade]

We don't have the documentation yet, though there is work ongoing to capture the supported features as quantum processor capabilities (see microsoft/qsharp-compiler#488), which would allow developers to get compile time feedback on whether their code would work as-written for a particular target. As for two samples vs one, I'll let @cgranade weigh in there. I think the samples included here have thus far been primarily for pure Q#, but I don't know if there is any expectation around shifting that focus to also include hardware compatible samples.

I think a key principle needs to be that adapting samples to be hardware-compatible shouldn't make it harder to understand the samples or what they teach about Q# and the Quantum Development Kit. Thus, I'm all for adapting existing samples to be compatible with current capabilities if we can do so in a fairly nice way, otherwise I would suggest splitting into two samples.

We have some precedent for this, in fact, with the host-language interoperability samples. The Python interoperability feature has some limitations that make it hard to use for all existing samples, such that there's a dedicated samples section under interoperability/python.

@cgranade I think it would be useful to have hardware-compatible examples in the samples for those running stuff on Azure quantum. My suggestion would be to make two versions and have an input argument --hw-compatible or so. Any thoughts?

Agreed with making two versions, as per the above. I don't know that we could make them switch with an input argument, though, given that Q# applications compile as whole programs; @swernli could likely clarify here.

[swernli]

@cgranade That all sounds reasonable to me.

@guenp Given that we plan on having a separate sample for hardware targets, I don't think anything here needs to be adjusted for translation compatibility.

I can tell it's a great sample, because I've already learned a few new tricks from it! Well done!

[msoeken]

Thanks for the sample @guenp. I left a few comments.

[guenp]

@cgranade That all sounds reasonable to me.

@guenp Given that we plan on having a separate sample for hardware targets, I don't think anything here needs to be adjusted for translation compatibility.

I can tell it's a great sample, because I've already learned a few new tricks from it! Well done!

Thanks @swernli! We discussed during scrum and we decided to wait with implementing a hardware-compatible sample in our public repo until we go live with the Azure Quantum public preview. I'll follow up with you on guidance for this when that deliverable gets closer :)

[msoeken]

That looks great! Had just one small comment.

[cgranade]

I think this looks really good, @guenp! Just a few more suggestions that I had to tie things up. Thank you!

[cgranade]

I think this is almost there (sorry for as many rounds...!), just a couple last comments. I've marked as approved, as these are all suggestions. Thank you!