No. Q# contests are quite different from regular Codeforces rounds, and not frequent enough to warrant a rating of their own :-)

lol your(ezdp )profile picture shows your reaction after posting "is it rated?" :P

No. You'll be immortalized in the contest standings, though :-)

Normal CF rounds are pretty much orthogonal to the Q# round, so it doesn't affect them. (In fact, at least one of the previous Q# contests overlapped with a normal round.) Right now the calendar has two upcoming contests in May.

actually you're super saiyan gohan lol!

If you're going to introduce your cat to quantum computing, you might want to avoid the topic of Schrödinger's cat... I believe this is why historically cats don't do so well with quantum physics.

I asked last year a similiar question and got a useful resource: http://lapastillaroja.net/wp-content/uploads/2016/09/Intro_to_QC_Vol_1_Loceff.pdf

TL;DR The programming environment of Q# is nicely simple, but quantum physics is not.

I only found the documentation ? also how to install it on local machines?

Looking at the contest schedule — May 26 :-)

?

Linear algebra is like the most visualizable thing ever.

Awesome quantum computing offers a lot of resources in a variety of formats — a lot of them are written but there are videos and MOOCs there as well.

Here is a great video on "why quantum computing?" by Dave Wecker: https://cloudblogs.microsoft.com/quantum/2018/06/01/achieving-practical-quantum-computing/. And we want to learn Q# to be able to implement the algorithms that allow us to solve unsolvable problems of today.

Both the warmup round and the main contest are not rated. You can win a T-shirt in the warmup round, though, so it's a little more significant than only for practice purposes this time.

You can bypass Visual Studio and just use .Net Core SDK (packages dotnet*) in Linux. Look for commands that use it, like here.

Okay, Downvoted.

Can you please provide the exact steps you're following for a repro? It could be, for example, this issue if you're opening namespace in a separate cell.

In general, Q# accumulated some syntax and libraries changes since the last warmup round (it's been over a year, after all :-)), so some of the code will generate warnings and errors on the latest Q#.

As soon as we have them :-)

Have you checked the solution in ReferenceImplementation.qs? For solving these exercises you go through the list of available gates and their effects (for example, in BasicGates tutorial) and check which ones have effects similar to what you need. In this case, it's just one gate.

For an integer $$$k \in [0, 2^N - 1]$$$, I write $$$|k\rangle$$$ to mean the state vector corresponding to the little-endian encoding of $$$k$$$. The required unitary needs to do the following:

1. For $$$k < 2^{N - 1}$$$, map $$$|k\rangle$$$ to $$$|2^{N - 1} - 1 - k\rangle$$$.
2. For $$$k \geq 2^{N-1}$$$, map $$$|k\rangle$$$ to a superposition of $$$|2^{N-1}\rangle, |2^{N-1} + 1\rangle, \ldots, |2^N - 1\rangle$$$.

The first task can be accomplished by flipping the each qubit in qs[0 .. N-2] if qs[N-1] == 0. This is done via the line

ApplyToEach((ControlledOnInt(0, X))([Tail(qs)], _), Most(qs));

The second task can be accomplished by applying the $$$H$$$-gate to each qubit in qs[0 .. N-2] if qs[N-1] == 1. This is done via the line

ApplyToEach(Controlled H([Tail(qs)], _), Most(qs));

No … Already asked and answered in the 1st comment :v

I think it is yes because last year it was rated.

The resources I link in the post are really good — and you don't need to learn all the capabilities of Q#, just enough to start solving the problems. For example, you can safely skip generics :-)

This particular problem is task 1.11 from Superposition kata, so it's very easy to test :-)

More generally, testing quantum programs can be quite challenging, depending on the type of problem. You can study the testing harnesses in the Quantum Katas to see how they are implemented for a type of problem similar to yours. Superposition tasks, though, are tested by comparing them with the correct solution, so if you don't have a correct solution on hand, you can't take the same approach. In this case I would use DumpMachine to check the amplitudes of the basis states in the state you prepared.

You can follow this tutorial to create a runnable executable with Q# code and then modify Q# code to allocate qubits, call your solution on them and use DumpMachine to inspect the amplitudes.

From the announcement blog:

To solve each task, you will write Q# code to implement the described task. Solutions are accepted in Q# only.

VS IntelliSense can be sensitive to a number of things in your environment, like .NET Core version and VS version; for example, this issue happens when you're running QDK 0.11.2004.2825 with .NET Core 3.1.300. I got my configuration working but I'm using .NET Core 3.1.201.

Custom invocation was implemented for the last contest:

https://codeforces.net/blog/entry/65579

Custom Invocation allows you to run Q# code on Codeforces servers; make sure your code has namespace Solution and an operation with a signature operation RunQsharp () : Bool defined in it.

See if that still works.

You definitely shouldn't have to add @EntryPoint to run in Custom Invocation. However, it looks like it was broken when we updated Codeforces from the previous QDK version to 0.11. Let us look into fixing this...

We've updated custom invocation, so it should work now if you define a wrapper operation RunQsharp:

namespace Solution {
    open Microsoft.Quantum.Intrinsic;
    operation RunQsharp () : Bool {
        // your code here
        let result = 1;
        Message($"Got some {result}");
        return true;
    }
}

Microsoft QDK is a collection of tools, from the Q# programming language and compiler to several simulators. When you run a Q# program locally, it will typically use a full state simulator which imitates the behavior of a perfect (error-free) quantum device up to ~30 qubits. You will also be able to use QDK to run the same Q# programs with a resource estimator or on real hardware, but this is out of scope of this contest :-)

LittleEndian is a wrapper type around the Qubit[] type, so to treat it as a Qubit[] you need to unwrap it: Length(register!) to get the number of qubits or register![i] to get i-th qubit.

I much prefer the old syntax (set arr[idx] = expr;) even if it's semantically an ugly special case.

Have you tried taking the projects from https://github.com/microsoft/MLADS2020-QuantumClassification or from https://github.com/microsoft/Quantum/tree/master/samples/machine-learning/? That's what I did when I started learning our QML library — starting with a project that already does it and modifying it is a lot easier than starting from scratch.

Anyone else manage to pass D1/2 without actually getting machine learning to work? :|

That really depends on the kind of program you need to test. (The main challenge is devising the code, not porting it to Jupyter notebook.)

You can study the testing harnesses in the Quantum Katas to see how they are implemented for a type of problem similar to yours. This will work, for example, for reversible-computing problems (the katas are SolveSATWithGrover, GraphColoring and RippleCarryAdder). For problems A1-A5 the testing harness is the closest to the one used in the Measurements kata.

Superposition tasks, though, are tested by comparing them with the correct solution, so if you don't have a correct solution on hand, you can't take the same approach. In this case I would use DumpMachine to check the amplitudes of the basis states in the state you prepared and compare them with the ones you need.

It's hard to debug without seeing the code (you can ask a question in contest interface so that only the contest managers will see it). Did you do things like the following to import the package?

import qsharp
qsharp.packages.add("Microsoft.Quantum.MachineLearning::0.11.2004.2825")
qsharp.reload()

Yes. The goal of the warmup round is to prepare you to solving the harder problems of the main contest: allow you to set up your environment and make sure it works and figure out how the new types of problems work.

That's where your creativity comes in, I guess.
Well, in these two particular cases, with a single qubit representing an angle, it's obvious only Y rotations make any sense.
For more general cases, I suggest starting by replicating the examples given in the documentation for general-purpose two- and three-qubit circuit configurations.
If that doesn't yield satisfactory results, you should look for some sort of nice structure in the given data, and design the circuit yourself specifically to exploit that.

Which task?

If it's task B1 or B2, pay attention to the note on the bottom of the task statement.

Most likely it is a version mismatch.. Try downgrading your iqsharp to 0.11.2004.2825 Or first, try changing the library version to whichever you are using in the add packages line.

A1 and A2 are different problems, you can think of the letters as groups of problems that are solved in broadly the same way.

It's mentioned that arbitary rotation gates (and that function in particular) cannot be used which is why you are getting RTE. You can implement this operation by using Controlled CNOT gates as mentioned in the question

In these problems you can't do that, but you also don't need this, since the classes are perfectly distinguishable with just the angle. That's why these problems don't offer you this option.

In general you need to preprocess your data and calculate new features for it before you pass it to the library. For example, in the HalfMoons example the data is preprocessed before encoding: WithProductKernel function adds an extra feature that is the product of all original features. After that the standard encoding realizes that there are 3 features in the data and those can't fit in a single-qubit state, and automatically uses an extra qubit to encode the features (the missing features are padded with 0s to the nearest power of 2).

Both time and memory are measured for running the simulation. (So, for example, the more qubits you have allocated, the slower the gates become, though this doesn't have noticeable impact until 20+ qubits — I explored this a bit in this blog post)

I got the error rate down to 6% with some preprocessing. First I centered everything, then I converted it to polar coordinates, and then added some ad-hoc fixes for the argument wrap-around. After preprocessing, the training data looks like this:

which is a lot easier to work with.