@amirebrahimi I think it's the same issue as discussed at https://quantumcomputing.stackexchange.com/questions/12466/qsharp-reload-throws-error-in-python and in comments at https://codeforces.com/blog/entry/77614
This fixed it for me. Thank you @tcNickolas_twitter!
Re: D1 - I'm trying to modify the ClassifierStructure() to simply add an additional controlled rotation:
ControlledRotation((1, new Int), PauliY, 1)
but get the following error:
Unhandled exception. System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
---> Microsoft.Quantum.MachineLearning.EstimateGradient on D:\a\1\s\submodules\QuantumLibraries\MachineLearning\src\GradientEstimation.qs:line 78
at Microsoft.Quantum.MachineLearning._RunSingleTrainingStep on D:\a\1\s\submodules\QuantumLibraries\MachineLearning\src\Training.qs:line 148
at Microsoft.Quantum.MachineLearning._RunSingleTrainingEpoch on D:\a\1\s\submodules\QuantumLibraries\MachineLearning\src\Training.qs:line 229
at Microsoft.Quantum.MachineLearning._TrainSequentialClassifierAtModel on D:\a\1\s\submodules\QuantumLibraries\MachineLearning\src\Training.qs:line 388
at Microsoft.Quantum.MachineLearning.TrainSequentialClassifierAtModel on D:\a\1\s\submodules\QuantumLibraries\MachineLearning\src\Training.qs:line 322
at Microsoft.Quantum.MachineLearning.TrainSequentialClassifier on D:\a\1\s\submodules\QuantumLibraries\MachineLearning\src\Training.qs:line 98
at Microsoft.Quantum.Kata.QuantumClassification.TrainLinearlySeparableModel on C:\Users\AmirEbrahimi\dev\qc\CodeForces2020\Warmup\notebook\Backend.qs:line 0
I've dug through the source on GitHub a bit and it seems it is failing at estimating the number of qubits needed. Any ideas of how to resolve this? I would think simply by adding that ControlledRotation with another qubit referenced that it would expand the number of qubits.
So, this isn't immediately apparent, but you need to use the unwrap '!' operator to get at the qubits:
e.g. - register!
As far as the rest, you need to consider how adders work and the equivalent on a quantum computer (that is also reversible).
@githg22_gitlab In this particular case your data is encoded in just 1 qubit, so you have a choice of Rx, Ry and Rz gates :-) In general that's the same kind of challenge that classical machine learning faces - you need to figure out the feature engineering and the model structure before you can train it
But I'm getting a very high value of Miss rate (0.4)
@githg22_gitlab: There's indeed not a formatter for Q# yet, but that could be a great feature request at https://github.com/microsoft/qsharp-compiler/, or if you'd like to contribute one yourself, you may be interested in checking out some other compiler extensions such as the one @crazy4pi314 and @bettinaheim were working on in their stream yesterday at https://www.twitch.tv/videos/649894848 and in @crazy4pi314's fork at https://github.com/crazy4pi314/qsharp-compiler.
I'll check them out thanks
@amirebrahimi: This is actually a broader community for Q# developers and users, but it's really cool to see everyone from the contest! If you're interested in the Q# community, I'd encourage checking out what the Q# community has done at https://qsharp.community. There's some neat blog posts, GitHub projects, and so forth hosted there.
Thanks, @cgranade - I remember hearing about this community a while back I think from an interview you had either on QCN or meQuanics. Good to finally jump into Q# and give it a try. It's an interesting model and very different from the rest. In some ways I feel more restricted though.
Well, that was a lot of fun :) I see you came out right above me @githg22_gitlab. It's quite hilarious to me how much of the time I spent was just about getting the dev environment set up, learning how the Q# QML approach is architected, and figuring out how to reduce the training time iterations.
Haha. I agree with a lot of time spent over setting up the environment.
Welcome everyone, its really exciting to see so many new faces here! Hopefully the warm-ups have been going well 😄
@githg22_gitlab I have been wanting to work on a Q# linter/code formatter for a while, that would be a great project if you wanted to collaborate with the community here! (also my code would look so much nicer :P )
@cgranade - It's nuanced for me and perhaps just temporary by the current level of documentation or feature set: not being able to construct a gate from a unitary directly, not being able to easily construct a kronecker product of pauli matrices without having to create a new operation, not being able to print the circuit easily (or having the concept of a circuit), etc. I think having used Cirq a little bit and mostly having used Qiskit it's me adjusting to the difference.
Now on the + side: I love being able to use Visual Studio (keybindings for commenting selected blocks would go a long way though!). I love having the easy connection to work with C#. I love the representation of data structures in QDK.
XYXZto a register of 4 qubits you can use the
ApplyPaulioperation. One of the design goals of Q# is to get the user to be thinking about the algorithms at a higher level and not needing to construct matrices.
Thanks for the feedback, I really appreciate it, @amirebrahimi! I think if I could offer some clarification as to some of what you raised, Q# really is at some level about sending instructions to a quantum device, rather than about constructing matrices for those instructions. One of the architects on the Quantum Development Kit team, Alan Geller, summarized it a couple years ago as that Q# exists "because we want to build algorithms, not circuits." From that perspective, matrix decompositions are the things we keep in our heads, or internal to the simulator as we write Q# code.
It's entirely possible to mesh that with thinking of state vectors and unitary matrices as special kinds of programs, however. The
PrepareArbitraryState operation takes an array of complex numbers describing a state vector, and uses them to prepare that state by decomposing that input into the right sequence of instructions needed to do so. The same approach would work well for inputs that represent unitary matrices, of course; if you're interested, that could be a great feature request or even contribution.
To the bit about not really using circuit representations, that goes to the design goal again where the user shouldn't need to think about specific gate sequences (people building the language and runtime are) to be able to code their quantum program. As a former QC researcher myself who really liked the circuit representations (I was an experimentalist :P ), I have really grown to like not having to use them, and thinking more like I would for writing in any other programming language when I write quantum code (maps/apply/list comprehensions/types etc.).