(résolu)tri des valeurs après plusieurs "for in ... do.. done"

cristobal78 · Le 13/10/2020, à 18:14

bonjours à tous et surtout aux codeurs malins du forum

je cherche à modifier ce script afin d'obtenir les fréquences des sommes obtenues en additionnant 3 nombres de 1 à 6.
Au départ il s'agit d'un constat qui surprenait Cosme II, grand Duc de Toscane, et qui en parla à Galilée au tout début du 17 ème siècle.

Il jetait 3 dés à 6 faces numérotées de 1 à 6 et il était sur d'avoir constaté que somme 10 apparaissait plus souvent que la somme 9, ce qui surprenait le grand Duc qui s'attendait (par symétrie ?) à avoir la même fréquence pour la somme 9 et la somme 10.
Galilée sans Ubuntu et sans script lui trouva l'explication sur la base de la fréquence d'apparition des sommes.

Pour comprendre la solution de Galilée j'ai écrit ce script que voici :

#!/bin/bash
for de1 in 1 2 3 4 5 6
	do 
	for de2 in 1 2 3 4 5 6
		do 
		for de3 in 1 2 3 4 5 6
			do
			echo "$de1 + $de2 + $de3 = $(($de1+$de2+$de3))"
		done
	done
done

On obtient bien la liste de toutes les sommes possibles (liste de 216 lignes car 6x6x6=216) mais pour trouver la fréquence de chaque somme c'est la galère, même si avec un peu de temps on voit que 9 apparait 25 fois et que 10 apparait 27 fois.
Cosme avait donc un sacré coup d'oeil !

Ma question c'est comment modifier ce script pour lire le résultat sous cette forme (16 lignes seulement) :

fréq somme égale à 3 = 1
fréq somme égale à 4 = 3
...
fréq somme égale à 9 = 25
fréq somme égale à 10 = 27
...
fréq somme égale à 18 = 1

Dernière modification par cristobal78 (Le 15/11/2020, à 00:51)

pingouinux · Le 13/10/2020, à 18:38

Bonjour,
Par exemple (mais pas très joli…) :

#!/bin/bash
tot=( 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 )
for de1 in 1 2 3 4 5 6
        do 
        for de2 in 1 2 3 4 5 6
                do 
                for de3 in 1 2 3 4 5 6
                        do
                        s=$((de1+de2+de3))
                        tot[$s]=$(( ${tot[$s]} + 1 ))
                        echo "$de1 + $de2 + $de3 = $s"
                done
        done
done
for i in {3..18}; do echo $i ${tot[$i]}; done

Dernière modification par pingouinux (Le 13/10/2020, à 18:40)

Vobul · Le 13/10/2020, à 18:40

Salut,

Alors bon je l'ai fait en python parce que bon bash ça va un moment mais bof....

Au préablable:

pip install --user pandas

#!/usr/bin/env python
import itertools
import pandas as pd

dice1 = dice2 = dice3 = range(1, 7)
res = []
# roll the dices and make a sum of the results
for a in itertools.product(dice1, dice2, dice3):
    res.append(sum(a))

s = pd.Series(res)
print(s.value_counts(ascending=True))

Ce qui donne comme résultat :

Watael · Le 13/10/2020, à 20:28

$ declare -ai ar
$ numbers=( {1..6} )
$ for de1 in ${numbers[@]}; do for de2 in ${numbers[@]}; do for de3 in ${numbers[@]}; do ar[$de1+$de2+$de3]+=1; done; done; done 
$ for i in "${!ar[@]}"; do echo "${ar[$i]} $i"; done | sort -k1,1n -k2,2n -t ' '
1 3
1 18
3 4
3 17
6 5
6 16
10 6
10 15
15 7
15 14
21 8
21 13
25 9
25 12
27 10
27 11

parce que dégainer python pour ça
XD

Vobul · Le 13/10/2020, à 20:35

Watael a écrit :

parce que dégainer python pour ça
XD

Ça doit sûrement être parce que je suis fan du Colt Python

Vobul · Le 13/10/2020, à 23:53

Petit benchmark des familles avec un des dés à 300 faces :

Python : 9.72 secondes
Bash : 1 minute et des poussières

Et puis faire un plot est facile :

beuguissime · Le 13/10/2020, à 23:56

Surtout dégainer pandas pour ça ! Mais merci Vobul pour l'astuce avec itertools.

In [8]: import itertools                                                                                                                                                            

In [9]: import collections                                                                                                                                                          

In [10]: res = [sum(a) for a in itertools.product(dice1, dice2, dice3)]                                                                                                             

In [11]: collections.Counter(res)                                                                                                                                                   
Out[11]: 
Counter({3: 1,
         4: 3,
         5: 6,
         6: 10,
         7: 15,
         8: 21,
         9: 25,
         10: 27,
         11: 27,
         12: 25,
         13: 21,
         14: 15,
         15: 10,
         16: 6,
         17: 3,
         18: 1})

Y a bien une symétrie et les résultats les plus fréquents sont 10 et 11 à égalité. Je pense que Cosimo II a eu de la chance de tomber sur un tirage qui n'était pas biaisé car je doute qu'il ait reproduit l'expérience plusieurs centaines de fois pour s'affranchir du bruit statistique. Merci cristobal78 pour l'anecdote cependant

Dernière modification par beuguissime (Le 14/10/2020, à 00:02)

cristobal78 · Le 17/10/2020, à 01:14

Merci à tous

Je ne creuserai pas les solutions basées sur Python car je ne connais pas du tout ce langage. Mais merci tout de même d'avoir regardé mon petit problème.
Quant aux solutions bash elle me semblent basées sur la création d'un tableau.
Comme je n'en ai jamais utilisé je ne sais pas comment ça marche ni pourquoi on passe par un tableau.

J'ai cherché de la doc sur les variables de type tableau notamment sur la doc ubuntu mais je n'ai pas trouvé de tuto simple et clair sur le sujet.
J'ai ensuite essayé de comprendre en regardant dans l'Advanced bash scripting guide (ABS Guide) mais franchement je n'ai pas trouvé ça bien clair non plus. Ça ne répond pas simplement à la question : pourquoi un tableau, qu'est qu'un tableau apporte, etc...

Je vais donc continuer à creuser en m'appuyant sur le script de Pingouinux qui marche (je l'ai testé) et semble plus à ma portée que le code de Maitre Watael

Mais où trouve t on une approche pédagogique des tableaux sous Bash ? Je suis preneur !!!
Merci encore à tous.

Zakhar · Le 17/10/2020, à 09:33

cristobal78 a écrit :

Merci à tous
Je ne creuserai pas les solutions basées sur Python car je ne connais pas du tout ce langage. Mais merci tout de même d'avoir regardé mon petit problème.
Quant aux solutions bash elle me semblent basées sur la création d'un tableau.
Comme je n'en ai jamais utilisé je ne sais pas comment ça marche ni pourquoi on passe par un tableau.
(...)

Et tu as bien raison.

En plus s'il vous plaît, à moins que ce soit vraiment indispensable... évitez les "bashisms" : or les "tableaux" sont un pur bashism.

La bonne pratique est d'écrire du shell portable, et de spécifier /bin/sh et non pas /bin/bash.

Ca fait pas loin de 10 ans qu'Ubuntu est passé à Dash qui est bien plus performant que bash... mais ne gère pas les "bashisms" comme les tableaux !

Donc voici la solution en "philosophie GNU/Linux", c'est à dire en utilisant l'outillage à notre disposition.

Je l'ai rendue paramétrable en fonction du nombre de faces du dé.

#! /bin/sh

faces=6

for de1 in $(seq 1 $faces)
	do 
	for de2 in $(seq 1 $faces)
		do 
		for de3 in $(seq 1 $faces)
			do
			echo "$(($de1+$de2+$de3))"
		done
	done
done | sort -n | uniq -c

Notez bien #! /bin/sh à moins que vous vouliez un truc plus mou et lent, aucune raison de mettre #! /bin/bash

Aussi, bash est particulièrement inefficace pour les boucles (for, do). Pour faire plaisir à Vobul, j'ai changé faces pour mettre 300 et testé avec le programme ci-dessus et en remplaçant /bin/sh par /bin/bash, voici ce que ça donne sur mon PC:

$ /usr/bin/time -v ./test.sh  # Test avec /bin/sh ==> dash 300 faces
(...)
User time (seconds): 114.09
(...)
$ /usr/bin/time -v ./test.sh  # Test avec /bin/bash ==> bash 300 faces
(...)
User time (seconds): 233.30
(...)

CQFD : bash est plus de 2 fois plus lent !

Dernière modification par Zakhar (Le 17/10/2020, à 10:19)

Watael · Le 17/10/2020, à 10:03

heu...
avec le code que j'ai donné :

$ time ./monCode.bash
[...]

real    0m0,012s                                                                                                                                                                                                                                                                 
user    0m0,004s                                                                                                                                                                                                                                                                 
sys     0m0,009s

alors que

$ time ./tonCode.sh
[...]

real    0m0,098s                                                                                                                                                                                                                                                                 
user    0m0,060s                                                                                                                                                                                                                                                                 
sys     0m0,022s

Dernière modification par Watael (Le 17/10/2020, à 10:07)

Zakhar · Le 17/10/2020, à 10:04

Et pour Vobul, si on veut vraiment de la perf, c'est pas python qu'il faut, mais le bon vieux C :

#include <stdio.h>

#define FACES 300

static unsigned int total[3 * FACES];

int main()
{
	int de1, de2, de3, i;
	
	for (de1 = 1; de1 <= FACES; de1++)
		for (de2 = 1; de2 <= FACES; de2++)
			for (de3 = 1; de3 <= FACES; de3++)
				total[de1 + de2 + de3]++;
	for (i = 3; i <= 3 * FACES; i++)
		printf("%7d %d\n", total[i], i);

	return 0;
}

Le programme ci-dessus affiche exactement la même sortie de "uniq -c".

Compiler :

$ gcc test.c -o test

Run :

$ /usr/bin/time -v ./test
(...)
User time (seconds): 0.07
(...)

Python est enfoncé !

En plus, comme le shell s'inspire (de loin) de la syntaxe C, le programme en C n'est pas si loin de celui en shell "avec tableaux" !

Dernière modification par Zakhar (Le 17/10/2020, à 11:50)

Zakhar · Le 17/10/2020, à 10:05

Watael a écrit :

heu...
avec le code que j'ai donné :

$ time ./monCode.bash
[...]

real    0m0,012s                                                                                                                                                                                                                                                                 
user    0m0,004s                                                                                                                                                                                                                                                                 
sys     0m0,009s

Avec 300 faces

Si c'est le cas tu as combien de Qbits sur ta machine de guerre !

Tu as dû lire (trop) rapidement ma réponse. Il est vrai qu'avec 6 faces ce n'est pas significatif : trop rapide quel que soit le shell !

Dernière modification par Zakhar (Le 17/10/2020, à 10:07)

Watael · Le 17/10/2020, à 10:09

ton code indique

faces=6

si mon code est plus rapide (et de loin!) sur 6 faces, je n'imagine pas la différence sur 300 faces.

Zakhar · Le 17/10/2020, à 10:17

Watael a écrit :

ton code indique
faces=6
si mon code est plus rapide (et de loin!) sur 6 faces, je n'imagine pas la différence sur 300 faces.

Relis tout le post s'il te plaît !

Voici le test avec faces=6

$ /usr/bin/time -v ./test.sh  # Test avec /bin/sh ==> dash
(...)
User time (seconds): 0.01
(...)
$ /usr/bin/time -v ./test.sh  # Test avec /bin/bash ==> bash
(...)
User time (seconds): 0.04
(...)

Si on cherche la "rapidité", sans conteste le code le plus rapide est le code en C que j'ai posté (on peut sans doute faire mieux en assembleur !)

Pour la performance, il est certain que bash est plus lent que dash, fais le test toi-même sur une simple boucle à vide si tu ne me crois pas.
Or jouer avec des tableaux (ce que l'on fait en C !) implique d'utiliser bash... dans un programme avec des boucles où il est connu que bash n'est pas très fort par rapport à dash

Ensuite il faut considérer la "lisibilité/maintenance".
Je pense qu'utiliser les outils GNU est plus lisible/maintenable !

Après c'est certain que lancer sort et uniq, ça veut dire des accès disques (heureusement Linux fait ça bien) et sur un petit nombre de faces, tout calculer en mémoire pourrait être plus rapide, je te l'accorde volontiers !

@Wattael, j'ai mis en gras que le test plus haut était fait avec 300 faces, car c'était effectivement peu clair... et aussi indiqué ça dans le commentaire de la sortie !

Dernière modification par Zakhar (Le 17/10/2020, à 10:21)

Zakhar · Le 17/10/2020, à 10:40

Même chose en C avec le nombre de dés paramétrable :

#include <stdio.h>

#define FACES 6
#define DES 3

static unsigned int total[3 * FACES];

void lancer(int d, int t)
{
	int i;
	
	if (0 == d)
		total[t]++;
	else
		for (i = 1; i <=FACES; i++)
			lancer(d - 1, t + i);
}

int main()
{
	int i;
	
	lancer(DES, 0);
	for (i = 3; i <= 3 * FACES; i++)
		printf("%7d %d\n", total[i], i);
		
	return 0;
}

Tu peux faire à l'identique en shell avec une fonction, c'est aussi très élégant et le code est plus court et générique grâce à la récursion (mais pas forcément plus rapide !).

#!/bin/sh

faces=$(seq 1 6)
des=3


lancer()
{
	if [ $1 -eq 0 ]; then
		echo "$2"
	else
		for de in $faces; do
			lancer $(( $1 - 1 )) $(( $2 + $de ))
		done
	fi	
}

lancer $des 0 | sort -n | uniq -c

Dernière modification par Zakhar (Le 17/10/2020, à 11:09)

Watael · Le 17/10/2020, à 10:45

rien à faire :

time ./tonCode_300.dash
[...]

real    4m39,123s
user    3m35,578s
sys     2m36,578s

$ time ./monCode_300.bash
[...]

real    1m46,813s
user    1m46,695s
sys     0m0,013s

Zakhar · Le 17/10/2020, à 11:02

Tu as raison, {1..6} étant un bashism, je l'ai remplacé par la chose plus standard : $( seq 1 $faces)

A noter que cristobal78 l'avait mis "en dur", et si je l'avais écrit "en dur" il n'y aurait pas eu le syndrome... mais c'est moins facile de tester avec 300 !

Mais tu as optimisé dans une variable, ce qui est malin, car effectivement, même si dash est plus rapide, là je "fork" 27 millions de fois le programme seq !

Donc en suivant ta méthode on gagne effectivement du temps :

#! /bin/sh

faces=$(seq 1 300)

for de1 in $faces
	do 
	for de2 in $faces
		do 
		for de3 in $faces
			do
			echo "$(($de1+$de2+$de3))"
		done
	done
done | sort -n | uniq -c

Cette fois la liste des lancers possible est calculée une seule fois via seq, et le temps est quasi divisé par 2.

Comme quoi les petits détails peuvent faire des grandes différences de temps !

Tu peux refaire le test ? (Parce qu'on ne peut pas comparer tes chiffres aux miens, avec 2 processeurs différents, ça ne se compare pas !)

P.S.: j'ai modifié le générique avec nombre de dés paramétrable de la même manière.

Dernière modification par Zakhar (Le 17/10/2020, à 11:11)

Watael · Le 17/10/2020, à 11:15

tu gagnes énormément : 1m12,219s
il y a alors un léger avantage par rapport à bash.

Zakhar · Le 17/10/2020, à 11:21

Il reste une différence fondamentale entre le code de pingouinux, le tien, mon code C, et le code shell que je montre, c'est que dans tous les codes on utilise une variable interne pour cumuler et on affiche le résultat par une autre boucle à la fin.

Mon code utilise la "technique linux du pipe" et envoie l'intégralité des calculs de la boucle interne "dans le pipe". Pour rigoler, vous pouvez remplacer le | sort | uniq -c de la fin par une redirection, et vous verrez qu'on "pipe" la bagatelle de 100Mo de données avec un dé à 3000 faces !..

Or "pipe" = I/O, même si tout est fait en mémoire en l'occurrence, ça reste plus lourd qu'un cumul interne, ce que fait ton programme, celui de pingouinux, et mon programme C.

Le "pipe" est cependant tellement "philosophie linux" que je n'ai pas pu résister !

En utilisant le "pipe", de fait, on n'a pas besoin d'une boucle d'affichage car on a donné tous les résultats détaillés, et ce sont les programmes qui sont à la suite dans le "pipe" qui vont faire le job.

C'est vraiment une autre façon de faire... mais il est vrai pas nécessairement la plus optimisée en temps.
3000 faces "pipe" 100Mo de données, qu'il faut ensuite trier (sort), puis compter les lignes uniques (uniq) -ça c'est rapide en 1 passe... mais quand même sur 100Mo-

Donc compte tenu de la différence de "technique", il va y avoir un nombre de faces où la technique "pipe" sera plus lente que le calcul en variable interne, malgré l'optimisation de dash par rapport à bash : 5000, 10000 ?

Donc si tu veux comparer les temps dash/bash, il faut que tu compares sur la même chose, c'est à dire mon code en dash puis en bash (il suffit de changer le "shebang")
Ton code utilisant une autre "technique" (variable interne au lieu de "pipe") n'étant pas portable dash, tu ne peux pas faire la comparaison. Sans doute que s'il était portable dash (hélas pas de chance avec les tableaux !) ça irait encore beaucoup plus vite avec dash et ta technique !

Donc oui, les "bashism" peuvent aider, notamment à la performance d'algorithmes... mais quand on en est là je rejoins volontiers Vobul, autant faire en Python, ou encore mieux en C si on veut vraiment dépoter.
Mon programme C n'est pas fondamentalement différent de ce que tu as écrit en bash, il est même d'ailleurs totalement identique d'un point due vue algorithme et à la syntaxe près très ressemblant.

Je ne parle pas des exemples avec nombre de dés générique qui utilisent la récursivité, ça c'est encore un autre niveau de "non-performance" mais tellement beau !

Dernière modification par Zakhar (Le 17/10/2020, à 11:46)

Vobul · Le 17/10/2020, à 12:11

Bon ben moi j'ai fait une version en rust, et j'obtiens le même temps qu'en C

Zakhar · Le 17/10/2020, à 13:12

Pourquoi "sacrifier au dernier langage à la mode" !
C'est sans doute aussi pareil en Pascal, en Fortran... sur un tel algorithme ça ne m'étonnerait pas, il n'y a aucune chose du genre "manipulation mémoire" qui pourrait faire une quelconque différence entre les langages compilés.

Mon observation était que les deux façon de faire sont très différentes.

Donc si l'exercice (devoir d'école ?) était de montrer qu'on connaît bien Linux, on obtient A++ avec la version "pipe".

On peut aussi remarquer que le temps total observé n'est pas la somme des temps, en effet le /usr/bin/time -v montre :

Percent of CPU this job got: 169%

... ce qui n'est pas le cas avec la version purement algorithmique qui calcule tout en mémoire, elle devrait montrer juste un peu en dessous 100%.
En effet, le "sort" dans le pipe n'attend pas que le programme amont (nos 3 boucles imbriquées) qui écrit les sommes soit fini pour commencer à trier. Au contraire le tri se fait "en parallèle" et donc si on a plusieur "core", le temps de pipe/tri est gommé. Par contre "uniq" attend, puisque le tri ne peut rien afficher tant qu'il n'a pas reçu toutes les données à trier. Mais comme le uniq seul prend 0.5 sec, ce n'est pas très grave.

Donc si au lieu de mesurer le "temps" on regarde l'efficacité, la méthode "linux/pipe" est bien inefficace... mais évite de refaire des algorithmes qui existent déjà par ailleurs ("philosophie Linux").

D'un autre côté, si l'exercice d'école était de montrer qu'on sait écrire des algorithme rapides, il faut plutôt prendre les versions de pingouinux ou Wattael pour avoir A++, mais là où je te rejoins absolument Vobul, si l'exercice est de montrer qu'on sait écrire des trucs performants et rapides... le shell n'est pas le bon langage !

Donc j'ai juste supposé que le but n'était pas de développer le truc "le plus performant", d'autant que sur 3 dés à six face la différence entre technique de codage et même langages est totalement insignifiante !

Vobul a écrit :

Bon ben moi j'ai fait une version en rust, et j'obtiens le même temps qu'en C

Tu devrais essayer en assembleur pour passer de 0,07 à 0,06 secondes.

Dernière modification par Zakhar (Le 17/10/2020, à 13:46)

Zakhar · Le 17/10/2020, à 14:02

[Hors-sujet]

@Vobul sinon j'aime bien Python, pas pour le langage lui-même, mais parce qu'il prouve que l'Open Source a gagné et que le "propriétaire" ne peut que décliner !..

Historiquement, on avait un langage interprété qui était super utilisé : Basic et ses déclinaisons.

Mais voila, à sa bonne habitude, MigroMou en a fait un truc propriétaire verrouillé... et à part le monde clos de M$ sous sa forme de macro office, il n'existe plus guère dans les stats publiques (Tiobe).

Alors les gens se sont tournés vers Java, qui montait, montait au point de détrôner langage après langage dans le fameux "indice Tiobe"

Puis Oracle a mis la main dessus en rachetant Sun... et surprise, que voit-on : maintenant c'est Python qui monte, monte, monte, et Java qui décline lentement.

Bon, C et ses nombreuses variantes (dont Rust fait partie de loin) s'en fiche un peu, c'est tellement un "langage socle" qu'il est toujours dans le haut du "Tiobe" en rajoutant les variantes et toujours à peu près stable sans grandes montées ou descente.

Conclusion, les développeurs ont raison, ils ne veulent pas d'un langage qui est "à la botte" des intérêts d'un "vendeur" et peut partir à 180° de leurs intérêts du jour au lendemain.
Python n'est pas dans ce cas, c'est bien un langage "libre" (pour l'instant !)... ce qui veut dire qu'une foule de développeurs ont pu enrichir sa bibliothèque d'un tas de trucs intéressants et tant pis pour M$ ou Oracl€ qui n'ont rien compris !

Et même des "grosses boîtes" qui développent, Java fait réfléchir avec le procès qui n'en finit plus entre Oracle et Google. Le choix de ce langage peut faire poser la question si on ne va pas se trouver dans la même situation si on développe un truc qui a du succès !..

Le C ne risque rien non plus, c'est une norme ISO.

Dernière modification par Zakhar (Le 17/10/2020, à 14:08)

pingouinux · Le 17/10/2020, à 17:21

Je dois avouer qu'en #2 je ne me suis pas posé autant de questions, mais me suis contenté de donner une solution en modifiant le moins possible le script fourni par cristobal78.

Zakhar · Le 17/10/2020, à 19:38

Ma proposition modifie encore moins
- réduction du "echo" pour n'afficher que le total
- rajout d'un "double pipe" à la fin de la triple boucle.

Le reste ce sont des rajouts pour "faire propre" : rendre le nombre de faces du dé paramétrable + optimisation suite à échange avec Wattael

Si tu écris ma modification ainsi, sans "faire propre et optimisé" :

#!/bin/bash
for de1 in 1 2 3 4 5 6
	do 
	for de2 in 1 2 3 4 5 6
		do 
		for de3 in 1 2 3 4 5 6
			do
			echo $(($de1+$de2+$de3))
		done
	done
done | sort -n | uniq -c

Voici le diff pour les deux versions :

$ diff p1.sh p2.sh 
8c8
< 			echo "$de1 + $de2 + $de3 = $(($de1+$de2+$de3))"
---
> 			echo $(($de1+$de2+$de3))
11c11
< done
---
> done | sort -n | uniq -c

$ diff p1.sh p3.sh 
1a2
> tot=( 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 )
7a9,10
>                         s=$((de1+de2+de3))
>                         tot[$s]=$(( ${tot[$s]} + 1 ))
11a15,16
> for i in {3..18}; do echo $i ${tot[$i]}; done
>

Donc 2 lignes modifiées sur ma version (non clean) et 4 lignes ajoutées sur la tienne.

Mais c'est sûr, les deux versions marchent, et on peut sans doute faire plein d'autres codes qui fonctionnent.

Et aussi tu as été plus rapide sur ce coup là !

Dernière modification par Zakhar (Le 17/10/2020, à 19:42)

cristobal78 · Le 17/10/2020, à 19:44

Oui cher pinguouinux et en plus tu as été le 1-er à répondre et t'en remercie à nouveau.

Cela dit j'ai bcp aimé et suivi dans la mesure de mes modestes moyens la riche discussion que ce petit pb, à ma grande surprise, a suscité auprès d'autres codeurs de talents.
Une petite précision pour l'ami zakhar : ce n'est pas un devoir d'école (je suis maintenant bcp trop vieux pour ça !) mais simplement un point apparu dans un livre très intéressant "Toutes les mathématiques du monde, de Hervé Lehning (Flammarion 2017) dont je vous recommande la lecture.

Je passe en résolu mais je reste preneur d'un document pédagogique sur les tableaux en Bash.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/10/2020, à 18:14

(résolu)tri des valeurs après plusieurs "for in ... do.. done"

#2 Le 13/10/2020, à 18:38

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#3 Le 13/10/2020, à 18:40

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#4 Le 13/10/2020, à 20:28

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#5 Le 13/10/2020, à 20:35

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#6 Le 13/10/2020, à 23:53

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#7 Le 13/10/2020, à 23:56

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#8 Le 17/10/2020, à 01:14

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#9 Le 17/10/2020, à 09:33

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#10 Le 17/10/2020, à 10:03

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#11 Le 17/10/2020, à 10:04

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#12 Le 17/10/2020, à 10:05

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#13 Le 17/10/2020, à 10:09

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#14 Le 17/10/2020, à 10:17

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#15 Le 17/10/2020, à 10:40

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#16 Le 17/10/2020, à 10:45

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#17 Le 17/10/2020, à 11:02

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#18 Le 17/10/2020, à 11:15

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#19 Le 17/10/2020, à 11:21

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#20 Le 17/10/2020, à 12:11

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#21 Le 17/10/2020, à 13:12

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#22 Le 17/10/2020, à 14:02

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#23 Le 17/10/2020, à 17:21

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#24 Le 17/10/2020, à 19:38

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

#25 Le 17/10/2020, à 19:44

Re : (résolu)tri des valeurs après plusieurs "for in ... do.. done"

Pied de page des forums