DEV Community: Sarah Kasier

Profiles for fun and profit: How to use profiles to customize VS Code

Sarah Kasier — Mon, 27 Feb 2023 21:54:10 +0000

tl;dr Check out this gist for some examples of VS Code profiles I use daily 📝🥳

VS Code is my daily driver for basically all of my projects, not just for writing Python code for work.
I use it for writing books, blogs, embedded devices for IoT projects, and presentations with reveal.js.
My settings for each project using VS Code are pretty different, and I used to do a lot of manual setting switching and installing/uninstalling extensions.
For some of the embedded projects, extensions like PlatformIO and the C/C++ extension are great, but they take a lot of time to setup and install dependencies which are not needed for, say writing a blog post.
You could always use workspaces to help manage editor settings and what files open, but you cannot control which extensions are installed for each workspace.
This is where VS Code profiles come in!

What are VS Code profiles?

VS Code profiles are like workspaces, but are less about the contents of the editor and more about what the VS Code window itself looks like.
Profiles were officially launched in VS Code 1.75, and work anywhere you can use VS Code.
A Profile can include extensions, settings, keyboard shortcuts, UI state, tasks, and user snippets.
This means you can have a profile for writing Python code, one for web development, and one for writing blog posts that you can switch between with a few clicks.

Some ideas or use cases for profiles that I have tried or seen:

Language specific development (e.g. Python, C++, etc.)
Web development
Work + personal profiles: you can log into different accounts for each (e.g. GitHub, Azure, etc.)
Text editing
Demos, live streams, or screencasts
Teaching

There are definitely more ways to use profiles, and I would love to hear about them in the comments!

Using profiles

To create a profile, you can either use the command palette (Profiles: Create an empty profile / Profiles: Create from current profile) or click on the settings icon in the bottom left corner of the VS Code window.

Once you have opened the settings, select the Create Profile menu option, which will give you the option of starting with a blank profile or copying the current window's settings to the new profile.

You can delete and rename profiles, import and export profiles, and switch between profiles them all from the gear icon menu.
When you go to export a profile, there is a helpful panel that opens up to show you what will be included in the export.
From that panel it is easy to inspect and edit if needed the settings, UI state, and extensions that will be included in the export.

When you export a profile, you can either save it as a file, or if you save it to a gist, it will give you a URL you can share with others.

NOTE: The share URL will open to a vscode.dev editor window with the profile loaded. A profile management panel open on the left with a prompt for the user to import the profile!

Check out this gist for some samples of profiles I use, which I'll try to update periodically.
The use-case specific profiles are also linked below which will give you a preview and an option to import yourself:

That's it for now, hopefully this helps you tweak your VS Code setup to be even more awesome!
If you have any questions or comments please leave them below or reach out to me on Mastodon 😎

How to get the best Conda environment experience in Codespaces

Sarah Kasier — Mon, 30 Jan 2023 23:02:36 +0000

I often use Conda environments when working on my Python projects, as it helps me manage dependencies for projects outside of just pure Python packages. In porting some of these projects to Codespaces and Dev Containers, I have found some tricks to getting the fastest and most reliable experience with Conda and Codespaces.

tl;dr Check out this template repo for a sample Dev Container that is fast and reduces Codespace resource consumption.

Base image size matters

When you start a Codespace for a project, it will try to use whatever Dev Container you have specified in your repo, else it will try to use a kitchen sink container.
That default kitchen sink can be way too much and so if you will be working with Conda environments with an Anaconda or Miniconda Dev Container template instead.

Tip 1: To use less of your Codespaces resources start with a smaller image like Miniconda or Miniforge and install only what you need.

It is worth noting as well that if you use one of these template docker images or start with the same original docker image on the FROM line, the memory for those layers is pre-cached in Codespaces and seems to download faster.

Create new environments, don't install into base

The default Anaconda/Miniconda templates in VS Code will look for an environment.yml file in your project root and then install those requirements in the base environment.
This can run into issues when there are conflicts between what is already in the base Conda environment and what you are trying to install.

Tip 2: Change your Dockerfile to conda create a new environment as opposed to merging your environment with the base environment to avoid conflicts:

RUN if [ -f "/tmp/conda-tmp/environment.yml" ]; then umask 0002 && /opt/conda/bin/conda env create -f /tmp/conda-tmp/environment.yml; fi \
    && rm -rf /tmp/conda-tmp

Conda process uses lots of memory, gets killed

The other challenge I ran into sometimes was that if I was running a lower memory/storage Codespace instance, when I tried to use Conda from the command line to modify environments, the process would be killed after a few seconds.
This turns out to be related to some performance issues Conda has that make it consume a lot of memory when trying to work with the conda-forge installation channel.
You can always then just increase the size of the Codespace your are working with (just go to your Codespaces list and use the triple dots to change the settings for a Codespace).

There is another option that will fix the performance issues so that it can be run on smaller Codespaces.
Mamba is a faster dependency solver that can wrap Conda and resolve some of these performance issues.
You use all the same Conda syntax for things except use the command mamba and if it's not something Mamba improves on, it just drops back to conda.
To use mamba in your Dev Container to speed up working with environments, you will need to install it into your base Conda profile, and the use mamba to create the Conda environment for your environment.

Tip 3: Install and use mamba to speed up the Conda environment creation process.

The snippet below is a minimal example of a Dockerfile for your dev containers and Codespaces with all the tips included:

FROM mcr.microsoft.com/devcontainers/miniconda:0-3
RUN conda install -n base -c conda-forge mamba
COPY environment.yml* .devcontainer/noop.txt /tmp/conda-tmp/
RUN if [ -f "/tmp/conda-tmp/environment.yml" ]; then umask 0002 && /opt/conda/bin/mamba env create -f /tmp/conda-tmp/environment.yml; fi \
    && rm -rf /tmp/conda-tmp

You can find a template repo where I have added all of these files into a blank repo that might help test some dev containers and Codespaces yourself!

Other Troubleshooting

Conda not working from the start in the terminal

Sometimes after the Codespace or Dev Container has started, the shell will not have been configured to use the conda or mamba commands. If you try to run either conda or mamba the error message will prompt you to run conda init and that should fix it. Make sure after you run the fix that you close that terminal and open a new one for the shell profile to be reloaded.

Conda environments don't show up in the terminal/don't auto activate the right Conda environment

Depending on the loading order of the extensions in VS Code, if it has not seen any Python file or tool in use yet it will not necessarily load the terminal settings for environments right away.
If I open a Jupyter notebook or any Python file that will usually prompt the extension to load the terminal parts and then I just open another terminal window and it's all fixed.

Anyway, hope this helps you get the best Conda experience in Codespaces and Dev Containers! If you have any other questions, tips, or tricks, feel free to reach out to me on Mastodon or in the comments below! 💖

GitHub Universe 2022

Sarah Kasier — Mon, 07 Nov 2022 17:58:49 +0000

I cannot believe it's almost time for GitHub Universe 2022!! It has been super fun working with the GitHub Codespaces team and the QIR Alliance to prepare for the event, and I'm so excited to be able to share what I have been up to.

tl;dr: You can develop for and with quantum computers from your tablet on the beach 😎

Bold claim, I know, but I will show you in my Community Stage session Quantum development with Codespaces on Thursday Nov 10 from 11:30 AM - 12:00 PM. The demo I put together will show you an example of how the QIR alliance is using tools like Codespaces, Python and Jupyter Notebooks to build the infrastructure for quantum computing. The QIR alliance is a Linux Foundation project that helps develop the specifications for the compilers, front-ends, and hardware that make quantum devices work.

I'll be posting during the event on Mastodon, and make sure to check back here for my notes on the event as well as some more fun experiments with Python and Codespaces 🐍💖

Quantum Development Kit 0.12 Release Highlights

Sarah Kasier — Mon, 06 Jul 2020 09:07:29 +0000

I am so excited for this release folks, it has some features I have been wanting for a long while!

The QDK team has published official QDK release notes for version 0.12.20070124, but I wanted to walk through and highlight some of the parts that I am most excited about. So let's get to it!

Using Q# with Python and Jupyter just got soo much better!

There is so much in this release that makes developing Q# in Jupyter Notebooks and Python so much easier.
I have also noticed a ton more documentation on the IQ# magic commands, which was sorely needed.

You can see the new docs in the API Reference on the side of the page.

Let's take a look at the official release notes to see the details of what all was added:

IQ# now allows arguments to the %simulate, %estimate, and other magic commands. See the %simulate magic command reference for more details.

I HAVE BEEN WANTING THIS FOREVER 😻
It will be so much nicer to use Jupyter notebooks with Q# kernels now, you won't have to write stubs that would fill in the arguments you wanted.
Thanks so much to the team for getting this one implemented 💖

New phase display options in IQ#. See the %config magic command reference for more details.

The %config magic command is not new, but there are new docs for %config and some new config options.
These options allow for configuring how the phase is displayed when running callables like DumpMachine and DumpRegister.

Here's an example of some of the new IQ# features including arguments to simulate and showing the default DumpMachine behavior.

Using the %config magic command, we can change the display of the phase column in DumpMachine.

I really like the ability to actually turn them off as they can add a lot of noise when trying to demonstrate something that is independent of phase.

IQ# and the qsharp Python package are now provided via conda packages (qsharp and iqsharp) to simplify local installation of Q# Jupyter and Python functionality to a conda environment. See the Q# Jupyter Notebooks and Q# with Python installation guides for more details.

I pretty much only use the Anaconda distributions of Python, as it's great for working with scientific software.
The addition of the qsharp package to conda will thus make managing environments for quantum development a lot easier.

In this case, conda envs are especially useful, as you can specify things that are not Python packages as part of an environment (like if you needed a particular version of some .NET tooling, or the IQ# kernel that powers Python ↔ Q# interoperability).
Using the new packages, it's really easy to get everything you need for working with IQ# Notebooks, or with using Q# from Python:

conda install -c quantum-engineering qsharp

Updates to make it easier for IQ# users to consume library packages with different QDK versions, requiring only major & minor version numbers match rather than the exact same version

This one is also a general quality of life improvement, and makes maintenance tasks easier.
IQ# uses a specific version of the compiler when building and running your Jupyter notebook code.
In your notebook, you might also want to load additional packages but they each have a version of the compiler that they were built against.
Now, rather than the IQ# compiler version and the package compiler versions needing to match exactly, they only need match major and minor.

Legacy, we got chemistry 😘

New qdk-chem tool for converting legacy electronic structure problem serialization formats (e.g.: FCIDUMP) to Broombridge

Full disclaimer, I am not a chemist.
That said, I am familiar with having to manage data that is in multiple different encodings for a project and that is a nightmare.
This comes up in quantum chemistry applications as there is a step in the development loop where the chemist exports a description of the problem from their simulation software and wants to use that with the QDK. This release adds some new support for converting/using other serializations with the QDK, so that you can use the standard Broombridge format to work with your electronic structure problems.

This new conversion tool help in translating between the top box "Chemistry Modeling" and the blue box "Quantum chemistry format."

If you want to try it out, you can use the same dotnet tool install command that you use to get other .NET Core Global Tools:

dotnet tool install -g Microsoft.Quantum.Chemistry.Tools
qdk-chem --help

New functionality for Oracle synthesis

New functions and operations in the Microsoft.Quantum.Synthesis namespace for coherently applying classical oracles using transformation- and decomposition-based synthesis algorithms.

This is some great new functionality for those that are working on writing oracles for their algorithms.
Oracles are basically a way of representing classical functions in quantum algorithms, if you want to learn more, check out Chapter 7.4 of Learn Quantum Computing with Python and Q#!
The new namespace provides operations that help with taking truth tables or functions and helping you create an oracle that implements the table or function.

Quality of life/Consistency improvements

When using the simulator, qubits no longer need to be in the |0⟩ state upon release, but can be automatically reset if they were measured immediately before releasing.

The error messages for this before were not too bad, and always helped remind me I forgot to explicitly reset a register of qubits, but I greatly appreciate this new feature.
If you have already measured a qubit, then the the quantum device will know what exactly what state it's in, so resetting it is trivial.
Thus, if it is tracking that they were already measured and it's time to release them, it can do whatever operations needed automatically to put them back in the |0⟩ state.

Moved operations:

Microsoft.Quantum.Intrinsic.Assert is now Microsoft.Quantum.Diagnostics.AssertMeasurement

Microsoft.Quantum.Intrinsic.AssertProb is now Microsoft.Quantum.Diagnostics.AssertMeasurementProbability

The new names here make it much more clear what the operations are actually doing.

Removed deprecated Microsoft.Quantum.Primitive.* namespace

I think that finally clearing out that namespace will be good for clarity and also help make the language more inclusive.
It was originally deprecated in version 0.6 and renamed to the more descriptive Microsoft.Quantum.Intrinsic namespace.

Time to go update some code!

Anyway, I hope it was helpful to look at the release in context like this, I hope to be doing it for every release I can in the future!
If you want to learn more about getting started with Q# or maybe diving into quantum applications, check out my book Learn Quantum Computing with Python and Q#.
It's geared as a gentle introduction for developers of all levels to build up an understanding of both quantum computing and Q#.

Leave a comment below about what you are most excited about from this release or Q# in general!
Remember, quantum isn't magic but you are ✨

Building and Packaging a Q# Library

Sarah Kasier — Thu, 18 Jun 2020 06:13:38 +0000

tl;dr If you want to get started developing a new library for Q#, check out this template repo I made to get you going with the right structure, project files, and build automation with GitHub actions.

I have been really excited to start working on a new project with some colleagues building a new library for Q#, and wanted to share with you our journey so far!
The team will probably post more about the content of what the library is doing (implementing memory for a quantum computer), but here I want to focus on the infrastructure that we needed to get from an empty repo to a built and hosted NuGet package for a Q# library via GitHub Packages.

Libraries in general are a great way to extend languages without having to expand the base language thus increasing the maintenance and scope of the language.
Q# has a bunch of official libraries already provided already in the Microsoft/QuantumLibraries repo.
Part of our goal with this project is to show how leverage the existing Q# libraries and runtime and extend them to add new features and content.
This is certainly not a complete guide, and I'll highlight some improvements I plan to make in the future as we go!

Step 0: Setup your repo

This is probably a step that most of you can skip, but I wanted to add a few notes/reminders of things that are good to setup on a new git repo for a project like this.
Don't forget to:

Add a licence file (otherwise people won't be able to use your library!)
- If you want to learn more about your options, check out this licence selection assistant from GitHub.
Add a .gitignore file for Q#, you can just use the same .gitignore we did for our qRAM library.
Add a README.md so that there is a nice description of your project to folks visiting your repo 💖
- There are some good references out there for writing a good README, like this post from Akash Nimare , this one from Divyansh Tripathi, and this one by Danny Guo.
Add a CODE_OF_CONDUCT.md to your repo, check out GitHub's documentation for adding a code of conduct to your repo.

Also for running Q# code you will want to install the QDK, or setup a Docker container to do your work in.

Step 1: Create your Directory Structure

After looking at the microsoft/QuantumLibraries repo for a bit, I worked out how I wanted to structure the code in our repo.
There are three main directories that we needed, one for the source of the library, one for the samples demonstrating the library, and one for tests.
The samples directory will have a bunch of subdirectories (eventually) for each qRAM implementation we want to demo, as well as some samples showing how to do resource estimation for the various implementations.

│   .gitignore
│   LICENSE
│   README.md
│   CODE_OF_CONDUCT.md
│
├───samples
│
├───src
│
└───tests

You can make these folders/directories however you want, you will just need three folders in your base or root project folder called src, tests, and samples.

NOTE: There is nothing magical about these names, it just happens to be what my team and I decided so if you have other naming conventions, go ahead and change them!
Just make sure then as you are reading the rest of this post to make the right replacements for your names in the commands and files I show below 👍

Step 2: Create the Q# projects

Now that you have the folder structure, its time to create the Q# project files that will allow you and the later automation to build your library.
These project files are kinda like Makefiles and use the C# infrastructure (MsBuild) to actually control the Q# compilation.

Library source

Navigate to the src folder and run the following command:

dotnet new classlib -lang Q#

This will create two files in the src/ directory: Library.qs and src.csproj.
You can see the contents below.

`Library.qs`

namespace src {

    open Microsoft.Quantum.Canon;
    open Microsoft.Quantum.Intrinsic;


    operation HelloQ () : Unit {
        Message("Hello quantum world!");
    }
}

NOTE: You can change the namespace name to better reflect what your library is about!
The Q# API design documentation has some good guidance on how to make good namespace names, e.g.: Organization.Product.DomainArea.

`src.csproj`

<Project Sdk="Microsoft.Quantum.Sdk/0.11.2004.2825">

  <PropertyGroup>
    <TargetFramework>netstandard2.1</TargetFramework>
  </PropertyGroup>

</Project>

You can see that the src.csproj file has a reference to the version of the QDK that it was created with as well as what .NET framework it is being built for.

You can test that this template was created correctly by running:

> dotnet build
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 284.96 ms for C:\Users\skais\qsharp-library-template\src\src.csproj.
  Restore completed in 29.64 ms for C:\Users\skais\qsharp-library-template\src\src.csproj.

  ____________________________________________

  Q#: Success! (0 errors, 0 warnings)

  src -> C:\Users\skais\qsharp-library-template\src\bin\Debug\netstandard2.1\src.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:12.79

Generally you will not need to do much with the project files here in Q# other than to make sure to add references to other projects and packages you might take as dependencies for your project.
Speaking of, let's try that now by starting our tests project.

Testing

Navigate to the tests/ folder and run the following command:

dotnet new xunit -lang Q#

This should create two new files in the tests/ directory, Tests.qs and tests.csproj

`Tests.qs`

namespace tests {

    open Microsoft.Quantum.Canon;
    open Microsoft.Quantum.Diagnostics;
    open Microsoft.Quantum.Intrinsic;


    @Test("QuantumSimulator")
    operation AllocateQubit () : Unit {

        using (q = Qubit()) {
            Assert([PauliZ], [q], Zero, "Newly allocated qubit must be in |0> state.");
        }

        Message("Test passed.");
    }
}

`tests.csproj`

<Project Sdk="Microsoft.Quantum.Sdk/0.11.2004.2825">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Quantum.Xunit" Version="0.11.2004.2825" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.4.0" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.1" />
    <DotNetCliToolReference Include="dotnet-xunit" Version="2.3.1" />
  </ItemGroup>

</Project>

Now the project file here is almost good to go, but it needs to know about our library project in the src/ folder.
Let's add that now by running this command in the tests/ directory.

dotnet add reference ..\src\src.csproj

That should add the following <ItemGroup> to your tests.csproj file:

  <ItemGroup>
    <ProjectReference Include="..\src\src.csproj" />
  </ItemGroup>

Now when you go to run the tests you write for your library the compiler knows where to find your actual library code!
You can test that this tests project is setup correctly by running dotnet test.

> dotnet test
Test run for C:\Users\skais\foo\tests\bin\Debug\netcoreapp3.1\tests.dll(.NETCoreApp,Version=v3.1)
Microsoft (R) Test Execution Command Line Tool Version 16.3.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.


Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 1.7436 Seconds

Samples

The last directory we need to setup is samples/.
Navigate back to the project root and into the samples/ folder.
Now, I plan to have multiple samples for my project so I'll make one more folder in samples/ called sample1.
Navigate into the sample1 folder and run the following command:

dotnet new console -lang Q#

This should create two files, Program.qs and sample1.csproj.

`Program.qs`

namespace sample1 {

    open Microsoft.Quantum.Canon;
    open Microsoft.Quantum.Intrinsic;


    @EntryPoint()
    operation HelloQ() : Unit {
        Message("Hello quantum world!");
    }
}

NOTE: You can change the namespace name to better reflect what your sample is about!

`sample1.csproj`

<Project Sdk="Microsoft.Quantum.Sdk/0.11.2004.2825">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

</Project>

Again, you will want to run dotnet add reference to make sure the sample also knows about your library.

dotnet add reference ..\..\src\src.csproj

This will add the same ProjectReference to your sample1.csproj file.

You can check that this sample was created correctly by running the following:

> dotnet run
Hello quantum world!

Step 3: Setup the GitHub Actions to build and publish a package

Now that you have your repo structure setup, it's time to hook up the GitHub automation that will automatically do some maintenance on the repo.

We will setup two automation workflows for this repo, one that will make sure tests pass on code that is committed to master, and the other will build and publish a NuGet package when a new commit is made to master.

Both of these workflows are examples of GitHub Actions, learn more about this feature of GitHub repos here.

Automating test builds

We can use yaml files to configure these workflows, and to make sure that GitHub finds these files let's make the following folders at the root of your project: .github/workflows/

In the workflows folder create a file called test.yml with the following contents.

# This is a workflow that will run `dotnet test` on your tests directory.

name: Run Tests

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch.
on:
  pull_request:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2

    # Runs a set of commands using the runners shell
    - name: .NET tests
      run: dotnet test
      working-directory: tests

This action will fire whenever you make a pull request on the master branch.
In the PR window you will see the feedback from the tests (passing/not passing).

You may want to modify this flow to fire on other branches or conditions, check out all the possible triggers for GitHub actions.

If you want to see all of the actions that have been run on your repo you can look at the actions tab:

The above screen cap is from the qRAM library's actions page.
You can see the details of a particular action run here:

Now that you are sure your code is building and ready to merge it into master, let's take a look at the workflow that will package our library!

Automating packaging

In the same workflows/ folder, create a file called publish.yml with the following contents:

name: Build and publish NuGet package to GitHub packages

on:
  push:
    branches: [ master ]

jobs:
  build:
    runs-on: windows-latest

    steps:
    # Same checkout action as before, but adding an authentication token to
    # help push the package to the GPR.
    - uses: actions/checkout@v2
    # NUGET_AUTH_TOKEN trick from https://stackoverflow.com/questions/57889719/how-to-push-nuget-package-in-github-actions
    - name: "Setup .NET Core @ Latest"
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '3.1.x'
        source-url: https://nuget.pkg.github.com/qsharp-community/index.json
      env:
        NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}

    # The command `dotnet pack` will build your project and then pack it up in 
    # a NuGet package. The `-c` switch to indicate the build configuration
    # here "Release" and `-o` indicates where it will put the output. We just
    # make a new directory called `drop` at the project root and will get the 
    # built package from there later.
    - name: .NET pack
      run: dotnet pack -c Release -o ../drop /p:Version="0.1.$Env:GITHUB_RUN_NUMBER"
      shell: pwsh
      working-directory: src

    # The command `dotnet nuget push` takes the package we made in the previous
    # step in the `drop` directory and pushes it to the GitHub Package Registry.
    - name: Push to GitHub Packages
      run: dotnet nuget push (Join-Path "drop" "*.nupkg")
      shell: pwsh

The line you will have to change for your repo is the source-url: https://nuget.pkg.github.com/qsharp-community/index.json line.
Change the qsharp-community to the repo owner of the repo you are working in.
For more information on this configuration see the docs.

FIXME: So the numbering of the packages here is still not perfect, and is keyed off of the GITHUB_RUN_NUMBER of the action.
In order to be SemVer 2.0 compliant, it needs to start over when the minor or major version is incremented but I haven't figured out a good way to do this yet. 😆

Next steps: Templates and NuGet.org

So if you made it here and haven't made your repo yet, I saved you some time by making a template repo on GitHub.
I will keep it up to date while we continue with the qRAM project and when I figure out how to increment versions numbers better, I'll push the fix there too.
Also when the qRAM library is ready to go to version 1.0 and publish it on NuGet.org, I will add another workflow to the template repo to publish your library there too!

Hopefully you found this post helpful, and are ready to start making your own library for Q# today! 💖

Quantum Sweepstakes Machine

Sarah Kasier — Fri, 15 May 2020 01:40:25 +0000

TL;DR I wrote a quantum random number generator in Q# to play games. Run the code in your browser here:

I have really been enjoying working on some of my open source projects on Twitch lately, and to try and drive more viewership I thought I would do a giveaway/sweepstakes on a stream. It came time to select the winner and I realized I simply could not do this with a boring old random number generator online. So I decided to write up a quick snippet in Q#, Microsoft's new quantum programming language, on the stream and wanted to post a quick write up with the code here.

You can find the code for this post in this Gist, and run it all in your browser on myBinder.

There are two main files included in this gist, the first is a Jupyter Notebook that allows you to run the snippet and use it to select random integers yourself!

It currently is setup to select a random integer from 0 to 6 inclusive (7 total players), which index the list of viewers I had at the time. If you want to change the number of players you can just edit the argument in the first cell and re-run it by hitting shift and enter at the same time.

The Q# code here can be found in the operations.qs file:

This file defines a namespace Sweepstakes and one operation, SelectWinner that takes an integer argument that defines the number of players.
The main steps to this pretty short operation are as follows:

Figure out how many qubits you need to represent the number of players you have.
Allocate your qubits with using, and put them all in superposition by applying the H operation (short for Hadamard) to each qubit in the register.
Measure the register and interpret the bit string of measurement results as a binary value (MeasureInteger). I did have to also specify whether the register was to be interpreted as a little endian register so it knew how to parse it.
Lastly, if that measured integer was outside of the range of players (this will happen if the number of players is not a power of 2) then just repeat steps 2 and 3 until you get a valid player index.

And that's pretty much it!
A random integer generator written in the quantum programming language Q# that you can use to make all of the hard decisions in your life 😋
If you want to learn more about developing for quantum computers or how they work, you can check out these links:

An array of facts on arrays in Q#

Sarah Kasier — Sun, 15 Mar 2020 01:11:32 +0000

Post co-authored with Chris Granade, my co-author on Learn Quantum Computing with Python and Q#!

All of the Q#, C# and Python examples in this post can be run online on Binder. It may take a while to build the docker container so read ahead, and you can jump back when it's done. 😊

Normally when you read a post or an article about a quantum programming language like Q#, you'll see stuff about:

what qubits are,
what a quantum computer even is, or
how superposition and entanglement can be used together to solve hard problems.

That's all really important to help understand why quantum computing is so cool, and how you can get started with it, but there is something that's easily lost in all of that: quantum programs are just special kinds of classical programs.

What do we mean by that?
At their core, quantum programs are classical programs that send instructions to quantum devices. That means that a lot of what you already know about classical programming still applies. In this post, we'll look at how Q# represents one incredibly common classical data structure in what may seem to be a slightly unusual way, and how that helps make Q# a great classical language for controlling quantum devices.

Arrays in Q#

Whatever they might be called in a particular language, arrays are an incredibly common and useful data structure for developers. There can be differences in how they behave from language to language, so it might be helpful to take a look at how they work in Q#.

Consider the following snippet where you are creating two arrays (a and b) in Q#.

mutable a = [2, 4, 6];
let b = a;

// Change the first element of `a` to 1.
set a w/= 0 <- 1;

Message($"{b}");

What will the value of b be after running all the code above? Reminder you can run all the code in this post on Binder.

The answer here comes down to the difference between whether we think of a variable as storing a value, or as being a reference to something. In Q#, everything is a value, so when we define a new variable with let b = a, we tell the Q# compiler that we want the value of b to be equal to whatever the value of a is.

Therefore, the snippet above will print out the array [2, 4, 6], because after we defined b as having the value that a had at that moment ([2, 4, 6]), not a reference to the variable a. Put differently, b does not know anything about a, let alone any later changes to a.

Thinking of arrays as values also helps explain what w/= is all about in the code above. In Q#, w/ is a ternary operator (that is, one with three arguments) that makes a new array given: an old array, an index you want to replace, and a new element to put at that index. For example:

let a = [2, 4, 6] w/ 0 <- 1;
Message($"{a}"); // Prints [1, 4, 6].

Since w/ is an operator, you can use it like +, *, or any other operator to make Q# values:

let a = ([2, 4, 6] w/ 0 <- 1 w/ 2 <- 10) + [20];
Message($"{a}"); // Prints [1, 4, 10, 20].

When updating the value of a mutable variable, Q# provides helpful shorthand for using an operator in-place as an assignment operator:

mutable a = 10;
set a += 1;
Message($"{a}"); // Prints 11.

The same exact shorthand works for w/, so you can use w/= as a shorthand:

mutable a = [2, 4, 6];
// Both of the following lines are equivalent:
set a = a w/ 0 <- 1;
set a w/= 0 <- 1;

What makes all of this work is that in Q#, everything is a value.
The array [2, 4, 6] is a value in precisely the same way as 2 is a value, or that true, "foo", and 3.14 are values.

How do Q# arrays compare to similar concepts in other languages?

In Python, there isn't exactly an array type, so let's look at some related types you might use in a similar way. Lists, tuples, and strings in Python are ways of organizing collections of elements, so let's compare how they work to Q# arrays.

Tuples and strings are immutable, meaning that they cannot be changed after they are created. What happens in the following snippet?

a = "Hello world!"
b = a
a = a[:5] + " Cruel" + a[5:]
print(b)

This will print Hello world!, because b is immutable once created. The third line where we construct a new value for a works because we are not trying to change a's previous value, but give an entirely new one.

C# takes a very similar approach, treating strings as immutable. Try running the following example in a C# Notebook and see what you get!

var s = "abc";
var t = s;
s = s.Remove(1, 1).Insert(1, "B");
(s, t)

This immutability makes it really easy to reason about side-effects, since nothing else in your Python program can possibly mess with what a is. Where immutability in Python gets inconvenient, though, is if you want to replace just one element of a tuple or string:

>>> a = "Hello, world!"
>>> a[-1] = "?"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object does not support item assignment

To help with this, Python also provides lists, which are really similar to tuples, but are mutable; that is, the contents of lists can be changed after they are created.

>>> a = [2, 4, 6]
>>> a[-1] = 10
>>> a
[2, 4, 10]

One way to think about Q# arrays, then, is as being similar to Python tuples, but with a cool operator (w/) that lets you use them in the same ways as lists even without needing mutable collections. That lets you get all the benefits and predictability of immutable collections like Python strings and tuples, and like C# strings, but with the flexibility that you would normally expect from mutable collections like Python lists and and C# arrays.

You can use Q# arrays to implement a wide range of classical computing tasks from within your quantum programs, even including things like the quicksort algorithm!

function Sorted<'T>(comparisonFunction : (('T, 'T) -> Bool), inputArray: 'T[]) : 'T[] {
    if (Length(inputArray) <= 1) {
        return inputArray;
    }
    let pivot = Head(inputArray);
    let left = Filtered(comparisonFunction(_, pivot), Rest(inputArray));
    let right = Filtered(Compose(Not, comparisonFunction(_, pivot)), Rest(inputArray));

    return Sorted(comparisonFunction, left) + [pivot] + Sorted(comparisonFunction, right);
}

Because Q# arrays are values, it's really easy to predict how they'll behave in your quantum programs, even as you do things like use the Adjoint functor to run parts of your programs backwards. Arrays are a great example of how the classical programming features of Q# are designed, making it easy to use for quantum computing 💖

More Resources!

Want to learn more about arrays in Q# or Quantum Computing? Check out the links below for some good resources! 😀