PDL::Dataflowp - Online in de cloud

PROGRAMMA:

NAAM

PDL::Dataflow -- beschrijving van de dataflow-filosofie

KORTE INHOUD

pdl> $a = nullen(10);
pdl> $b = $a->slice("2:4:2");
pdl> $b++;
pdl> print $a;
[0 0 1 0 1 0 0 0 0 0]

WAARSCHUWING

Dataflow is erg experimenteel. Vooral voor 2.0 zijn veel functies ervan uitgeschakeld
families voor gegevensstroom in één richting. Als u eenrichtingsgegevensstroom wilt gebruiken voor
iets, neem dan eerst contact op met de auteur en we zullen uitzoeken hoe we het functioneel kunnen maken
weer.

Gegevensstroom in twee richtingen (die ->plak() enz.) is echter volledig functioneel.
Vrijwel elke functie die een deelverzameling van de waarden in een of andere piddle retourneert, maakt a
bindend zodat

$a = wat piddle
$b = $a->slice("sommige delen");
$b->set(3,3,10);

verandert ook het overeenkomstige element in $a. $b is voor sommigen in feite een venster geworden
subelementen van $a. U kunt ook uw eigen routines definiëren die verschillende soorten doen
subsets. Als je niet wilt dat $b een venster is naar $a, dan moet je dat doen

$b = $a->slice("sommige delen")->kopiëren;

Het kopiëren schakelt alle datastromen tussen de twee piddles uit.

De problemen met eenrichtingsgegevensstroom houden verband met sequenties zoals

$b = $a + 1;
$b++;

waar er verschillende mogelijke uitkomsten zijn en de semantiek een beetje troebel wordt.

PRODUCTBESCHRIJVING

Dataflow is nieuw voor PDL2.0. De basisfilosofie achter dataflow is dat

> $a = pdl 2,3,4;
> $b = $a * 2;
> print $ b
[2 3 4]
> $a->set(0,5);
> print $b;
[10 3 4]

zou moeten werken. Dat doet het niet. Men was van mening dat het te verwarrend zou kunnen zijn om dit te doen
beginners en incidentele gebruikers van de taal. Daarom moet u expliciet inschakelen
gegevensstroom, dus

> $a = pdl 2,3,4;
> $a->doflow();
> $b = $a * 2;
...

levert het onverwachte resultaat op. In de rest van dit document worden verschillende functies en functies uitgelegd
details van de dataflow-implementatie.

lui evaluatie

Als je zoiets berekent als hierboven

> $a = pdl 2,3,4;
> $a->doflow();
> $b = $a * 2;

op dit moment is er nog niets berekend. Zelfs het geheugen voor de inhoud van $b
is niet toegewezen. Alleen de opdracht

> print $ b

zal er in feite voor zorgen dat $b wordt berekend. Dit is belangrijk om in gedachten te houden bij het doen
prestatiemetingen en benchmarks, evenals bij het opsporen van fouten.

Er is een verklaring voor dit gedrag: het kan cycli besparen, maar wat nog belangrijker is,
stel je het volgende voor:

> $a = pdl 2,3,4;
> $b = pdl 5,6,7;
> $c = $a + $b;
...
> $a->vergroten of verkleinen(4);
> $b->vergroten of verkleinen(4);
> print $c;

Nu, als $c tussen de twee formaatwijzigingen wordt geëvalueerd, is de foutconditie incompatibel
maten zouden voorkomen.

Wat er in de huidige versie gebeurt, is dat het wijzigen van de grootte van $a een vlag opwerpt in $c:
"PDL_PARENTDIMSCHANGED" en $b steekt gewoon weer dezelfde vlag op. Wanneer $c vervolgens wordt geëvalueerd,
de vlaggen worden gecontroleerd en er wordt vastgesteld dat een herberekening nodig is.

Natuurlijk kan luie evaluatie het debuggen soms pijnlijker maken omdat er fouten kunnen optreden
gebeuren ergens waar je ze niet zou verwachten. Een betere stacktracering voor fouten bevindt zich in het
werkt voor PDL, waarschijnlijk zodat je $PDL::traceevals kunt omschakelen en een goed krijgt
spoor van waar de fout eigenlijk was.

Families

Dit is een van de meer ingewikkelde concepten van eenrichtingsgegevensstroom. Houd rekening met de
volgende code ($a en $b zijn pdls die dataflow hebben ingeschakeld):

$c = $a + $b;
$e = $c + 1;
$d = $c->diagonaal();
$d++;
$f = $c + 1;

Wat moeten $e en $f nu bevatten? Hoe zit het wanneer $a wordt gewijzigd en er een herberekening plaatsvindt
veroorzaakt.

Om dataflow te laten werken zoals je zou verwachten, moet het een nogal vreemd concept zijn
geïntroduceerd: gezinnen. Laten we een diagram maken:

ab
\/
c
/|
​
ed

Dit is wat PDL daadwerkelijk in het geheugen heeft na de eerste drie regels. Wanneer $d wordt gewijzigd,
we willen dat $c verandert, maar we willen niet dat $e verandert omdat het al in de grafiek staat. Het
is nu misschien niet duidelijk waarom u niet wilt dat het verandert, maar als er 40 regels code waren
tussen de 2e en 4e regel wel. We moeten dus een kopie maken van $c en $d:

ab
\/
C' . . . C
/| |\
/ | | \
ed'. . . df

Merk op dat we de originele c en d hebben geprimed, omdat ze niet overeenkomen met de objecten
in $c en $d meer. Let ook op de stippellijnen tussen de twee objecten: wanneer $a is
gewijzigd en dit diagram opnieuw geëvalueerd, $c krijgt echt de waarde van c' met de
diagonaal verhoogd.

Om het bovenstaande te generaliseren, wanneer een piddle gemuteerd is, dwz wanneer de werkelijke *waarde* is
gedwongen veranderd (niet alleen de referentie:

$d = $d + 1

zou een heel ander resultaat opleveren ($c en $d zouden niet meer gebonden zijn terwijl

$d .= $d + 1

zou hetzelfde opleveren als $d++), een "familie" bestaande uit alle andere piddles verbonden aan de
gemuteerde piddle door een tweerichtingstransformatie wordt gemaakt en al die worden gekopieerd.

Alle segmenten of transformaties die eenvoudigweg een subset van de originele pdl selecteren, zijn in twee richtingen.
Matrix inverse zou moeten zijn. Er zijn geen rekenkundige operatoren.

bronnen

Wat u in het vorige gedeelte is verteld, is niet helemaal waar: het beschreven gedrag is dat wel
niet *altijd* wat je wilt. Soms wilt u waarschijnlijk een gegevensbron hebben:

$a = pdl 2,3,4; $b = pdl 5,6,7;
$c = $a + $b;
regel($c);

Nu, als je weet dat $a gaat veranderen en dat je wilt dat zijn kinderen mee veranderen
kunt u deze declareren in een gegevensbron (XXX niet geïmplementeerd in de huidige versie):

$ een->databron(1);

Hierna zal $a++ of $a .= iets geen nieuwe familie creëren, maar $a wijzigen en knippen
zijn relatie met zijn vorige ouders. Alle kinderen volgen de huidige waarde.

Dus als $c in de vorige sectie als bron was opgegeven, zouden $e en $f overblijven
Gelijk.

Bindend

Een dataflow-mechanisme zou niet erg nuttig zijn zonder de mogelijkheid om gebeurtenissen aan te binden
gewijzigde gegevens. Daarom bieden we een dergelijk mechanisme:

> $a = pdl 2,3,4
> $b = $a + 1;
> $c = $b * 2;
> $c->bind( sub { print "A nu: $a, C nu: $c\n" } )
> PDL::dowhenidle();
A nu: [2,3,4], C nu: [6 8 10]
> $a->set(0,1);
> $a->set(1,1);
> PDL::dowhenidle();
A nu: [1,1,4], C nu: [4 4 10]

Merk op hoe de callbacks alleen worden aangeroepen tijdens PDL::dowhenidle. Een gemakkelijke manier om te communiceren
dit naar Perl event loop-mechanismen (zoals Tk) wordt gepland.

Er zijn veel soorten toepassingen voor deze functie: bijvoorbeeld zelf-bijwerkende grafieken.

Bla bla bla XXX meer uitleg

Beperkingen

Dataflow is als zodanig een vrij beperkte toevoeging bovenop Perl. Om een ​​meer verfijnde te krijgen
bovendien moet de binnenkant van Perl een beetje worden gehackt. Een echte implementatie zou
stroom van alles mogelijk maken, inclusief

gegevens
gegevensgrootte:
data type
operaties

Op dit moment hebben we alleen de eerste twee (hé, 50% in een paar maanden is niet slecht ;) maar
zelfs dit is op zichzelf nuttig. Vooral dat laatste is echter wenselijk omdat het
zou de mogelijkheid toevoegen van vloeiende sluitingen van plaats tot plaats en zou er veel maken
dingen flexibeler.

Om de rest werkend te krijgen, moet de interne gegevensstroom waarschijnlijk worden gewijzigd in een
meer algemeen kader.

Bovendien zou het leuk zijn om gegevens in de tijd te kunnen laten stromen, zoals lucide (dus je zou kunnen
eenvoudig allerlei soorten signaalverwerking definiëren).

Gebruik PDL::Dataflowp online met behulp van onworks.net-services