Questions diverses sur Perl...

[MaliciaR]

Hello, tout le monde

Bon, je m'acharne toujours avec ce langage peu élégant

J'ai quelques questions "existentielles" qui me sont venues la semaine dernière :

* je me faisais un pitit script pour dénombrer les différents nucléotides dans une séquence d'ADN. Rien de bien compliqué. Il y a juste les manières de faire : je peux soit prendre une séquence, lui faire un split et obtenir ainsi un tableau où chaque élément est une base et une seule et puis itérer sur chaque élément dans une boucle; soit utiliser une boucle for et l'instruction substr pour parcourir la chaîne de caractères position par position. Dans ce dernier cas, les différents signes de la chaîne sont stockés dans une liste.

La question (je n'arrive pas vraiment à prendre de recul pour l'instant) est : est-ce qu'une façon de faire telle la 2e explicitée ci-dessus est plus rapide que la 1re? Si je ne m'abuse, en C les chaînes de caractères sont stockées uniquement sous forme de tableaux. Est-ce que c'est une façon de faire sous optimisée?

* parlant de split : j'ai une erreur à la compilation si j'utilise la synthaxe suivante :

@adn = split (/''/, $adn);

mais pas si j'enlève les / Or, j'ai vu partout sur des sites de docs et tout qu'il faut les / ... Est-ce encore un souci de l'interface chaise-machine comme d'habitude?

* je ne sais pas ce que vous en pensez, mais... j'ai quand même du mal avec le fait que ni l'initialisation des variables est obligatoire, ni la déclaration du type de la variable (je pense toujours au C où on doit spécifier si c'est int ou char ou que sais-je encore...). Oui, certainement, c'est flexible, mais ça me gêne un peu...


Merci pour vos avis
-----

[Towl]

Bon, je m'acharne toujours avec ce langage peu élégant

tss, tss, tss

La question (je n'arrive pas vraiment à prendre de recul pour l'instant) est : est-ce qu'une façon de faire telle la 2e explicitée ci-dessus est plus rapide que la 1re? Si je ne m'abuse, en C les chaînes de caractères sont stockées uniquement sous forme de tableaux. Est-ce que c'est une façon de faire sous optimisée?

Je dirais que oui, c'est sous optimisé, je dirais que l'ideal serait de passer par subs() pour prendre le premier caractere...

Mais a priori, on ne peut pas faire comme en python et considere la chaine comme un tableau :

>>> print "abcde"[2]
c
>>>

Après l'idéal c'est de s'amuser avec les tables de hashages pour avoir un joli code. En python, ca donnerai :

n = {}
for x in "tgca":
    n[x] = 0
for x in "tggacacgttaccccca":
    n[x] += 1
for x in n:
    print "%c = %d" %(x, n[x])

Donne

a = 4
c = 7
t = 3
g = 3

mais pas si j'enlève les / Or, j'ai vu partout sur des sites de docs et tout qu'il faut les / ... Est-ce encore un souci de l'interface chaise-machine comme d'habitude?

Les / détermine la séquence à trouver. Or tu recherches à chaque caractère, donc sur "rien". La syntaxe correcte est donc //. La chaine nulle '' est aussi acceptée, mais /''/ ne veut rien dire (toutes les occurences de la chaine nulle :s).

* je ne sais pas ce que vous en pensez, mais... j'ai quand même du mal avec le fait que ni l'initialisation des variables est obligatoire, ni la déclaration du type de la variable (je pense toujours au C où on doit spécifier si c'est int ou char ou que sais-je encore...). Oui, certainement, c'est flexible, mais ça me gêne un peu...

Moi au contraire, pour scripter j'aime bien de genre de facilité. Mais cela impose de coder tres proprement (pas comme mon exemple )

[MaliciaR]

tss, tss, tss

Oui?

Je dirais que oui, c'est sous optimisé, je dirais que l'ideal serait de passer par subs() pour prendre le premier caractere...

Clair. Mais c'est juste la comparaison des 2 qui m'a fait tiqué.

Mais a priori, on ne peut pas faire comme en python et considere la chaine comme un tableau :

>>> print "abcde"[2]
c
>>>

Ze veux python...

C'est moins mode flemmard en Perl

@bases = ('a', 't', 'c, 'g');
print $bases[2];

#et après avoir gentiment compilé, tu as :
c

Après l'idéal c'est de s'amuser avec les tables de hashages pour avoir un joli code.

Je connais ma douleur depuis hier, oui Surtout que dans le code que je dois pondre, j'ai décidé d'incorporer tous les codes génétiques connus. Et vu la taille de mes fichiers ADN input, je vais m'amuser...

Les / détermine la séquence à trouver. Or tu recherches à chaque caractère, donc sur "rien". La syntaxe correcte est donc //. La chaine nulle '' est aussi acceptée, mais /''/ ne veut rien dire (toutes les occurences de la chaine nulle :s).

Oki doki. En fait, j'avais vu la synthaxe /''/ et puis, j'ai fait comme join càd juste les ''.

Moi au contraire, pour scripter j'aime bien de genre de facilité. Mais cela impose de coder tres proprement (pas comme mon exemple )

Beh tu vois, je viens de récupérer un script qui me sera assez utile. 'Fin, le jour où j'aurai pigé ce qu'il fait : 1777 lignes de code dont 11 de commentaires La maintenabilité du code, y connaissent pas...

Merci pour l'attention

[Philou67]

Bonjour,

je peux soit prendre une séquence, lui faire un split et obtenir ainsi un tableau où chaque élément est une base et une seule et puis itérer sur chaque élément dans une boucle; soit utiliser une boucle for et l'instruction substr pour parcourir la chaîne de caractères position par position. Dans ce dernier cas, les différents signes de la chaîne sont stockés dans une liste.

La question (je n'arrive pas vraiment à prendre de recul pour l'instant) est : est-ce qu'une façon de faire telle la 2e explicitée ci-dessus est plus rapide que la 1re?

La question de l'optimisation ne devrait se poser que dans le cas où il y a un problème de performance. Dans tous les autres cas, il convient d'abord de travailler la lisibilité et la maintenabilité.
En conséquence, et surtout pour un script de "faisabilité", je n'hésiterais pas une seule seconde sur l'usage des tableaux (voire des tableaux associatifs => hash).

Il m'apparait nettement plus "lisible" d'écrire :

foreach my $code (split /\s/, $ADN)
{
    # traiter $code
}

que d'écrire:

for (my $index = 0 ; $index != length($ADN) -1; $index++)
{
    my $code = substr($ADC, $index, 1);

    # traiter $code
}

Dans le deuxième cas, on se pose des questions sur "comment" extraire correctement les séquences d'ADN (gérer l'index et la fin de la boucle), dans le premier cas, on se concentre sur l'objet du script : traiter le code d'ADN.

C'est un point de vue développé dans "perl best practices" : les outils du langage sont avant tout là pour permettre de se concentrer sur l'essentiel, à savoir l'application, et pas les mécaniques algorithmiques.

* parlant de split : j'ai une erreur à la compilation si j'utilise la synthaxe suivante :

@adn = split (/''/, $adn);

mais pas si j'enlève les / Or, j'ai vu partout sur des sites de docs et tout qu'il faut les / ... Est-ce encore un souci de l'interface chaise-machine comme d'habitude?

Le split " " a une signification particulière, différente de split /\s/. C'est un faux ami.

As a special case, specifying a PATTERN of space (' ') will split on white space just as "split" with no arguments does. Thus, "split(' ')" can be used to emulate awk's default behavior, whereas "split(/ /)" will give you as many null initial fields as there are leading spaces. A "split" on "/\s+/" is like a "split(' ')" except that any leading whitespace produces a null first field. A "split" with no arguments really does a "split(' ', $_)" internally.

* je ne sais pas ce que vous en pensez, mais... j'ai quand même du mal avec le fait que ni l'initialisation des variables est obligatoire, ni la déclaration du type de la variable

Si tu es gênée par ça, utiliser systématiquement :
- use warnings (ce qui, entre autre, va t'obliger à définir tes variables avant de les utiliser (sauf à tester si elle est définir ou non))
- use strict (ce qui, entre autre, va t'obliger à pré-déclarer la portée de tes variables (my, our, local), donc à les déclarer tout cours).
Sinon, en perl, le typage est faible :
- $ pour les variables scalaires
- @ pour les variables tableaux
- % pour les variables tableaux associatifs (ou tables de hachage)

[A voir en vidéo sur Futura]

[MaliciaR]

La question de l'optimisation ne devrait se poser que dans le cas où il y a un problème de performance. Dans tous les autres cas, il convient d'abord de travailler la lisibilité et la maintenabilité.

Mais vois-tu, je suis une fausse informaticienne : je pose les choses d'abord en pseudocode sur une feuille et je fais le script après.

Dans le deuxième cas, on se pose des questions sur "comment" extraire correctement les séquences d'ADN (gérer l'index et la fin de la boucle), dans le premier cas, on se concentre sur l'objet du script : traiter le code d'ADN.

Oui, je vois bien ce que tu veux dire.
En fait, je me posais la question parce que dans ce que je fais, ça va comme suit :
* j'ai une scalaire contenant une chaîne de caractères;
* vu que la séquence est sous forme de plusieurs lignes, je la transforme en une seule ligne (il me le faut pour une recherche de motifs après );
* je veux savoir combien j'ai des signes de type 'a', de type 'c', etc. : donc, je crée un tableau ayant pour éléments les carctères de ma chaîne;
* je compte;
* je fais ma recherche de motifs.
Mais le truc est que je garde ma scalaire contenant la séquence et j'ai un tableau qui la contient pour le comptage. Ca marche nickel si j'ai une séquence pas super longue. Mais dans les fichiers que je dois exploiter... il y en a des masses. J'avais essayé de la faire directement en tant que tableau dès le départ, mais il ne compile pas...
Je vais utiliser les hachages, je pense.

Le split " " a une signification particulière, différente de split /\s/. C'est un faux ami.

Merci, je vois mieux.

Si tu es gênée par ça, utiliser systématiquement :
- use warnings (ce qui, entre autre, va t'obliger à définir tes variables avant de les utiliser (sauf à tester si elle est définir ou non))
- use strict (ce qui, entre autre, va t'obliger à pré-déclarer la portée de tes variables (my, our, local), donc à les déclarer tout cours).
Sinon, en perl, le typage est faible :
- $ pour les variables scalaires
- @ pour les variables tableaux
- % pour les variables tableaux associatifs (ou tables de hachage)

C'est ce que je fais, oui. Mais je suis en train d'adopter la notation hongroise dans les noms pour être plus confortable

Merci pour tes remarques

[Philou67]

Mais vois-tu, je suis une fausse informaticienne : je pose les choses d'abord en pseudocode sur une feuille et je fais le script après.

Ma remarque s'applique donc d'autant plus

En fait, je me posais la question parce que dans ce que je fais, ça va comme suit :
* j'ai une scalaire contenant une chaîne de caractères;
* vu que la séquence est sous forme de plusieurs lignes, je la transforme en une seule ligne (il me le faut pour une recherche de motifs après );

Si tu as un scalaire unique avec des retours à la ligne, il est simplement possible de supprimer ces retours à la ligne à l'intérieur :

$ADN =~ s/\n//g;

* je veux savoir combien j'ai des signes de type 'a', de type 'c', etc. : donc, je crée un tableau ayant pour éléments les carctères de ma chaîne;
* je compte;

Dans ce cas, inutile de créer un tableau, ou de le parcourir avec substr, tu comptes simplement les a, et les c :

my ($code_a, $code_c);
($code_a) = $ADN =~ /a/;
($code_c) = $ADN =~ /c/;

* je fais ma recherche de motifs.
Mais le truc est que je garde ma scalaire contenant la séquence et j'ai un tableau qui la contient pour le comptage. Ca marche nickel si j'ai une séquence pas super longue. Mais dans les fichiers que je dois exploiter... il y en a des masses. J'avais essayé de la faire directement en tant que tableau dès le départ, mais il ne compile pas...
Je vais utiliser les hachages, je pense.

Je ne pense pas que les hashages ne t'apporte une aide particulière dans ce cas. Les tables de hashage permettent la chose suivante :
- une indexation de tableau "non numérique" (type base de donnée)
- la gestion de couples "clés - valeurs"
- la création de "pseudo-structures" dans lesquelles les clés sont les noms des champs, et les valeurs leurs valeurs
Oriente toi donc d'abord à essayer de faire fonctionner tes pattern sur ta chaine, plutôt qu'à trouver un moyen de stockage efficace. Selon les besoins de traitement que tu auras à réaliser sur ces données par la suite, la structuration de celles-ci t'apparaitra alors plus clairement, me semble-t-il.

C'est ce que je fais, oui. Mais je suis en train d'adopter la notation hongroise dans les noms pour être plus confortable

Je n'aime pas cette notation, surtout d'ailleurs en C, ou le typage est fort, et où l'ajout de ce préfixe de type est redondant avec le type en lui-même (et l'usage d'un IDE facilite grandement la recherche du type).
En perl, c'est d'autant plus inutile qu'une variable scalaire n'a pas de type particulier, hormis le fait d'être singulier. Ainsi, s'il tu l'initialises avec une chaine de caractère, et que cette chaine représente un nombre, il est possible de l'utiliser avec un opérateur arithmétique.

Je préfère grandement, que l'on soigne le nom de la variable/fonction, en utilisant une forme syntaxique issue du langage courant :
- get_ADN_sequence() : verb + [adjective] + noun (fonction)
- $ADN_pattern : [adjective] + noun (variable)
- @ADC_sequences : [adjective] + noun (variable, l'usage du pluriel est optionnel et dépend de l'usage général de la variable, à savoir singulier si traité un élément à la fois ou pluriel si traité globalement)
- $is_healthy : participle + adjective (boolean)
- ...
Cette convention est explicité également dans "Perl Best Practices" (je suis pas sur qu'elle porte un nom).