selectionner les lignes d'un fichier contenant des maximums
33 réponses
geo cherchetout
Bonjour,
J'ai un fichier texte dont chaque ligne contient, après un premier
nombre et une espace, un second nombre compris entre 0 et 1. En voici un
extrait :
Ce second nombre représentant lui-même des échantillons d'une onde
sonore de composition spectrale très pauvre, passe toutes les 50 à 200
lignes par un vrai maximum comme celui de la ligne 6. Deux maximums
successifs sont séparés par un minimum dont la valeur est au moins 10
fois plus faible, ce qui permet de les distinguer de quelques faux
maximums comme celui de la ligne 4.
Je voudrais écrire un script dont l'exécution réduise ce fichier aux
seules lignes contenant ces vrais maximums. Quelles commandes ou quel
langage de programmation, et donc quelles pages de manuel me conseillez
vous, sachant que mes connaissances sont des plus modestes ?
Merci d'avance.
Cette fois-ci, la perfection est atteinte ! (En supprimant le premier "", sans doute une bavure.)
geo cherchetout
Le 26.11.2004 21:11, *Pascal Bourguignon* a écrit fort à propos :
Ceci dit, on peut aussi bien détecter la fréquence en travaillant sur le passage à zéro que sur les crêtes.
Bien sûr, mais ce qui m'intéresse est la durée entre deux crêtes successives. Vu à la loupe, ce n'est pas la même chose que celle entre deux passages par zéro, parce que je ne dispose pas de plusieurs périodes pour chaque instant significatif, mais tantôt d'une période, tantôt d'une demie période seulement, selon que je suis en présence d'un 1 ou d'un 0. Je pourrais obtenir la dérivée du signal par un moyen électrique simple et mesurer ensuite les intervalles entre les passages par zéro du signal obtenu, mais je perdrais en amplitude et il me faudrait ensuite amplifier.
Pourquoi pas un script calculant la pente entre chaque paire d'échantillons consécutifs ? Il n'y aurait plus ensuite qu'à rechercher parmi les résultats les zônes suffisamment proches de zéro. Je pense que ce ne serait pas mieux que ce qui est déjà fait, parce qu'il faudrait encore distinguer les vrais zéros des faux.
Même mieux, je dirais, puisque les petits prasites influence moins les passages à zéro que les crêtes. Pour cela, il aurait fallu ne pas redresser le signal!
Bof, les échantillons sont ce qu'ils sont. Qu'ils se trouvent d'un côté ou de l'autre de l'axe ne devrait pas changer grand-chose au traitement informatique. Évidemment, s'il s'agissait d'un signal analogique... Merci quand-même pour tes remarques, et pardon à ceux que le sujet n'intéresse pas.
Le 26.11.2004 21:11, *Pascal Bourguignon* a écrit fort à propos :
Ceci dit, on peut aussi bien détecter la fréquence en travaillant sur
le passage à zéro que sur les crêtes.
Bien sûr, mais ce qui m'intéresse est la durée entre deux crêtes
successives. Vu à la loupe, ce n'est pas la même chose que celle entre
deux passages par zéro, parce que je ne dispose pas de plusieurs
périodes pour chaque instant significatif, mais tantôt d'une période,
tantôt d'une demie période seulement, selon que je suis en présence d'un
1 ou d'un 0.
Je pourrais obtenir la dérivée du signal par un moyen électrique simple
et mesurer ensuite les intervalles entre les passages par zéro du signal
obtenu, mais je perdrais en amplitude et il me faudrait ensuite amplifier.
Pourquoi pas un script calculant la pente entre chaque paire
d'échantillons consécutifs ? Il n'y aurait plus ensuite qu'à rechercher
parmi les résultats les zônes suffisamment proches de zéro. Je pense que
ce ne serait pas mieux que ce qui est déjà fait, parce qu'il faudrait
encore distinguer les vrais zéros des faux.
Même mieux, je dirais, puisque
les petits prasites influence moins les passages à zéro que les crêtes.
Pour cela, il aurait fallu ne pas redresser le signal!
Bof, les échantillons sont ce qu'ils sont. Qu'ils se trouvent d'un côté
ou de l'autre de l'axe ne devrait pas changer grand-chose au traitement
informatique. Évidemment, s'il s'agissait d'un signal analogique...
Merci quand-même pour tes remarques, et pardon à ceux que le sujet
n'intéresse pas.
Le 26.11.2004 21:11, *Pascal Bourguignon* a écrit fort à propos :
Ceci dit, on peut aussi bien détecter la fréquence en travaillant sur le passage à zéro que sur les crêtes.
Bien sûr, mais ce qui m'intéresse est la durée entre deux crêtes successives. Vu à la loupe, ce n'est pas la même chose que celle entre deux passages par zéro, parce que je ne dispose pas de plusieurs périodes pour chaque instant significatif, mais tantôt d'une période, tantôt d'une demie période seulement, selon que je suis en présence d'un 1 ou d'un 0. Je pourrais obtenir la dérivée du signal par un moyen électrique simple et mesurer ensuite les intervalles entre les passages par zéro du signal obtenu, mais je perdrais en amplitude et il me faudrait ensuite amplifier.
Pourquoi pas un script calculant la pente entre chaque paire d'échantillons consécutifs ? Il n'y aurait plus ensuite qu'à rechercher parmi les résultats les zônes suffisamment proches de zéro. Je pense que ce ne serait pas mieux que ce qui est déjà fait, parce qu'il faudrait encore distinguer les vrais zéros des faux.
Même mieux, je dirais, puisque les petits prasites influence moins les passages à zéro que les crêtes. Pour cela, il aurait fallu ne pas redresser le signal!
Bof, les échantillons sont ce qu'ils sont. Qu'ils se trouvent d'un côté ou de l'autre de l'axe ne devrait pas changer grand-chose au traitement informatique. Évidemment, s'il s'agissait d'un signal analogique... Merci quand-même pour tes remarques, et pardon à ceux que le sujet n'intéresse pas.
Emmanuel Florac
Le Sat, 27 Nov 2004 17:19:18 +0100, geo cherchetout a écrit :
Vaut-il mieux pour un débutant se familiariser en premier avec perl, qui me semble plus généraliste et moins hermétique, ou avec awk ?
Perl est quand même plus puissant, plus moderne et plus compréhensible. À moins de tenir à la compatibilité avec les OS des années 80, autant préférer Perl. Awk n'est plus guère qu'un outil "compatible", comme le bourne-shell, à mon sens.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Sat, 27 Nov 2004 17:19:18 +0100, geo cherchetout a écrit :
Vaut-il mieux pour un débutant se familiariser en premier avec perl, qui
me semble plus généraliste et moins hermétique, ou avec awk ?
Perl est quand même plus puissant, plus moderne et plus compréhensible.
À moins de tenir à la compatibilité avec les OS des années 80, autant
préférer Perl. Awk n'est plus guère qu'un outil "compatible", comme le
bourne-shell, à mon sens.
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
Le Sat, 27 Nov 2004 17:19:18 +0100, geo cherchetout a écrit :
Vaut-il mieux pour un débutant se familiariser en premier avec perl, qui me semble plus généraliste et moins hermétique, ou avec awk ?
Perl est quand même plus puissant, plus moderne et plus compréhensible. À moins de tenir à la compatibilité avec les OS des années 80, autant préférer Perl. Awk n'est plus guère qu'un outil "compatible", comme le bourne-shell, à mon sens.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Stephane Chazelas
2004-11-26, 22:24(+01), geo cherchetout:
Le 26.11.2004 19:08, *Stephane Chazelas* a écrit fort à propos :
Cette fois-ci, la perfection est atteinte ! (En supprimant le premier "", sans doute une bavure.)
Quel backslash.
Sous usenet, il est tres peu sage d'ecrire des des lignes de plus de 80 caractere car meme si son logiciel de lecture de news permet d'ecrire (et de diffuser) des lignes aussi longues, il est tres probable que les lecteurs de news des autres personnes coupent ces lignes. C'est pour ca que, dans la mesure du possible, il est preferable de couper ses longues lignes de code de sorte qu'elles soient valides (plutot que de laisser un lecteur de news la couper a un endroit ou ce n'est plus valide).
Il y a trois lignes de codes. A la fois le shell et awk sont censés reconnaitre ce "" en fin de ligne comme un moyen d'exprimer une ligne logique faite de deux lignes physiques. Cela dit,
Cette fois-ci, la perfection est atteinte ! (En supprimant le premier
"", sans doute une bavure.)
Quel backslash.
Sous usenet, il est tres peu sage d'ecrire des des lignes de
plus de 80 caractere car meme si son logiciel de lecture de news
permet d'ecrire (et de diffuser) des lignes aussi longues, il
est tres probable que les lecteurs de news des autres personnes
coupent ces lignes. C'est pour ca que, dans la mesure du
possible, il est preferable de couper ses longues lignes de code
de sorte qu'elles soient valides (plutot que de laisser un
lecteur de news la couper a un endroit ou ce n'est plus valide).
Il y a trois lignes de codes. A la fois le shell et awk sont
censés reconnaitre ce "" en fin de ligne comme un moyen
d'exprimer une ligne logique faite de deux lignes physiques.
Cela dit,
Cette fois-ci, la perfection est atteinte ! (En supprimant le premier "", sans doute une bavure.)
Quel backslash.
Sous usenet, il est tres peu sage d'ecrire des des lignes de plus de 80 caractere car meme si son logiciel de lecture de news permet d'ecrire (et de diffuser) des lignes aussi longues, il est tres probable que les lecteurs de news des autres personnes coupent ces lignes. C'est pour ca que, dans la mesure du possible, il est preferable de couper ses longues lignes de code de sorte qu'elles soient valides (plutot que de laisser un lecteur de news la couper a un endroit ou ce n'est plus valide).
Il y a trois lignes de codes. A la fois le shell et awk sont censés reconnaitre ce "" en fin de ligne comme un moyen d'exprimer une ligne logique faite de deux lignes physiques. Cela dit,
serait peut-etre plus portable, je ne suis pas sur que tous les awk permettent de couper une ligne au milieu d'une "string".
-- Stephane
Stephane Chazelas
2004-11-27, 18:01(+01), Emmanuel Florac:
Le Sat, 27 Nov 2004 17:19:18 +0100, geo cherchetout a écrit :
Vaut-il mieux pour un débutant se familiariser en premier avec perl, qui me semble plus généraliste et moins hermétique, ou avec awk ?
Perl est quand même plus puissant, plus moderne et plus compréhensible.
Plus puissant, ca depend ce que tu entends par la.
Si tu parles d'efficacité, pour des programmes aussi simples que celui de ce thread, awk (a l'exception de gawk qui est vraiment tres lent) est en general plus rapide que perl.
Plus moderne, je ne crois pas qu'on puisse faire ce genre de comparaison dans la mesure ou perl et awk sont deux outils quand meme tres different. awk est un outil de traitement de texte en colonnes, perl est un language de programmation (je ne parle pas de gawk qui part un peu n'importe ou).
Pour ce qui est de "compréhensible", la, je ne suis carrement pas d'accord (et pourtant j'apprecie et utilise perl). awk est quand meme tout ce qu'on fait de plus limpide, perl n'est pas vraiment reputé pour etre limpide.
À moins de tenir à la compatibilité avec les OS des années 80, autant préférer Perl. Awk n'est plus guère qu'un outil "compatible", comme le bourne-shell, à mon sens.
D'accord et pas d'accord.
D'accord pour utiliser perl au lieu de faire des scripts shells, on y gagne sur pratiquement tous les tableaux.
Mais dans un script shell, perl est parfaitement adapté.
Pour le probleme de "geo cherchetout", awk est *l*'outil qui s'impose si on ne connait pas perl. La page de man de awk (pas celle de gawk) est courte et limpide et on peut faire quelque chose avec en moins d'une heure.
Je suis d'accord pour dire que peut valoir le coup d'apprendre perl (si on est amené souvent a avoir a resoudre rapidement ce genre de problemes), mais c'est une tache d'une toute autre envergure que de lire la page de man de awk.
-- Stephane
2004-11-27, 18:01(+01), Emmanuel Florac:
Le Sat, 27 Nov 2004 17:19:18 +0100, geo cherchetout a écrit :
Vaut-il mieux pour un débutant se familiariser en premier avec perl, qui
me semble plus généraliste et moins hermétique, ou avec awk ?
Perl est quand même plus puissant, plus moderne et plus compréhensible.
Plus puissant, ca depend ce que tu entends par la.
Si tu parles d'efficacité, pour des programmes aussi simples que
celui de ce thread, awk (a l'exception de gawk qui est vraiment
tres lent) est en general plus rapide que perl.
Plus moderne, je ne crois pas qu'on puisse faire ce genre de
comparaison dans la mesure ou perl et awk sont deux outils quand
meme tres different. awk est un outil de traitement de texte en
colonnes, perl est un language de programmation (je ne parle pas
de gawk qui part un peu n'importe ou).
Pour ce qui est de "compréhensible", la, je ne suis carrement
pas d'accord (et pourtant j'apprecie et utilise perl). awk est
quand meme tout ce qu'on fait de plus limpide, perl n'est pas
vraiment reputé pour etre limpide.
À moins de tenir à la compatibilité avec les OS des années 80, autant
préférer Perl. Awk n'est plus guère qu'un outil "compatible", comme le
bourne-shell, à mon sens.
D'accord et pas d'accord.
D'accord pour utiliser perl au lieu de faire des scripts shells,
on y gagne sur pratiquement tous les tableaux.
Mais dans un script shell, perl est parfaitement adapté.
Pour le probleme de "geo cherchetout", awk est *l*'outil qui
s'impose si on ne connait pas perl. La page de man de awk (pas
celle de gawk) est courte et limpide et on peut faire quelque
chose avec en moins d'une heure.
Je suis d'accord pour dire que peut valoir le coup d'apprendre
perl (si on est amené souvent a avoir a resoudre rapidement ce
genre de problemes), mais c'est une tache d'une toute autre
envergure que de lire la page de man de awk.
Le Sat, 27 Nov 2004 17:19:18 +0100, geo cherchetout a écrit :
Vaut-il mieux pour un débutant se familiariser en premier avec perl, qui me semble plus généraliste et moins hermétique, ou avec awk ?
Perl est quand même plus puissant, plus moderne et plus compréhensible.
Plus puissant, ca depend ce que tu entends par la.
Si tu parles d'efficacité, pour des programmes aussi simples que celui de ce thread, awk (a l'exception de gawk qui est vraiment tres lent) est en general plus rapide que perl.
Plus moderne, je ne crois pas qu'on puisse faire ce genre de comparaison dans la mesure ou perl et awk sont deux outils quand meme tres different. awk est un outil de traitement de texte en colonnes, perl est un language de programmation (je ne parle pas de gawk qui part un peu n'importe ou).
Pour ce qui est de "compréhensible", la, je ne suis carrement pas d'accord (et pourtant j'apprecie et utilise perl). awk est quand meme tout ce qu'on fait de plus limpide, perl n'est pas vraiment reputé pour etre limpide.
À moins de tenir à la compatibilité avec les OS des années 80, autant préférer Perl. Awk n'est plus guère qu'un outil "compatible", comme le bourne-shell, à mon sens.
D'accord et pas d'accord.
D'accord pour utiliser perl au lieu de faire des scripts shells, on y gagne sur pratiquement tous les tableaux.
Mais dans un script shell, perl est parfaitement adapté.
Pour le probleme de "geo cherchetout", awk est *l*'outil qui s'impose si on ne connait pas perl. La page de man de awk (pas celle de gawk) est courte et limpide et on peut faire quelque chose avec en moins d'une heure.
Je suis d'accord pour dire que peut valoir le coup d'apprendre perl (si on est amené souvent a avoir a resoudre rapidement ce genre de problemes), mais c'est une tache d'une toute autre envergure que de lire la page de man de awk.
-- Stephane
Emmanuel Florac
Le Sun, 28 Nov 2004 12:42:18 +0000, Stephane Chazelas a écrit :
Plus puissant, ca depend ce que tu entends par la.
Si tu parles d'efficacité, pour des programmes aussi simples que celui de ce thread, awk (a l'exception de gawk qui est vraiment tres lent) est en general plus rapide que perl.
Le seul point saillant que je note c'est que tu parles toujours de awk et que tu comptes gawk pour rien :) Or justement comme la plupart de gens je crois, ça fait plusieurs années que je n'utilise quasiment plus que du Linux, donc gawk... :)
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Sun, 28 Nov 2004 12:42:18 +0000, Stephane Chazelas a écrit :
Plus puissant, ca depend ce que tu entends par la.
Si tu parles d'efficacité, pour des programmes aussi simples que
celui de ce thread, awk (a l'exception de gawk qui est vraiment
tres lent) est en general plus rapide que perl.
Le seul point saillant que je note c'est que tu parles toujours de awk et
que tu comptes gawk pour rien :) Or justement comme la plupart de gens je
crois, ça fait plusieurs années que je n'utilise quasiment plus que du
Linux, donc gawk... :)
--
Il y a toujours un bug de plus.
Loi de Lubarsky.
Le Sun, 28 Nov 2004 12:42:18 +0000, Stephane Chazelas a écrit :
Plus puissant, ca depend ce que tu entends par la.
Si tu parles d'efficacité, pour des programmes aussi simples que celui de ce thread, awk (a l'exception de gawk qui est vraiment tres lent) est en general plus rapide que perl.
Le seul point saillant que je note c'est que tu parles toujours de awk et que tu comptes gawk pour rien :) Or justement comme la plupart de gens je crois, ça fait plusieurs années que je n'utilise quasiment plus que du Linux, donc gawk... :)
-- Il y a toujours un bug de plus. Loi de Lubarsky.
drkm
Stephane Chazelas writes:
Je suis d'accord pour dire que peut valoir le coup d'apprendre perl (si on est amené souvent a avoir a resoudre rapidement ce genre de problemes), mais c'est une tache d'une toute autre envergure que de lire la page de man de awk.
Et pour une introduction un peu plus détaillée, que conseilles-tu ? Le livre de Kernighan et Weinberger ? Le « sed et awk » de chez O'Reilly ?
Et puisque les différences de gawk avec AWK ont été évoquées, quelles sont-elles, principalement ?
Je suis d'accord pour dire que peut valoir le coup d'apprendre
perl (si on est amené souvent a avoir a resoudre rapidement ce
genre de problemes), mais c'est une tache d'une toute autre
envergure que de lire la page de man de awk.
Et pour une introduction un peu plus détaillée, que conseilles-tu ?
Le livre de Kernighan et Weinberger ? Le « sed et awk » de chez
O'Reilly ?
Et puisque les différences de gawk avec AWK ont été évoquées,
quelles sont-elles, principalement ?
Je suis d'accord pour dire que peut valoir le coup d'apprendre perl (si on est amené souvent a avoir a resoudre rapidement ce genre de problemes), mais c'est une tache d'une toute autre envergure que de lire la page de man de awk.
Et pour une introduction un peu plus détaillée, que conseilles-tu ? Le livre de Kernighan et Weinberger ? Le « sed et awk » de chez O'Reilly ?
Et puisque les différences de gawk avec AWK ont été évoquées, quelles sont-elles, principalement ?
--drkm
Nicolas George
Emmanuel Florac wrote in message :
Le seul point saillant que je note c'est que tu parles toujours de awk et que tu comptes gawk pour rien :) Or justement comme la plupart de gens je crois, ça fait plusieurs années que je n'utilise quasiment plus que du Linux, donc gawk... :)
Note que même sous Linux, gawk est loin d'être universel : certaines distributions préfèrent mawk, Debian par exemple.
Emmanuel Florac wrote in message
<pan.2004.11.28.14.11.48.724971@imaginet.fr>:
Le seul point saillant que je note c'est que tu parles toujours de awk et
que tu comptes gawk pour rien :) Or justement comme la plupart de gens je
crois, ça fait plusieurs années que je n'utilise quasiment plus que du
Linux, donc gawk... :)
Note que même sous Linux, gawk est loin d'être universel : certaines
distributions préfèrent mawk, Debian par exemple.
Le seul point saillant que je note c'est que tu parles toujours de awk et que tu comptes gawk pour rien :) Or justement comme la plupart de gens je crois, ça fait plusieurs années que je n'utilise quasiment plus que du Linux, donc gawk... :)
Note que même sous Linux, gawk est loin d'être universel : certaines distributions préfèrent mawk, Debian par exemple.
geo cherchetout
Le 28.11.2004 13:32, *Stephane Chazelas* a écrit fort à propos :
OK ! Quel nigaud je suis, moi qui me suis évertué à rassembler en une seule la deuxième et la troisième. Merci pour ce petit rappel.
geo cherchetout
Le 28.11.2004 13:42, *Stephane Chazelas* a écrit fort à propos :
Pour le probleme de "geo cherchetout", awk est *l*'outil qui s'impose si on ne connait pas perl. La page de man de awk (pas celle de gawk) est courte et limpide et on peut faire quelque chose avec en moins d'une heure.
Awk et son manuel ne semblent pas être des produits libres ? (J'ai trouvé une traduction en français du manuel de gawk et quelques sites didactiques. Cela me suffira, avec un petit coup de main des contributeurs de ce groupe, à l'occasion, car il n'est pas envisageable pour moi de devenir un expert.)
Je suis d'accord pour dire que peut valoir le coup d'apprendre perl (si on est amené souvent a avoir a resoudre rapidement ce genre de problemes), mais c'est une tache d'une toute autre envergure que de lire la page de man de awk.
Bon, me voilà prévenu. Merci encore.
Le 28.11.2004 13:42, *Stephane Chazelas* a écrit fort à propos :
Pour le probleme de "geo cherchetout", awk est *l*'outil qui
s'impose si on ne connait pas perl. La page de man de awk (pas
celle de gawk) est courte et limpide et on peut faire quelque
chose avec en moins d'une heure.
Awk et son manuel ne semblent pas être des produits libres ?
(J'ai trouvé une traduction en français du manuel de gawk et quelques
sites didactiques. Cela me suffira, avec un petit coup de main des
contributeurs de ce groupe, à l'occasion, car il n'est pas envisageable
pour moi de devenir un expert.)
Je suis d'accord pour dire que peut valoir le coup d'apprendre
perl (si on est amené souvent a avoir a resoudre rapidement ce
genre de problemes), mais c'est une tache d'une toute autre
envergure que de lire la page de man de awk.
Le 28.11.2004 13:42, *Stephane Chazelas* a écrit fort à propos :
Pour le probleme de "geo cherchetout", awk est *l*'outil qui s'impose si on ne connait pas perl. La page de man de awk (pas celle de gawk) est courte et limpide et on peut faire quelque chose avec en moins d'une heure.
Awk et son manuel ne semblent pas être des produits libres ? (J'ai trouvé une traduction en français du manuel de gawk et quelques sites didactiques. Cela me suffira, avec un petit coup de main des contributeurs de ce groupe, à l'occasion, car il n'est pas envisageable pour moi de devenir un expert.)
Je suis d'accord pour dire que peut valoir le coup d'apprendre perl (si on est amené souvent a avoir a resoudre rapidement ce genre de problemes), mais c'est une tache d'une toute autre envergure que de lire la page de man de awk.
