BrainScript via regler för parsning av kommandorad

Artikel
03/15/2017

Nedan beskriver vi CNTK regler för parsning av kommandoraden. CNTK består av ett antal komponenter för att slutföra en uppgift. De flesta av dessa komponenter behöver viss konfigurationsinformation för att fungera, och dessa konfigurationsparametrar tillhandahålls via konfigurationsfiler i CNTK.

Konfigurationsfiler är samlingar med namn/värde-par. Konfigurationsdata kan vara någon av följande typer:

Enkelt: ett enda värde tilldelas till konfigurationsparametern. Till exempel deviceId = "Auto".
Matris: en konfigurationsparameter tilldelas en matris med värden som inte behöver vara av en enhetlig typ. : är standardavgränsaren för matriser. Avgränsaren kan ändras genom att matrisvärdena omges av parenteser och det nya avgränsartecknet placeras omedelbart efter den öppna parentesen. Tecknet * tillåter att ett visst värde upprepas flera gånger i matrisen. Är till exempel minibatchSize = 256:512:512:512:1024 lika med minibatchSize = 256:512*3:1024.
Ange: parameteruppsättningar innehåller uppsättningar med konfigurationsparametrar av valfri typ. Parameteruppsättningar kan kapslas. Standardavgränsaren för parameteruppsättningar är ; om flera objekt ingår på en rad. Radavgränsare fungerar också som avgränsare för objekt. Exempel:

block1 = [id=1;size=256]

block2 = [
    subblock = [string="hi";num=5]
    value = 1e-10
    array = 10:"this is a test":1.25
]

I CNTK ordnas konfigurationsfiler på ett hierarkiskt sätt. De faktiska datavärdena utvärderas inte förrän en CNTK komponent begär värdet. När ett värde begärs av en komponent söker CNTK först i komponentblocket. Om värdet inte hittas fortsätter det att leta i parametern parent och grandparent tills parametern hittas eller den översta nivån i konfigurationshierarkin nås utan någon matchning. På så sätt blir det enklare att dela samma parametervärden mellan olika block. Som vi diskuterade tidigare, för att köra CNTK måste du ange konfigurationsfilen på kommandoraden eftersom cntk configFile=yourExp.cntk detta kommer att läsa in den begärda konfigurationsfilen och köra alla kommandoblock som anges i kommandoparametrarna i konfigurationsfilen.

Kommandon och åtgärder

Det måste finnas en kommandoparameter på den översta nivån som definierar de kommandon (avgränsade med :) som ska köras i konfigurationsfilen. Varje kommando refererar till ett kommandoblock i filen, som måste innehålla en åtgärdsparameter som definierar den åtgärd som blocket ska utföra. Följande kommando kör mnistTrain till exempel blocket, som kör träningsåtgärden mnistTest följt av blocket som utvärderar modellen.

command = mnistTrain:mnistTest

mnistTrain = [
    action = "train"
    ...
]

mnistTest = [
    action = "eval"
    ...
]

Överlagring av konfiguration på kommandoraden

Det är vanligt att ha en konfiguration som kan användas som en baskonfiguration och bara ändra några få parametrar för varje experimentell körning. Detta kan göras på några olika sätt, varav ett är att åsidosätta inställningarna på kommandoraden. Om du till exempel vill åsidosätta modellfilens sökväg kan du helt enkelt ändra kommandoraden på följande sätt:

cntk configFile=yourExp.cntk stderr="c:\temp\newpath"

Detta åsidosätter den aktuella inställningen för stderr, som definieras på konfigurationsfilens rotnivå med det nya värdet. Om en parameter i ett kommandoblock måste ändras måste även blocket anges. Man kan till exempel ändra minibatchSize för ett experiment på kommandoraden som

cntk configFile=yourExp.cntk mnistTrain=[minibatchSize=256]

eller ändra datafilen som används för ett experiment som

cntk configFile=yourExp.cntk mnistTrain=[reader=[file="mynewfile.txt"]]

Lagerkonfigurationsfiler

I stället för att åsidosätta vissa delar av en konfigurationsfil med hjälp av kommandoradsparametrar kan man också ange flera konfigurationsfiler, där de senare filerna åsidosätter de tidigare. På så sätt kan en användare ha en huvudkonfigurationsfil och sedan ange i en separat konfigurationsfil vilka parametrar för originalet som de vill åsidosätta för en viss körning av CNTK. Detta kan åstadkommas genom att antingen ange en "+"-avgränsad lista över konfigurationsfiler eller genom att använda taggen configFile= flera gånger. Följande är likvärdiga.

cntk configFile=yourExp1.cntk+yourExp2.cntk

cntk configFile=yourExp1.cntk configFile=yourExp2.cntk

Om yourExp2.cntk bara innehåller strängen mnistTrain=[reader=[file=mynewfile.txt]]skulle båda dessa kommandon motsvara:

cntk configFile=yourExp1.cntk mnistTrain=[reader=[file="mynewfile.txt"]]

Observera att värdet för en variabel alltid bestäms av den senaste gången den tilldelades. Det går också att blanda kommandoradsparametrar och skiktade konfigurationsfiler i godtyckliga kombinationer. Exempel:

cntk configFile=yourExp1.cntk+yourExp2.cntk var1=value configFile=yourExp3.cntk

skulle bearbeta dessa konfigurationsparametrar i den ordning de visas på kommandoraden och det värde som tilldelades sist är det värde som används.

Förutom att kunna ange flera konfigurationsfiler på kommandoraden kan en användare inkludera en konfigurationsfil i en annan. Om till exempel den första raden i yourExp2.cntk var

include=yourExp1.cntk

sedan bara köra

cntk configFile=yourExp2.cntk

skulle motsvara körning

cntk configFile=yourExp1.cntk+yourExp2.cntk

där i det senare fallet yourExp2.cntk inte innehåller include-instruktionen. Observera att dessa inkluderingsinstruktioner kan visas var som helst i en konfigurationsfil. oavsett var include-instruktionen visas, kommer den angivna konfigurationsfilen att inkluderas. Att inkludera en konfigurationsfil motsvarar att klistra in innehållet i filen på platsen för include-instruktionen. Inkludera-instruktioner matchas rekursivt (med hjälp av en djup-första sökning), vilket innebär att om yourExpA.cntk innehåller yourExpB.cntk, och yourExpB.cntk innehåller yourExpC.cntk, så matchas den fullständiga kedjan och yourExpC.cntk tas i praktiken med i yourExpA.cntk. Om en konfigurationsfil inkluderas flera gånger (t.ex. innehåller "A" "B" och "C" och "B" även "C", kommer den i praktiken endast att inkluderas första gången den påträffas.

Stringize Variables

Även om skiktade konfigurationsfiler gör det möjligt för användare att återanvända konfigurationsfiler mellan experiment, kan detta fortfarande vara en besvärlig process. För varje experiment kan en användare behöva åsidosätta flera parametrar, varav vissa kan vara långa filsökvägar (t.ex. stderr, modelPath, ). file Funktionen "stringize" kan göra den här processen mycket enklare. Det gör att en användare kan ange konfiguration som följande:

command = SpeechTrain
stderr = "$Root$\$RunName$.log"
speechTrain = [
    modelPath = "$Root$\$RunName$.cn"
    SGD = [
        reader = [
            features = [
                type = "real"
                dim = "$DataSet1_Dim$"
                file = "$DataSet1_Features$"
            ]
        ]
    ]
]

RootHär är ,RunName, DataSet1_Dim, och DataSet1_Features variabler som anges någon annanstans i konfigurationen (i ett omfång som är synligt från den punkt då de används). När du tolkar den här konfigurationsfilen ersätter parsern varje sträng i formuläret $VarName$ med strängen VarValue, där VarValue representerar värdet för variabeln med namnet VarName. Variabelmatchningsprocessen är rekursiv. Om till exempel A=$B$, B=$C$, och C=HelloWorld.txt, så skulle A matchas som "HelloWorld.txt". Kontrollera att det inte finns någon referensloop i konfigurationsfilen. Annars hamnar parsern i oändlig loop just nu.

Observera att eftersom det är likvärdigt för en användare att ange värdet för en variabel i en konfigurationsfil jämfört med på kommandoraden, kan värdena för dessa variabler anges på någon av platserna. Kom ihåg att värdet för en variabel bestäms av den senaste gången den tilldelades, om det råkar finnas i en konfigurationsfil eller på kommandoraden. Om Root definieras i config1.txt, men åsidosätts på kommandoraden, är det värde som anges på kommandoraden det värde som används för att lösa instanser av $Root$ i configFile1.txt. En användbar funktion är att om stderr eller modelPath pekar på kataloger som inte finns skapas dessa kataloger av CNTK. På så sätt kan du ange något i stil stderr = $Root$\$RunName$\$RunName$.logmed , även om katalogen $Root$\$RunName$ inte finns.

Standardvärden, upprepade värden och kommentarer

De flesta parametrar i konfigurationsfiler har ett standardvärde som används om inget konfigurationsvärde anges. Om det inte finns något standardvärde och det inte går att hitta värdet i en sökning visas ett undantag och programmet avslutas. Om ett parameternamn anges mer än en gång är det sista värdet som anges till det värdet det som ska underhållas. Det enda undantaget till detta är i parameteruppsättningar, som omges av [ hakparenteser ], i dessa fall anses värdena inom klammerparenteserna vara en parameteruppsättning och läggs till i den befintliga parameteruppsättningen. Exempel:

params=[a=1;b=2;c=3]
params=[c=5;d=6;e=7]

är i praktiken lika med:

params=[a=1;b=2;c=5;d=6;e=7]

Observera att den här tilläggsbearbetningen INTE används för matriselement och att hela matrisen ersätts om den anges flera gånger. Tecknet # innebär början av en kommentar, allt som inträffar efter # ignoreras. # måste föregås av blanksteg eller vara i början av raden för att tolkas som en kommentar. Följande är en giltig kommentar

stderr="c:\cntk\log\cntk" # "_mnistTrain_mnistTest.log"

Följande är ett exempel på ett värde som inte tolkas som en kommentar. Den anger en parameter var till oändlighet eftersom # in 1#INF inte är en kommentarsmarkör

var=1#INF

Dela via