Nouveautés du kit de développement Azure Quantum (QDK moderne)

  • Article

Le QDK moderne est la dernière version du langage Q# et des outils de développement. Avec un encombrement plus réduit et des performances plus rapides, il s’agit d’une extension Visual Studio Code en un clic et de fonctionnalités d’amélioration du langage, de prise en charge intégrée de Python et de Jupyter Notebook, de mise en évidence de la nouvelle syntaxe, de prise en charge du débogueur, de prise en charge de projets multi-fichiers, de messages d’erreur et de connectivité Azure intégrée. En éliminant les dépendances du QDK classique précédent, il est désormais véritablement indépendant de la plateforme, s’exécutant sur Windows, Mac, Linux et le web.

Intégration de Visual Studio Code

Le QDK moderne est étroitement intégré à l’environnement de développement Visual Studio Code. Les nouvelles fonctionnalités incluent :

  • Un nouvel estimateur de ressources pour VS Code que vous pouvez exécuter localement sans compte Azure
  • Un débogueur Q# pour le débogage intégré avec points d’arrêt, pas à pas et vue variables locales et quantiques
  • Prise en charge des projets Q# multi-fichiers
  • Améliorations apportées au serveur de langage avec la messagerie d’erreur, la mise en surbrillance de syntaxe, les saisies de code, les informations de pointage et les définitions d’accéder à
  • Connectivité de l’espace de travail Azure intégrée et soumission de travaux
  • Un simulateur partiellement alloué (sans bruit) intégré
  • Jupyter Notebook intégration avec le codage Q# dans les cellules et la mise en surbrillance de la syntaxe
  • Génération QIR pour les programmes Q#

Bientôt disponible

  • L’informatique hybride intégrée avec profil adaptatif n’est pas encore prise en charge avec le QDK moderne. Si vous devez exécuter des projets d’informatique hybride, consultez Continuer à travailler dans le QDK classique.

Fonctionnalités dépréciées

  • Prise en charge de Visual Studio
  • Prise en charge des langages et projets .NET
  • Le noyau IQ# et les commandes magiques pour les notebooks Jupyter. Pour plus d’informations sur l’utilisation des notebooks Q# et Jupyter, consultez intégration Jupyter Notebook et Migration de votre code.

Mises à jour du langage Q#

Alors que les découvertes et innovations quantiques continuent d’évoluer à un rythme rapide, le langage Q# et le kit de développement Azure Quantum continuent d’évoluer pour répondre aux besoins actuels et futurs de développement quantique. Les sections suivantes décrivent les modifications, mises à jour et améliorations apportées au QDK moderne.

Mises à jour de la syntaxe du langage

Basé sur les expressions

Le langage Q# est désormais basé sur des expressions plutôt que sur des instructions. Cela permet une nouvelle utilisation de la syntaxe existante, comme l’incorporation d’une expression if dans une autre expression :

let x = if check { 0 } else { 1 };

Retour implicite

L’exemple précédent tire également parti de l’utilisation d’instructions sans point-virgule de fin à la fin d’un bloc pour renvoyer une valeur de ce bloc. Ce modèle peut être utilisé au lieu d’expressions de retour explicites dans un callable :

function ReturnsThree() : Int {
    return 3;
}

function AlsoReturnsThree() : Int {
    3
}

Expressions de blocs

Q# prend désormais en charge les expressions de blocs qui peuvent organiser plusieurs lignes, variables d’étendue et retourner une valeur :

let flip = {
    use q = Qubit();
    H(q);
    if M(q) == One {
        X(q);
        "Heads"
    } else {
        "Tails"
    }
} ;

Éléments en tant qu’instructions

Des éléments tels que newtype, functionoperationet même open peuvent désormais apparaître sous forme d’instructions dans une étendue locale. Cela permet de définir des types d’assistance locaux et des callables, ainsi que des incluts délimités. Par exemple, une fonction d’assistance locale peut être définie juste avant d’en avoir besoin :

function ShowDecrement() : Unit {
    open Microsoft.Quantum.Arrays;
    let before = [1, 2, 3];

    function SubOne(in : Int) : Int {
        in - 1
    }

    let after = Mapped(SubOne, before);
    // after will be [0, 1, 2]
}

La fonction SubOne et l’ouverture de l’espace Microsoft.Quantum.Arrays de noms sont limitées à la fonction et n’affectent pas le ShowDecrement code en dehors de celle-ci.

Ombrage de noms

Q# permet désormais d’observer les noms résolus lorsque cela était précédemment interdit. Cela permet de réutiliser plus facilement le code qui inclut des noms de variables ou d’appelables sans avoir besoin d’une variable mutable :

function Shadowing(input : Int) : Double {
    let input = 2 * input;
    let output = Calculate(input);
    let output = IntAsDouble(output);
    return output;
}

Types explicites pour les variables locales

Les variables locales peuvent désormais être typées explicitement à l’aide de la même syntaxe que les types pour les déclarations d’arguments pouvant être appelées :

let x : Int[] = [];

Les types explicites ne sont pas obligatoires, mais peuvent parfois être utiles lors de la résolution de l’ambiguïté de type pour les fonctions qui acceptent des génériques, comme Length. Le modèle précédent pour la gestion de ce problème , l’ajout de types concrets à un appel de fonction générique avec une syntaxe telle que Length<Int[]>([]); – n’est plus pris en charge.

Prélude implicite de l’espace de noms

La résolution de noms incorpore désormais un prélude implicite qui est un ensemble d’espaces de noms qui sont traités comme s’ils avaient été ouverts, tant qu’aucun autre nom résolu ne les remplace. Les espaces de noms traités de cette façon sont Microsoft.Quantum.Core, Microsoft.Quantum.Canonet Microsoft.Quantum.Intrinsic. Ceux-ci n’ont pas besoin d’être ouverts explicitement, sauf en cas d’utilisation d’alias ou de différenciation des conflits potentiels.

Bibliothèque standard

La bibliothèque standard Q# est désormais hébergée dans le même dépôt que le compilateur et le runtime, et se trouve dans le dossier de la bibliothèque de niveau supérieur. Toutes les fonctionnalités et fonctionnalités n’ont pas été migrées à partir des bibliothèques Q# classiques, qui sont toujours accessibles à l’adresse https://github.com/microsoft/QuantumLibraries. Si un élément de la bibliothèque précédente est nécessaire pour un programme, cet élément et toutes les dépendances peuvent être copiés dans le programme source. Si une fonctionnalité de bibliothèque est critique pour un flux de travail et doit être envisagée pour l’inclusion dans la nouvelle bibliothèque standard, veuillez signaler un problème GitHub avec les détails.

Simulation

Simulation éparse par défaut

Le QDK moderne utilise un simulateur quantique d’état éparse intégré comme valeur par défaut target pour la simulation locale. Ce simulateur est écrit en Rust et provient du référentiel QIR Runner , ce qui lui permet de compiler sur WASM et de s’exécuter dans divers environnements. Actuellement, il s’agit du seul back-end de simulation disponible dans le QDK, bien que d’autres back-ends soient à l’étude pour une intégration future. Pour plus d’informations sur la conception de la simulation éparse, consultez Test de grands algorithmes quantiques à l’aide d’une simulation éparse.

Contrôles plus stricts sur la version des qubits

Le QDK classique avait historiquement assoupli l’exigence que les qubits soient à l’état sol ou |0⟩ avant d’être libérés à la fin de leur portée, de sorte qu’un qubit qui a été mesuré et qui n’a pas été utilisé plus était également sûr de libérer, car le simulateur réinitialiserait automatiquement le qubit. Toutefois, cela a provoqué une confusion lorsque le même programme a été exécuté sur du matériel quantique réel où une telle réinitialisation automatique n’est pas présente et où les qubits peuvent être réutilisés dans un état inattendu. Pour le QDK moderne, nous sommes revenus à un comportement plus strict qui consiste à appliquer que les qubits doivent être à l’état de base lors de la mise en production. Cela permet aux auteurs d’algorithmes de vérifier le comportement de leur algorithme pour l’exactitude en préparation de l’exécution sur du matériel.

Portes multicontrées décomposées

Le QDK moderne utilise désormais des stratégies de décomposition pour les portes multicontrées. Bien que cela ne tire pas parti des raccourcis disponibles pour la simulation où les portes contrôlées sont facilement implémentées, il correspond plus étroitement au comportement des systèmes quantiques physiques. Cela signifie que l’exécution d’une porte avec un grand nombre de qubits de contrôle entraîne des allocations de qubits et des portes de préparation supplémentaires, de la même façon que lorsqu’elle est compilée pour l’exécution sur du matériel. Pour plus d’informations sur les algorithmes de décomposition utilisés, consultez l’implémentation dans la bibliothèque standard.

Génération QIR

Le QDK moderne produit le QIR en générant la représentation textuelle de LLVM (.ll) au lieu d’utiliser le code binaire (.bc). La plupart des targets outils et qui acceptent le bitcode peuvent également analyser le texte LLVM, y compris des outils tels que PyQIR et QIR Runner.

Le QDK moderne est actuellement limité à la génération QIR pour les programmes compatibles avec le profil de base QIR. Lorsque la compilation du profil de base est configurée, le compilateur et l’extension VSCode produisent des erreurs pour les modèles qui ne sont pas compatibles avec .target Le compilateur peut également ignorer de manière conditionnelle la compilation d’éléments qui ont des attributs indiquant qu’ils sont spécifiques à une compilation targetsparticulière :

@Config(Unrestricted)
function ResultAsBool(input : Result) : Bool {
    input == One
}