Voici le fruit de la réflexion de ce midi.
Il est important d'optimiser son environnement de travail, pour cela quoi de mieux qu'un environnement dynamique invitant à toujours se remettre en question.
Nous avons combiné l'outil idéal permettant cette joie qu'amène le renouveau :
Bon week-end à tous !
alias grep='GREP_COLOR=`python -c "import random; print random.randint(31, 36)"` grep --color=auto'
# Et en Java ?
Posté par Sébastien Koechlin . Évalué à 10. Dernière modification le 01 juillet 2017 à 09:23.
Il n'y a peut-être pas besoin de lancer toute la lourdeur de python pour sortir un entier entre 31 et 36.
alias grep='GREP_COLOR=$(($RANDOM%7+31)) grep --color=auto'
Mais l'idée est rigolote. Merci.
[^] # Re: Et en Java ?
Posté par Layus . Évalué à 6.
Je me suis dit exactement la même chose, et je me suis rendu compte que ça ne marche pas avec Zsh… Visiblement, quand on utilise l'alias après un pipe, il est lancé dans son propre subshell, et
man zshall
dit en gros que tous les subshells obtiennent toujours la même valeur pour $RANDOM, sauf si le parent l'utilise entre deux invocations.Je suis très déçu par Zsh là :-(.
[^] # Re: Et en Java ?
Posté par steph1978 . Évalué à 3.
C'est plus simple mais c'est faux.
$RANDOM retourne une valeur entre 0 et 32767 (2**15 valeurs).
Donc fonctionne exactement pour des puissances de 2 mais par pour les autres cas.
Pour les autres cas, la distribution n'est pas parfaite.
Bon pour 7, l'imprécision est très faible, moins de 1 pour 1000.
Mais je dirai que c'est un coup de chance.
[^] # Re: Et en Java ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 04 juillet 2017 à 10:40.
Euh, je ne vois pas la transition entre la plage de valeur et "fonctionne exactement pour des puissances de 2" ?
Pour moi, $RANDOM envoie un nombre entre 0 et 32767, et ensuite on fait un modulo 7 pour avoir un nombre entre 0 et 6, ça me semble plutôt correcte. Une autre plage de valeur aurait été plus correcte ?
PS: effectivement, pour avoir un nombre entre 31 et 36, on aurait du faire un modulo 6, mais ça ne change rien à mes questions.
[^] # Re: Et en Java ?
Posté par steph1978 . Évalué à 10.
Travaillons avec 6.
Jusqu'à 32768//6 * 6 - 1 = 32765, la répartition entre les 6 chiffres (0 .. 5) est équivalente : 5461 chacun.
Mais 32766, dont le modulo 6 est 0, ajoute une chance pour 0.
Et 32767, dont le modulo 6 est 1, ajoute une chance pour 1.
Au final, ce générateur de mauvaise qualité a la distribution suivante:
0 : 5462 / 32768 = 0,16668
1 : 5462 / 32768 = 0,16668
2 : 5461 / 32768 = 0,16665
3 : 5461 / 32768 = 0,16665
4 : 5461 / 32768 = 0,16665
5 : 5461 / 32768 = 0,16665
C'est un pouillème, et dans notre cas pas très important.
Mais si tu utilise ça avec un modulo plus grand, la distorsion s'amplifie et peut avoir des effets non désirés.
Bref, si l'application est sérieuse, ne pas utiliser ça ; et c'est vrai dans tous les langages : RANDOM et MODULO = PAS BIEN !
[^] # Re: Et en Java ?
Posté par steph1978 . Évalué à 10.
Note qu'une solution est de ne pas prendre en compte les valeurs résiduelles, c'est à dire qui sont dans la dernière plage incomplète des modulos.
Ça se calcul facilement : 32768//6 * 6 = 32766.
Ici, on enlève tout ce qui est supérieur ou égale à 32766 :
do
r = $RANDOM
while r >= 32766
On obtient ainsi forcément un nombre compris entre 0 et 32765. Et donc une distribution parfaite.
Mais dans ce cas, le temps de génération (= nombre de boucles) n'est pas prévisible et peut être très long pour des modulos "pénibles" : ex, pour 993, il faut enlever les 992 dernières valeurs (cas pire <1000). Mais même pour 1000, il faut enlever les 768 dernières valeurs (le modulo est facile à calculer de tête). Et donc 2% de chance de faire au moins deux fois la boucle.
[^] # Re: Et en Java ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Merci, c'est très bien expliqué :)
[^] # Re: Et en Java ?
Posté par steph1978 . Évalué à 10.
Et j'oubliais :
# man grep
Posté par Faya . Évalué à 7.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.