PDL::Dataflowp - En ligne dans le Cloud

PROGRAMME:

Nom

PDL::Dataflow -- description de la philosophie du flux de données

SYNOPSIS

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

ATTENTION

Le flux de données est très expérimental. De nombreuses fonctionnalités sont désactivées pour 2.0, en particulier
familles pour un flux de données unidirectionnel. Si vous souhaitez utiliser un flux de données unidirectionnel pour
quelque chose, veuillez d'abord contacter l'auteur et nous trouverons comment le rendre fonctionnel
nouveau.

Flux de données bidirectionnel (qui implémente ->tranche() etc.) est entièrement fonctionnel, cependant.
À peu près n'importe quelle fonction qui renvoie un sous-ensemble des valeurs dans un piddle fera un
contraignant de sorte que

$a = un peu de piddle
$b = $a->slice("certaines parties");
$b->set(3,3,10) ;

modifie également l'élément correspondant dans $a. $b est devenu effectivement une fenêtre sur certains
sous-éléments de $a. Vous pouvez également définir vos propres routines qui effectuent différents types de
sous-ensembles. Si vous ne voulez pas que $b soit une fenêtre sur $a, vous devez faire

$b = $a->slice("certaines parties")->copy ;

La copie désactive tout flux de données entre les deux piddles.

Les difficultés avec le flux de données unidirectionnel sont liées à des séquences telles que

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

où il y a plusieurs résultats possibles et la sémantique devient un peu trouble.

DESCRIPTION

Le flux de données est nouveau pour PDL2.0. La philosophie de base derrière le flux de données est que

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

devrait marcher. Ce n'est pas le cas. Il a été considéré que faire cela pourrait être trop déroutant pour
novices et utilisateurs occasionnels de la langue. Par conséquent, vous devez explicitement activer
flux de données, donc

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


produit le résultat inattendu. Le reste de ce document explique diverses fonctionnalités et
détails de la mise en œuvre du flux de données.

Paresseux évaluation

Lorsque vous calculez quelque chose comme ci-dessus

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

rien n'aura été calculé à ce stade. Même la mémoire pour le contenu de $b
n'a pas été attribué. Seule la commande

> imprimer $b

entraînera en fait le calcul de $b. Ceci est important à garder à l'esprit lorsque vous faites
les mesures de performance et les références ainsi que lors du suivi des erreurs.

Il y a une explication à ce comportement : cela peut sauver des cycles mais surtout,
imaginez ce qui suit :

> $a = pdl 2,3,4;
> $b = pdl 5,6,7 ;
> $c = $a + $b ;

> $a->redimensionner(4);
> $b->redimensionner(4);
> imprimer $c;

Maintenant, si $c était évalué entre les deux redimensionnements, une condition d'erreur incompatible
tailles se produiraient.

Ce qui se passe dans la version actuelle, c'est que le redimensionnement de $a lève un drapeau dans $c :
"PDL_PARENTDIMSCHANGED" et $b lèvent à nouveau le même drapeau. Lors de la prochaine évaluation de $c,
les drapeaux sont vérifiés et il s'avère qu'un recalcul est nécessaire.

Bien sûr, l'évaluation paresseuse peut parfois rendre le débogage plus pénible car des erreurs peuvent
se produire quelque part où vous ne les attendriez pas. Une meilleure trace de pile pour les erreurs est dans le
fonctionne pour PDL, probablement pour que vous puissiez basculer un commutateur $PDL::traceevals et obtenir un bon
trace de l'endroit où se trouvait réellement l'erreur.

Familles

C'est l'un des concepts les plus complexes du flux de données unidirectionnel. Prendre en compte
code suivant ($a et $b sont des pdls pour lesquels le flux de données est activé) :

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

Que doivent contenir $e et $f maintenant ? Qu'en est-il lorsque $a est modifié et qu'un recalcul est
déclenché.

Pour que le flux de données fonctionne comme vous le souhaitez, un concept plutôt étrange doit être
introduits : les familles. Faisons un schéma :

un B
\ /
c
/|
/ |
ed

C'est ce que PDL a en mémoire après les trois premières lignes. Lorsque $d est modifié,
nous voulons que $c change mais nous ne voulons pas que $e change car il est déjà sur le graphique. Ce
peut ne pas être clair maintenant pourquoi vous ne voulez pas que cela change mais s'il y avait 40 lignes de code
entre les 2e et 4e lignes, vous le feriez. Nous devons donc faire une copie de $c et $d :

un B
\ /
c'. . . c
/| |\
/ | | \
éd' . . . df

Notez que nous avons amorcé les c et d d'origine, car ils ne correspondent pas aux objets
dans $c et $d plus. Notez également les lignes pointillées entre les deux objets : lorsque $a est
changé et ce diagramme est réévalué, $c obtient vraiment la valeur de c' avec le
diagonale incrémentée.

Pour généraliser sur ce qui précède, chaque fois qu'un piddle est muté, c'est-à-dire lorsque sa *valeur* réelle est
changé de force (pas seulement la référence :

$d = $d + 1

produirait un résultat complètement différent ($c et $d ne seraient plus liés alors que

$d .= $d + 1

donnerait la même chose que $d++), une "famille" composée de tous les autres piddles joints au
piddle muté par une transformation bidirectionnelle est créé et tous ceux-ci sont copiés.

Toutes les tranches ou transformations qui sélectionnent simplement un sous-ensemble du pdl d'origine sont bidirectionnelles.
La matrice inverse devrait être. Il n'y a pas d'opérateurs arithmétiques.

Sources

Ce qu'on vous a dit dans la section précédente n'est pas tout à fait vrai : le comportement décrit est
pas *toujours* ce que tu veux. Parfois, vous aimeriez probablement avoir une "source" de données :

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

Maintenant, si vous savez que $a va changer et que vous voulez que ses enfants changent avec
celui-ci, vous pouvez le déclarer dans une source de données (XXX non implémenté dans la version actuelle) :

$a->source de données(1);

Après cela, $a++ ou $a .= quelque chose ne créera pas de nouvelle famille mais modifiera $a et coupera
sa relation avec ses parents précédents. Tous ses enfants suivront sa valeur actuelle.

Donc si $c dans la section précédente avait été déclaré comme source, $e et $f resteraient
égal.

Fixations

Un mécanisme de flux de données ne serait pas très utile sans la possibilité de lier des événements à
données modifiées. Par conséquent, nous proposons un tel mécanisme:

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

Remarquez comment les rappels ne sont appelés que pendant PDL::dowhenidle. Un moyen simple d'interfacer
ceci vers des mécanismes de boucle d'événement Perl (tels que Tk) est en cours de planification.

Il existe de nombreux types d'utilisations pour cette fonctionnalité : les graphiques d'auto-mise à jour, par exemple.

Blah blah blah XXX plus d'explications

Limites

Dataflow en tant que tel est un ajout assez limité au-dessus de Perl. Pour obtenir un plus raffiné
De plus, les internes de Perl ont besoin d'être piratés un peu. Une véritable mise en œuvre serait
permettre la circulation de tout, y compris

données
taille des données
Type de données


Pour le moment, nous n'avons que les deux premiers (hé, 50% dans quelques mois, c'est pas mal ;) mais
même cela est utile en soi. Cependant, surtout le dernier est souhaitable car il
ajouterait la possibilité de faire circuler les fermetures d'un endroit à l'autre et rendrait de nombreux
les choses plus flexibles.

Pour que le reste fonctionne, les éléments internes du flux de données doivent probablement être modifiés pour être un
cadre plus général.

De plus, ce serait bien de pouvoir faire circuler des données dans le temps, de manière lucide (ainsi vous pourriez
définir facilement toutes sortes de choses de traitement du signal).

Utilisez PDL::Dataflowp en ligne à l'aide des services onworks.net