>> So welcome back everybody,
is my great pleasure
today to be talking
about Q Sharp or
software effort in general.
This announcement that
we had a while back,
and that last week officially
we went open source.
So all of our software in
the QDK is now available
online on GitHub in its entirety.
We've heard plenty before
about applications and what
you could potentially want to
do with quantum computing.
So by now we hopefully
have some ideas and
some inspiration on the problems we
might want to tackle at this point.
But the question is
how do we get there?
These are all
huge challenging problems.
We all like to save the world,
but in the end usually that turns
out not to be quite as easy.
The way we think about
quantum algorithms and we
teach about quantum and
quantum algorithms today is
very important for how people
will think about them in
10 years or 20 years,
and what we build
this future on essentially.
Sometimes there were very nice
examples like grower forward,
for example, that is somewhat
visual in this 2D plane.
You can draw some diagrams,
have some graphics.
But then when it comes down to
actually explaining what it is that
the algorithm actually is
supposed to do and how it works,
that usually looks something like
that in detail in a classroom at
a whiteboard with some formulas and
the more detail that is
on the slide obviously.
But if you're looking back at
this nice virtual representation
of this algorithm.
If you're forget for a moment
all the nitty-gritty details,
we might want to take a step
back and fundamentally
think about what it
is we want to do and we want to
achieve to come up with new ideas,
with new ways of looking at
a problem and approaching a problem
before we go into
the technical detail
exactly on which sign goes where.
So if you would explain
exactly what people
are supposed to do based on
this sphere on this diagram,
what you will probably come up
is something like saying, "Well,
you got to get yourself
a uniform superposition to make
sure your state has
some overlap with where
you actually want to go."
Then we can do two kinds of
reflections for a suitable number
of time that will
effectively rotate or state in space
such that we rotate towards
where we want to go.
After you've done that a
sufficient number of time,
you can measure and get
hopefully a state that is collapsed
to what you wanted to know.
I've written down for example here
in Q Sharp how this might look like.
The nice thing is really that we
still have pretty much these lines.
Yes, it's maybe not entire sentences,
but still fundamentally
we can express,
there's supposed to be
a uniform superposition.
You're supposed to somehow
mark where you want to go,
your target state, your flag,
your target state, and
usually that's the difficulty
with this amplitude
amplification things.
You somehow need to mark it and
that needs to be efficient.
Then you can just reflect
against the plane,
do that a couple of
times and you're done.
So looking back at fundamentals,
for example teleportation,
what we often
see are diagrams like this one here.
So okay, this is nice.
This is visual. It's
a pretty picture.
It's nice to have in a paper because
sometimes if you do a lot of theory,
it's hard to sell your papers
without some pictures.
So in that sense,
sometimes we want to have them,
but scaling up can be
a little bit tricky.
So if you have too much
to draw basically,
if you have a lot of nesting,
a lot of branching that here is in
this classically controlled
gates actually,
then it might come in
a little more handy to
actually have a code or
pseudo-code representation of it.
Because at the very least,
we've got if statements that somehow
make it a little bit cleaner,
and especially if you have more than
just one x or one sec gate in there.
But what's more than that,
it's not just about that.
If you look at these agent,
the CNOT, what is it we want to do?
It's not telling me a whole lot
of what the intent is there.
So instead of calling it H and CNOT,
which means a lot to everybody who
has already worked in the field,
but not necessarily to
the people getting into it.
We could instead write, "Well,
we want to entangle two cubits."
Then we want to transfer and
manipulate entanglement to
do something useful with it.
So hopefully, we hope to abstract out
somewhat that line of
thinking that thought to
make it approachable and workable
for people who have
context in chemistry,
have context in biology,
or anything else,
material sciences where these
things may come in handy,
but not necessarily the entire
foundation of having had a degree
in quantum information theory.
Because when's the last time that
you saw something like that?
I hope some of you code.
I hope none of you had to deal
with that or maybe you did,
and then you work on hardware.
But basically, I'd
rather write a plus
a plus b because it's
just so much faster.
So this is basically that we
want to achieve with the software
that we're building.
Stepping back one step,
we've got to ask yourself
what is it we want to achieve
fundamentally when designing
a quantum programming language,
when designing a software platform,
what expectations do we have?
On one hand as I mentioned in
a sense that's abstraction.
That's talking about what we
want to do rather than how
strong the pulse sequence has to be
to achieve that for
a particular platform,
for a particular hardware.
So in a sense, we want
to be able to talk
about what we care
about and what we're
working on rather having to
have expertise in anything from
superconducting materials up to
number theory and complexity theory.
On the other hand,
there was going to be
the people who download
the algorithms and most
likely hopefully they're
going to know a whole lot more
about this algorithms than
most other people who
would use them as part
of building on it and
developing new ways of utilizing
that specific subroutines.
So we want encapsulation.
What's important usually when you
have abstraction and encapsulation,
you end up paying
some overhead prize usually,
because you've got
all your nice transformations.
Then once you start
plugging them together,
you could probably
eliminate some of it.
Now you've got the choice.
You can write an application
start to finish.
Given all the input values for
every problem you want to solve,
for every application you actually
want to run on quantum hardware.
That's doable if you have
one or two applications.
Given where we are,
that's currently certainly doable.
If you ever actually
had a paper where you
wanted to get are numerical data
or something like that,
you probably ran into the problem
where you wrote a lot
of scripts that do exactly that,
that somehow test a bunch
of input parameters,
test a bunch of ways of plugging
stuff together and so on.
So there are two ways we could go.
One is the responsibilities up to
the developer to actually
make this connection,
makes sure that there's
no performance overhead to be
paid from abstracting things out,
which requires a lot of
work or we can provide in
the language the means to
annotate the information,
to provide the information that is
necessary to automate
the process as much as possible.
We chose to do the Lateran.
Q sharp is a very young,
a very new language.
We certainly there's
the first step then,
and there's certainly
a very long way to go,
but this is where we want to go.
Especially given
the early stage of the field,
given how hardware works,
given that devices are probably
going to be more or less reliable
for the next couple of years,
we do want to note that
our code is correct,
we've heard before that it's
a large problem to
debug Quantum hardware.
You don't just have to
debug Quantum hardware,
it is the hardware that's unreliable,
there's algorithms that are
usually probabilistic
rather deterministic.
So there is a margin of
error there as well.
We can estimate give guarantees with
bounds using triangle inequality
usually is the easiest way to go.
The problem is these are
usually not very tight,
so to make it actually usable,
to actually speed up a lot,
probably we might want to just
try out and heuristically
figure out what is
the right step size for example,
if you have a [inaudible]
or something like that.
But that requires some confidence
in that what you're doing is
actually what you want to
do in the correctness
of your implementation.
So in a sense,
our first priority is
optimization of course,
making it efficient to
run on Quantum hardware,
but once that's satisfied
as much as we can track
about whether you intended to
do what's going to be executed,
that's also something we want to do.
Furthermore, we want to have
some idea about resources,
about how many cubits do you need,
about how long is it
going to take probably
once you have access
to Quantum hardware,
you're not just going to hit
Enter and hope for
the best and see if
it runs within the time
that your cubits are alive,
but at least it should have
some idea on whether that's doable.
Again, versatility is very
important such that we
can figure out incrementally
improve algorithms,
improve hardware, improve
the ways we formulate
an entire program and how we handle
optimization of that program.
Lastly, execution.
As I mentioned, efficiency.
We want to leverage
the hardware that we
have given that we're very
much fighting for every cubit,
fighting for everything we can do,
we want to optimize what we have,
and reliability especially
in terms of code.
So this all brings me to a couple of
questions that I think about a lot,
and for me it's all about
information, essentially.
When you write the program,
what you have is somebody with
an idea how to solve
a problem in their head,
what you want to get is
to somehow translate
that knowledge into something
that hardware understands
specifically.
To do so what we need to have is
a way to convey that information.
That information can be
conveyed in various ways,
and usually is used and broken down,
and once you've inland something,
you lost the information about where
the original operation
started and ended.
There's usually a trade
off once you've used it,
it's probably no longer there.
You can use it for one
thing or for the other.
So it's very important to
think about these things,
and these things specifically
maybe very different
than in conventional compiler
construction for example.
Because there are decades
of research going into what
we currently do to run
a program on your laptop.
Whether that's exactly the right way
to go about doing it
on Quantum hardware,
that's entirely an open question.
The reality is until we actually
run a couple of things,
until we have benchmarks
and test suits and
some research that goes
into that, we won't know.
So we were early here,
we make a first attempt,
our goal is to make
a good first attempt
with Q# to do exactly that.
It's certainly something
that hopefully will grow,
but also will evolve and morph,
because some of the things we think
today are important may not be
very important in the long run
and the other things
hopefully pop up.
Fundamentally, what we
want to do is we want to
reason about the long-run and
that's really what it's all about.
So I'm not going to go into
more details about what
exactly is in the language.
If there are any questions,
I'm happy to answer them,
I'm happy to go into more
specific on language features
on capabilities and trade-offs
that we've done so far,
and where we might want to do.
But I think the important ideas
what I said before.
To give the pretty picture
in a sense we want to
somehow combine
some processing usually,
some classical processing,
heavy classical computation
is something that
generates heat which is one
of the main bottlenecks
currently for data centers
and anything like that.
So realistically,
there's always going to
be a classical part to it for
heavy processing that's
not going to run on
your 4K or even lower
where your cubits left.
So there needs to be
some coordination between
the two probably
compiling it with things.
With Q# you're now competing against
high-performance classical
libraries for
machine learning, for example.
We provide arbitrarily classical
control flow because it's very
important to reason about
the program structure essentially,
but we're not going to compete
with NumPy or anything like that.
That's in a sense
not derived expectation because it
wouldn't run at the same level.
Then we of course also one
to actually execute it,
and as mentioned, something needs to
coordinate between what
is processed where.
So that's pretty much what
makes our software stack.
For today to figure out if that
even is remotely reasonable,
we want some tools to actually assess
whether we're getting somewhere
where we'll run to get,
and we've got plenty of them.
Q# is one, of course.
We also got an arsenal
of Dev tools that are
there to make it easier for people
to get into it, to learn it,
to work with it, we've got
simulation framework set up
because most people
probably don't have
a Quantum computer in
their basement or access to one.
So for our daily work and basis,
it's probably helpful to have
some simulation capabilities.
For us specifically, that means
not just the full Quantum
states simulation,
but also resource counts and
anything you could do possibly
to get a good and understanding as
you can about your algorithm before
you actually go and try to do
something on real hardware
and libraries naturally.
So as far as the Dev tool goes,
we do provide a couple of things,
a couple of integration,
we're going to hear more about
that also after that talk,
there's two extensions
that we provide,
but that's mainly what we provide.
You have a language Server,
anything that supports
language server protocol can
use that server to communicate
with the Q# compiler.
So if your favorite editor is Emacs
or Sublime or anything like that,
we are now open source,
feel free to contribute.
For the simulation as mentioned,
we got a couple of simulators there.
We're working, we're certainly
always listening to the ask,
what the committee wants and needs,
and will be helpful to have,
and we've got libraries
like chemistry,
arithmetic libraries,
and an awesome set
of course material and exercises,
and the Katas that Maria is going to
talk more about a little bit later,
that she's all written.
This is one of our newest edition
is Jupiter Notebooks.
A few extensions are easily
obtained by just downloading
your favorite editor, VS Code.
In this example, go to
extensions and download them.
How Q# looks like is that it
works more or less in
a sub-processor model where you
have Q# code that is
eventually supposed to
be executed more or less on
a Quantum processor or router,
the actual Q# run time and
a driver that actually
calls into that code.
The driver right here is C#,
but it could be
anything in principle.
We're on.NET Core.
So you just need to somehow be
able to call into.NET Core.
What the nice thing about
that setup is for example,
for the trace simulator,
you can actually configure a little
bit what it's supposed
to be watching.
Also some durations arbitrarily
set for particular intrinsic
operations or gates.
That gives you a better idea
on how your old
[inaudible] might perform,
how certain adaptions
might impact that.
To be somewhat helpful,
what you can get also
on one hand here
is exactly number of
gates as you see there,
but also we allow you if you
run on a full state simulator
to actually dump the state
to look at the amplitudes.
I know it's helpful for
debugging though we're
really on from a Q# perspective,
we're focused on the operations,
on the transformations
you want to do.
Because what a Quantum state is in
a sense is not relevant
to what you want to do.
So our focus there really
is a transformation
itself and how they relate to
each other more importantly.
With that, we can do
some pretty powerful and cool things
as we've seen one
or two slides before and
some as we've heard about
the chemistry example here.
We've of course all the
usual tools for plotting.
The whole thing comes
with nice documentation.
Hopefully, we're always
working on improving that.
What we have in our documentation
is on one hand getting started,
quickly setting up your environment,
some documentations on
what the libraries are,
on what the language are,
a detailed API documentation for
everything in our libraries
that is generated,
and that should cover
the most basic things.
What is also helpful
sometimes to watch for
is we have at that block
coding contests and new
language features or
[inaudible] or something
like that for those more invested in
actual development and possibly also
these tools that might
be a good place to look.
There's a complete
set of link that is
probably good to take a snapshot of.
As I've mentioned,
the open source repost list there has
gotten a little bit longer lately,
and I'm happy to show that right.
Okay. So here's
one over repositories that just went
online last week which
is the compiler,
the core piece to actually
run quantum algorithms,
do development, and so on.
You don't need to look
at the source code
of the compiler and
the extensions and so on.
This is really if
you're curious about
what we do and at some point,
it's also going to
get a little bit more
clear looking through the repository
where we are headed and
where we want to go.
If you find issues and
things that you think
should work and don't,
here's a good place to file them.
We've got a run time repository
that contains in
particular also all
of our simulators,
it contains also a piece that
generates C# because you need
to execute on something.
So Q# itself right now is
taking text and building
an abstract notion of that text.
We're on the process of writing
the actual compilation piece,
breaking it down, that hopefully
should happen over
the next year or so.
But for the purpose of executing
it anywhere right now,
we're pretty much
generating C# based on
these high level data structures and
leveraging the capabilities
of the C# compiler,
which are lot more relevant and more
practical for actually
running on classical hardware
on similar features than anything
that we might want to do
for Quantum S. There's
also a third new repository which is
the IQ# repository which
is the piece that makes
that Jupyter integration
possible and also having
Python as a driver for
example, easy to have.
So let me show you a little bit
how it looks like if you're
actually working with an ID.
This right now is in Visual Studio,
but that's purely because
I happen to like it.
You can use VS Code or
anything like that.
The nice thing with Visual Studio is
you've got the unit testing framework
and you've got the help that
the editor can provide
via our extensions.
This is one of our Katas
for example and to show you
a little bit just how working in
IT might look like, on one hand.
It's helpful that you see everything
that is declared in this file,
you can jump to it,
go to it right here.
As mentioned, the idea
is that there are set of tasks
you're supposed to solve.
So when you initially
run all the tests,
you are supposed to
fail and your job is
to make them pass, make them green.
There's a nice set of instructions
that come with it that
explained what it
is you're supposed to do and why
we want to do what we want to do.
For example, here create
an entangled pair.
It tells us to actually that we get
two qubits in a serious
state and we're supposed to
create a Bell state,
a particular one.
We can do that right now.
As you see, as I'm typing,
I do get live feedback whether what
I'm typing actually makes sense.
Also, in particular,
for example here,
it will actually show
me the next parameter,
it will show the description of what
that next parameter
actually is supposed to be.
That's all built based on
documentation comments in
the code and our libraries are
fairly well-documented, such that,
if you're hovering on things
like on CNOT for example here,
you do get a description of what
the gate is actually doing.
So we can have Q2 here.
Run the test again and we
should see that indeed,
that particular test
hopefully should now pass.
I've already filled in a third one,
so having solved that one,
actually makes the
other one pass as well.
We've got all the features
for example, or you can see,
well pick where declaration is,
we see here, there's, for example,
a type declaration here.
It's got two items named Bit1 and
Bit2 to represent the message
you want to transmit.
This here's the super
dense coding Kata.
So the goal is to transmit
to classical bits
physically by using the resource
of entanglement and
physically sending one qubit.
So there are a couple of nice
features that the compiler provides.
For example, if you're
getting an open direct,
if you see here now,
finding this thing is pretty easy.
It's a chest to exactly
where to look for it,
you can click on it,
it's actually going to
insert this open directive again,
as you know from other languages
just like C# and F# where
similar functionalities are
also available obviously.
They're always working
on improving that.
We've got renamed for example,
that makes it fairly easy
and convenient to work with.
It's just writing two lines of
code, fairly straightforward.
Writing a couple of 100 lines
of code which hopefully,
people working on quantum all
over again will at some point,
is easier to have some support here.
We have this whole thing
also in Jupyter Notebook
Format and Maria,
the next speaker is going
to talk about it some more.
I'm just going to show
you a little bit.
You can actually clone for
example, a Kata's repository,
you get an index and a list of
all things here that are available.
As I mentioned, you're going to see
more about that a bit later on.
Because I mentioned, things
are also available in VS code.
Here we see the example to actually
just create a Bell state and
then see what the state is,
we can run it with.Net.
All right. Just.Net run,
we will do what you want
to do and what we get here
is an output that is
now a little bit less
readable with what the amplitudes
are for particular qubits,
for state 1, state 2,
state 3, states 0.
In case you were wondering
a little bit how
this whole thing works,
for example, with
Tracer where we have
branching based on
measurement results,
the way it's currently implemented
is that when you write,
for example teleportation and
you have a branching here.
What the tracer does
is actually follow
one particular execution path
and the path it
follows is going to be
probabilistic depending on what
probabilities have been annotated
for a particular branch.
So what we did here for
example is to say, okay,
here are an assertion
regarding what the state
of the qubit should be,
we can have similar assertions before
branchings that basically
say, the probability,
I know based on my knowledge
of the algorithm is
supposed to be that,
and it will just
probabilistically follow
whichever path according
to that probability.
If you don't set anything,
I believe it's
a 50-50 chance and there're
ways obviously to force
each path in branching.
Again, there everything
is open sourced,
there are certainly nice things one
could do with them,
and build on that,
and have a more clever way to get it
an entire understanding of
the tree for your program.
We're always working on
improving our tools.
So before I go into
full demonstration here,
I think it's easier
if I just opened up
the round for questions for
anything you want to see,
any other software aspects
you would like to look at.
I think that probably
makes more sense.
No questions? So then
I hope for plenty of contributions
and people using it,
or at the very least, bug reports.
That's always a good sign that people
are actually using the software.
Perfect. Then I think
we're all excited to
hear more about course material
and how to actually use these tools.
