Discussion :

[Flodelarab]

Il existe deux divisions.

• La division entière. Ou division euclidienne.
• La division réelle.

7 divisé par 2 donne 3 dans le premier cas et 3.5 dans le second cas. (la division euclidienne donne 7 divisé par 2 égale 3 reste 1, pour être précis).

Par suite, il y a 3 sortes de langages de programmation:

• Les langages qui ont compris qu'il y avait un problème et qui ont explicitement deux opérateurs.
• Les langages typés qui font la division entière avec les entiers et la division réelle avec les nombres réels.
• Les langages qui n'ont rien compris et qui vous laisse dans la mouïse.

Tu peux être sûr que des tas de logiciels sont bugués car le programmeur croit faire une division alors qu'il fait l'autre.

Dans le second cas, celui des logiciels qui sélectionnent de façon implicite la division, il faut multiplier par 1.0 avant de diviser pour basculer dans les nombres à virgule, donc assortis de la division réelle. Sinon, il fait l'entière.
Comme awk est du genre à faire les choses implicitement, même si je ne me souviens plus de la division présente, il ne coûte rien de multiplier par 1,0.
D'ailleurs, awk est un sacré piège pour l'implicite entre le texte et les nombres. Je me suis déjà fait avoir plusieurs fois.

[Sve@r]

Tu peux être sûr que des tas de logiciels sont bugués car le programmeur croit faire une division alors qu'il fait l'autre.

J'ose espérer que la majorité des programmeurs (de ceux qui ont le niveau adéquat pour travailler sur des logiciels) connait ce souci d'une part et sait comment le langage qu'il utilise gère la division d'autre part. Sans compter les tests unitaires sur les fonctions qui permettent généralement de repérer ce genre d'erreur.

Comme awk est du genre à faire les choses implicitement, même si je ne me souviens plus de la division présente, il ne coûte rien de multiplier par 1,0.

En réalité sur ce point précis il fait les choses bien.

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
~$ awk 'BEGIN {n=7/2; print n}'
3,5
~$ awk 'BEGIN {n=int(7)/2; print n}'
3,5
~$ awk 'BEGIN {n=7/int(2); print n}'
3,5
~$ awk 'BEGIN {n=int(7)/int(2); print n}'
3,5

[Dorhub]

Merci beaucoup, mais je pense changer de stratégie est prendre la valeur la plus basse pour chaque groupe

[Dorhub]

il y a 3 sortes de langages de programmation:

• Les langages qui ont compris qu'il y avait un problème et qui ont explicitement deux opérateurs.
• Les langages typés qui font la division entière avec les entiers et la division réelle avec les nombres réels.
• Les langages qui n'ont rien compris et qui vous laisse dans la mouïse.

C'est vrai que ce n'est pas intuitif

[N_BaH]

tant que j'en suis à donner des solutions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#!/bin/bash
 
fGroups=groupes.txt
 
evalMoyN() {
    bc -l <<eof
define abs(digit){
    if (digit<0) return -digit;
    return digit
}
    abs($1-$2) < abs(${3:-0}-$2)
eof
}
 
#calcul des totaux
declare -ai nb
while read gr vl fr
do
    [[ $gr != '#'* && $gr != '' ]] && {
        vl=${vl//,/.}
        nb[$gr]+=1
        groups[$gr]=$(bc -l <<<"${groups[gr]:-0}+$vl")
    }
done <"$fGroups" 
 
# calcul des moyennes
for gr in ${!groups[@]}
do
    moyN[$gr]=$(bc -l <<< "scale=2;${groups[gr]}/${nb[gr]}")
done
 
#calcul de la valeur la plus proche de la moyenne
while read gr vl fr
do
    [[ $gr != '#'* && $gr != '' ]] && {
        vl=${vl//,/.}
 
        (( $(evalMoyN $vl ${moyN[gr]} ${k[gr]}) )) && {
            k[$gr]="$vl"
            K[$gr]="$gr $vl(/${moyN[gr]}) $fr"
        }
    }
done <"$fGroups"
 
#affichage des résultats
printf '%s\n' "${K[@]}"

[N_BaH]

tant que j'en suis à proposer des solutions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#!/bin/bash
 
fGroups=groupes.txt # tel que défini ici : https://www.developpez.net/forums/d2135755/systemes/linux/shell-commandes-gnu/extraire-moyenne-bash/#post11861435
 
evalMoyN() {
    bc -l <<eot
define abs(digit){
    if (digit<0) return -digit;
    return digit
}
    abs($1-$2) < abs(${3:-0}-$2)
eot
}
 
#calcul des totaux
declare -ai nb
while read gr vl fr
do
    [[ $gr != '#'* && $gr != '' ]] && {
        vl=${vl//,/.}
        nb[$gr]+=1
        groups[$gr]=$(bc -l <<<"${groups[gr]:-0}+$vl")
    }
done <"$fGroups" 
 
# calcul des moyennes
for gr in ${!groups[@]}
do
    moyN[$gr]=$(bc -l <<< "scale=2;${groups[gr]}/${nb[gr]}")
done
 
#calcul de la valeur la plus proche de la moyenne
while read gr vl fr
do
    [[ $gr != '#'* && $gr != '' ]] && {
        vl=${vl//,/.}
 
        (( $(evalMoyN $vl ${moyN[gr]} ${k[gr]}) )) && {
            k[$gr]="$vl"
            K[$gr]="$gr $vl(/${moyN[gr]}) $fr"
        }
    }
done <"$fGroups"
 
#affichage des résultats
printf '%s\n' "${K[@]}"

[disedorgue]

Le titre dit explicitement en bash et à ma connaissance bc n'est pas du bash

[Sve@r]

bc -l <<eof

EOF (End Of File) c'est pour un fichier. Moi je préconise "EOT" (End Of Text) et en majuscules plus des underscores pour que ça ressorte bien en évitant toute confusion possible => bc <<_EOT_

Le titre dit explicitement en bash et à ma connaissance bc n'est pas du bash

T'as raison

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#!/bin/bash
cherche() {
	awk -v g=$1 'BEGIN {n=0} {if ($1 != g) next; v[n]=$2; f[n]=$3; n++} END {m=0; for (i=0; i < n; i++) m+=v[i]; c=m; m/=n; for (i=0; i < n; i++) {d=v[i]-m; if (d<0) d=-d; if (d < c) {c=d; r=f[i]}}; print r}'
}
 
for g in "$@"; do
	grep "^[^#]" "fic" |cherche $g
done

Testé sur ce fichier (nommé "fic" chez-moi)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#Groupe Valeur Fruit
  1  8  Orange
  1  6,5  Banane
  1  6,2  Pomme 
  1  12  Abricot
  1  7  Mure 
 
  2  4  Pomme
  2  6  Banane
  2  6  Abricot
  2  3  Mure

Je l'ai remis car j'ai rectifié une petite erreur sur le fichier d'origine qui était écrit 1 6, 2 Pomme avec un espace à la con devant le "2" (ou alors ce n'est pas une erreur et le script doit "en plus" la détecter et la corriger...)

Résultat

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
~$ ./x.sh 1
Orange
~$ ./x.sh 2
Pomme

[N_BaH]

@Sve@r
ah, non ! pas grep |awk !
EOF -> EOT : modifié.

@diesdorgue
bc : j'avais prévenu que ce que ne peut pas faire bash sans tortures est une transgression acceptable.
mais, dura lex sed lex, je dois pouvoir adapter ce que j'ai fait pour la valeur la plus basse.

[Sve@r]

@Sve@r
ah, non ! pas grep |awk !

Ce n'est pas tout à fait grep |awk, c'est grep |une_fonction. Et si on respecte le principe d'opacité des fonctions, on n'est pas censé savoir qu la fonction fait un "awk" (d'ailleurs ça peut changer demain).
En fait j'ai voulu écrire la fonction comme pouvant traiter n'importe quel flux en provenance de stdin pour plus de souplesse (ainsi elle ne se restreint pas à un fichier mais à n'importe quoi en input). D'ailleurs ma première version de la boucle était cat "fic" |cherche $g et ça fonctionne puisque le awk ne cherche que les lignes contenant le groupe demandé.
Puis je me suis dit que pour ce cas précis, si le flux entrant était déjà nettoyé au préalable des lignes en commentaire ce serait un plus.

EOF -> EOT : modifié.

Ah, ça c'est gentil

[N_BaH]

Ce n'est pas tout à fait grep |awk, c'est grep |une_fonction.

et allez ! de la mauvaise par-dessus.

[...]ma première version de la boucle était cat "fic" |cherche $g

ça t'apprendra peut-être à soutenir les intégristes de bash :

Le titre dit explicitement en bash et à ma connaissance bc n'est pas du bash

T'as raison

Et si on respecte le principe d'opacité des fonctions

`connais pas.

[Sve@r]

`connais pas.

C'est ce qu'on nomme "boite noire" (toutefois c'est plutôt appliqué en POO). On te donne un objet, on te dit "il prend X en entrée et donne Y en sortie" et tu n'as pas besoin d'en savoir plus ni comment c'est codé en interne, et surtout pas y fourrer ton nez. Ainsi le concepteur de l'objet a toute latitude pour le faire évoluer comme il le sent en fonction des avancées technologiques sans avoir à te rendre des comptes ; tant qu'il respecte ses obligations d'accepter X en entrée et donner Y en sortie.

Ensuite de ton côté, ne sachant pas comment le truc fonctionne, tu peux être tenté de vouloir l'aider en lui fournissant juste ce dont tu penses qu'il aura besoin, d'où le grep. Remarque dans ce cas, un grep "^ $g " "fic" était encore plus efficace. Mais bon, j'ai fait ça à la "va vite" (déjà rien que mes noms de variables dans le awk...) dans l'humour, parce que disedorgue demandait un bash pur, j'ai trouvé marrant de le lui mettre un awk (et j'ai même envisagé Python)

[N_BaH]

ah, oui. je connais le concept de "boîte noire", mais ça ne me serait pas venu à l'idée de l'appliquer ici, parce que je vois très bien ce qu'il y a à l'intérieur.

[Flodelarab]

Je suis complètement en ligne derrière N_BaH. J'ai eu la même réaction. Sve@r, tu recrées de façon alambiquée la séparation entre le filtre (grep) et l'action (awk), alors que awk sait faire les deux.

Quant à la boîte noire, les scripts shell sont tout, sauf ça. On n'est plutôt dans un grand terrain vague. Les variables ne sont pas locales. si j'appelle var=toto ./monscript.bash et si monscript.bash appelle lui-même ./fils.bash, alors fils.bash peut utiliser la variable $var qui n'est définie nulle-part dans les scripts (père ou fils). D'autre part, si tu fais de la récursivité, tu vas avoir des problèmes si tu présupposes les variables indépendantes pour chaque occurrence de la fonction.

[Sve@r]

J'ai eu la même réaction. Sve@r, tu recrées de façon alambiquée la séparation entre le filtre (grep) et l'action (awk), alors que awk sait faire les deux.

Comme je l'ai dit, le grep reste facultatif (ça fonctionne aussi sans mais comme le disait quelqu'un, si cela va sans dire, cela va encore mieux en le disant ) et surtout c'était un code humoristique. Personnellement j'essaye toujours d'éviter awk qui est assez consommateur (mais ce n'est pas pour ça que je me l'interdis, s'il le faut, il le faut). Et encore plus personnellement, ça fait longtemps que je ne fais plus de bash car mon travail m'a orienté vers d'autres technos (Python/PyQt/Postgres). J'en fais encore bien entendu, mais à un niveau très basique. Par exemple si j'avais eu ce travail à faire, jamais je ne l'aurais fait en bash (Python me semble plus adéquat) et s'il faut vraiment le faire en shell, je n'hésiterais pas à utiliser les outils disponibles dans le monde Linux (grep, cut, etc).

D'autre part, si tu fais de la récursivité, tu vas avoir des problèmes si tu présupposes les variables indépendantes pour chaque occurrence de la fonction.

Je connais cette subtilité (j'ai effectivement tenté la récursivité et rapidement compris le souci)

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
fct1() {
	(
		... (toute variable définie ici est indépendante)...
	)
}
 
fct2() {
	local x=1
	local y=2
	local z=3
	...
}

[disedorgue]

ça t'apprendra peut-être à soutenir les intégristes de bash :

Et c'est moi l'intégriste : https://www.developpez.net/forums/d2.../#post11866063




En plus dans la vraie vie, je fais du python/sql/perl mais pas de shell...

[papajoker]

Les "intégristes" awk peuvent aussi s'amuser…
https://github.com/patsie75/awk-demo

[N_BaH]

deuxième service !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#!/bin/bash
 
fGroups=groupes.txt
abs() {
 
    echo $(($1<0?-$1:$1))
}
rendreEntier() {
        local n=$1 sep=${n//[0-9]/}
        test -z "${sep:=,}" && n="$n,0"
        case $sep in
        .) LC_NUMERIC=C printf -v n '%0.3f' $n;;
        ,) printf -v n '%0.3f' $n;;
        esac
        echo ${n//$sep}
}
evalMoyN() {
    echo $(( $(abs $(($1-$2))) < $(abs $(($3-$2))) ))
}
 
#calcul des totaux
declare -ai nb groups
while read gr vl fr
do
    [[ $gr != '#'* && $gr != '' ]] && {
        vl=${vl//,/.}
        nb[$gr]+=1
        groups[$gr]+=$(rendreEntier $vl)
    }
done <"$fGroups" 
 
#calcul des moyennes
for gr in ${!groups[@]}
do
    moyN[$gr]=$(( ${groups[gr]}/${nb[gr]} ))
done
 
#calcul de la valeur la plus proche de la moyenne
while read gr vl fr
do
    [[ $gr != '#'* && $gr != '' ]] && {
        vl=${vl//,/.}
        (( $(evalMoyN $(rendreEntier $vl) ${moyN[gr]} $(rendreEntier ${k[gr]:-0})) )) && {
            k[$gr]="$vl"
            K[$gr]="$gr $vl(/${moyN[gr]:: -3},${moyN[gr]: -3}) $fr"
        }
    }
done <"$fGroups"
 
#affichage des résultats
printf '%s\n' "${K[@]}"

edit : déplacement de local sep dans rendreEntier()

[disedorgue]

Sans être intégriste je trouve ça beau


A quoi sert le local sep dans la fonction evalMoyN

[Sve@r]

A quoi sert le local sep dans la fonction evalMoyN

A créer une variable "sep" locale à la fonction
Nan, je déconne, moi aussi cette ligne m'a surpris mais je pense que c'est une erreur de copier/coller. En revanche je ne pige pas pourquoi cette autre variable "sep" n'est pas mise en local dans la fonction "rendreEntier".