Je suis sur un code dans lequel il y a la déclaration suivante, dans
le main :
int a=2;
A A(a);
ou A est une class contenant que des membres statiques:
class A
{
static int a1;
public:
A();
A(int);
static int geta(void);
}
J'ai un peu de mal avec cette "déclaration". En essayant de
comprendre, il s'agit d'une variable non nommée ? Ai-je bon ?
l'acces au membre a1 se fait par A::geta(). J'ai besoin de pouvoir
enregistrer la class dans un fichier. j'ai donc défini :
friend ostream & operator<<(ostream & o, A& m);
mais la variable crée par "A A(a);" n'est pas utilisable par ma
fonction. Pourriez vous m'expliquer pourquoi et dans quels cas on
utilise de telle variable "non nommée" ?
C'est pas sûr, plus on utilise un générateur de nombres aléatoire entre plusieurs modules, plus les nombres sont décorrélés (pour un module, ça correspond à un sampling de la sortie du générateur). Un des meilleur système que j'ai utilisé était un processus en arrière plan qui générait des nombre continuellement et de lui en demander un quand on en avait besoin.
tous les algos un tant soit peu sérieux que je connaisse dispose d'un pool - calculé en arrière plan ou quand c'est nécessaire (ie quand vide) - MT19937 utilise un pool de 624 int32 par exemple; pour autant générer des nombres en continu n'a pas d'intérêt / sens particulier, et la qualité de la distribution n'est nullement liée à la taille de ce pool, une implémentation certifiable FIPS basée sur DES aura par exemple un pool de 20 octets.
Un des intérêts d'avoir une classe de nombre aléatoire est éventuellement d'en utiliser plusieurs instances initialisés à des seeds différents pour généré des nombres en les combinant. Ca augmente la cyclicité du générateur global tout en diminuant la prédictibilité.
je pense plutôt que la qualité de la distribution est inhérente à l'algo seul, penser améliorer quelque chose en "combinant" a posteriori est souvent une erreur motivée par le patch sur le patch qui corrigerait tout (en fait rien).
Un autre est de fournir la reproductibilité des résultats en cas d'utilisation multithread en utilisant une instance par thread.
ces arguments allant donc dans le sens de déclarations d'instances, non statiques, je ne suis pas sur de comprendre le "c'est pas sur" initial.
Sylvain.
Michael DOUBEZ wrote on 10/05/2007 12:36:
C'est pas sûr, plus on utilise un générateur de nombres aléatoire entre
plusieurs modules, plus les nombres sont décorrélés (pour un module, ça
correspond à un sampling de la sortie du générateur). Un des meilleur
système que j'ai utilisé était un processus en arrière plan qui générait
des nombre continuellement et de lui en demander un quand on en avait
besoin.
tous les algos un tant soit peu sérieux que je connaisse dispose d'un
pool - calculé en arrière plan ou quand c'est nécessaire (ie quand vide)
- MT19937 utilise un pool de 624 int32 par exemple; pour autant générer
des nombres en continu n'a pas d'intérêt / sens particulier, et la
qualité de la distribution n'est nullement liée à la taille de ce pool,
une implémentation certifiable FIPS basée sur DES aura par exemple un
pool de 20 octets.
Un des intérêts d'avoir une classe de nombre aléatoire est
éventuellement d'en utiliser plusieurs instances initialisés à des seeds
différents pour généré des nombres en les combinant. Ca augmente la
cyclicité du générateur global tout en diminuant la prédictibilité.
je pense plutôt que la qualité de la distribution est inhérente à l'algo
seul, penser améliorer quelque chose en "combinant" a posteriori est
souvent une erreur motivée par le patch sur le patch qui corrigerait
tout (en fait rien).
Un autre est de fournir la reproductibilité des résultats en cas
d'utilisation multithread en utilisant une instance par thread.
ces arguments allant donc dans le sens de déclarations d'instances, non
statiques, je ne suis pas sur de comprendre le "c'est pas sur" initial.
C'est pas sûr, plus on utilise un générateur de nombres aléatoire entre plusieurs modules, plus les nombres sont décorrélés (pour un module, ça correspond à un sampling de la sortie du générateur). Un des meilleur système que j'ai utilisé était un processus en arrière plan qui générait des nombre continuellement et de lui en demander un quand on en avait besoin.
tous les algos un tant soit peu sérieux que je connaisse dispose d'un pool - calculé en arrière plan ou quand c'est nécessaire (ie quand vide) - MT19937 utilise un pool de 624 int32 par exemple; pour autant générer des nombres en continu n'a pas d'intérêt / sens particulier, et la qualité de la distribution n'est nullement liée à la taille de ce pool, une implémentation certifiable FIPS basée sur DES aura par exemple un pool de 20 octets.
Un des intérêts d'avoir une classe de nombre aléatoire est éventuellement d'en utiliser plusieurs instances initialisés à des seeds différents pour généré des nombres en les combinant. Ca augmente la cyclicité du générateur global tout en diminuant la prédictibilité.
je pense plutôt que la qualité de la distribution est inhérente à l'algo seul, penser améliorer quelque chose en "combinant" a posteriori est souvent une erreur motivée par le patch sur le patch qui corrigerait tout (en fait rien).
Un autre est de fournir la reproductibilité des résultats en cas d'utilisation multithread en utilisant une instance par thread.
ces arguments allant donc dans le sens de déclarations d'instances, non statiques, je ne suis pas sur de comprendre le "c'est pas sur" initial.
Sylvain.
AG
Merci à tous pour vos réponses.
Je comprends qu'il s'agit donc bien de code mal écrit, et que nommer la variable avec le même nom que celui de la classe est une mauvaise pratique, qui ne sert à rien sinon à brouiller les pistes. Je note aussi que c'est autorisé par la norme, et que ça ne risque pas de casser le code (comportement indéfini, etc...).
Je m'en vais batailler contre cette pratique. Merci pour la solution du singleton, idiome que je ne connaissait pas (encore).
Alexandre.
Merci à tous pour vos réponses.
Je comprends qu'il s'agit donc bien de code mal écrit, et que nommer
la variable avec le même nom que celui de la classe est une mauvaise
pratique, qui ne sert à rien sinon à brouiller les pistes. Je note
aussi que c'est autorisé par la norme, et que ça ne risque pas de
casser le code (comportement indéfini, etc...).
Je m'en vais batailler contre cette pratique. Merci pour la solution
du singleton, idiome que je ne connaissait pas (encore).
Je comprends qu'il s'agit donc bien de code mal écrit, et que nommer la variable avec le même nom que celui de la classe est une mauvaise pratique, qui ne sert à rien sinon à brouiller les pistes. Je note aussi que c'est autorisé par la norme, et que ça ne risque pas de casser le code (comportement indéfini, etc...).
Je m'en vais batailler contre cette pratique. Merci pour la solution du singleton, idiome que je ne connaissait pas (encore).
Alexandre.
Fabien LE LEZ
On Thu, 10 May 2007 15:52:44 +0200, "AG" :
Je comprends qu'il s'agit donc bien de code mal écrit, et que nommer la variable avec le même nom que celui de la classe est une mauvaise pratique, qui ne sert à rien sinon à brouiller les pistes.
Un autre truc qui est également très douteux : utiliser un constructeur pour initialiser uniquement des variables statiques.
Je note aussi que c'est autorisé par la norme, et que ça ne risque pas de casser le code (comportement indéfini, etc...).
Que se passe-t-il si on fait ceci ?
A A (42); A b (84);
On Thu, 10 May 2007 15:52:44 +0200, "AG" <ag@tb.fr>:
Je comprends qu'il s'agit donc bien de code mal écrit, et que nommer
la variable avec le même nom que celui de la classe est une mauvaise
pratique, qui ne sert à rien sinon à brouiller les pistes.
Un autre truc qui est également très douteux : utiliser un
constructeur pour initialiser uniquement des variables statiques.
Je note
aussi que c'est autorisé par la norme, et que ça ne risque pas de
casser le code (comportement indéfini, etc...).
Je comprends qu'il s'agit donc bien de code mal écrit, et que nommer la variable avec le même nom que celui de la classe est une mauvaise pratique, qui ne sert à rien sinon à brouiller les pistes.
Un autre truc qui est également très douteux : utiliser un constructeur pour initialiser uniquement des variables statiques.
Je note aussi que c'est autorisé par la norme, et que ça ne risque pas de casser le code (comportement indéfini, etc...).
C'est pas sûr, plus on utilise un générateur de nombres aléatoire entre plusieurs modules, plus les nombres sont décorrélés (pour un module, ça correspond à un sampling de la sortie du générateur). Un des meilleur système que j'ai utilisé était un processus en arrière plan qui générait des nombre continuellement et de lui en demander un quand on en avait besoin.
tous les algos un tant soit peu sérieux que je connaisse dispose d'un pool - calculé en arrière plan ou quand c'est nécessaire (ie quand vide) - MT19937 utilise un pool de 624 int32 par exemple; pour autant générer des nombres en continu n'a pas d'intérêt / sens particulier, et la qualité de la distribution n'est nullement liée à la taille de ce pool, une implémentation certifiable FIPS basée sur DES aura par exemple un pool de 20 octets.
C'était une application de sécurité. Le Mersenne Twister n'était pas assez bon, il faut croire. Je ne suis pas un spécialiste mais intuitivement, j'avais compris que ce genre de technique permettais de sampler une séquence imprévisible sur le domaine de sortie du générateur (qui plus tard serait remplacé par un système hardware, c'est peut être la raison).
Un des intérêts d'avoir une classe de nombre aléatoire est éventuellement d'en utiliser plusieurs instances initialisés à des seeds différents pour généré des nombres en les combinant. Ca augmente la cyclicité du générateur global tout en diminuant la prédictibilité.
je pense plutôt que la qualité de la distribution est inhérente à l'algo seul, penser améliorer quelque chose en "combinant" a posteriori est souvent une erreur motivée par le patch sur le patch qui corrigerait tout (en fait rien).
Un autre est de fournir la reproductibilité des résultats en cas d'utilisation multithread en utilisant une instance par thread.
ces arguments allant donc dans le sens de déclarations d'instances, non statiques, je ne suis pas sur de comprendre le "c'est pas sur" initial.
Tu as raison, je pensais au fait qu'utiliser une seule instance de RNG permettait de le faire fonctionner sur un plus grand domaine. C'est pas essentiel et sans doute inutile.
Michael.
Michael DOUBEZ wrote on 10/05/2007 12:36:
C'est pas sûr, plus on utilise un générateur de nombres aléatoire
entre plusieurs modules, plus les nombres sont décorrélés (pour un
module, ça correspond à un sampling de la sortie du générateur). Un
des meilleur système que j'ai utilisé était un processus en arrière
plan qui générait des nombre continuellement et de lui en demander un
quand on en avait besoin.
tous les algos un tant soit peu sérieux que je connaisse dispose d'un
pool - calculé en arrière plan ou quand c'est nécessaire (ie quand vide)
- MT19937 utilise un pool de 624 int32 par exemple; pour autant générer
des nombres en continu n'a pas d'intérêt / sens particulier, et la
qualité de la distribution n'est nullement liée à la taille de ce pool,
une implémentation certifiable FIPS basée sur DES aura par exemple un
pool de 20 octets.
C'était une application de sécurité. Le Mersenne Twister n'était pas
assez bon, il faut croire. Je ne suis pas un spécialiste mais
intuitivement, j'avais compris que ce genre de technique permettais de
sampler une séquence imprévisible sur le domaine de sortie du générateur
(qui plus tard serait remplacé par un système hardware, c'est peut être
la raison).
Un des intérêts d'avoir une classe de nombre aléatoire est
éventuellement d'en utiliser plusieurs instances initialisés à des
seeds différents pour généré des nombres en les combinant. Ca augmente
la cyclicité du générateur global tout en diminuant la prédictibilité.
je pense plutôt que la qualité de la distribution est inhérente à l'algo
seul, penser améliorer quelque chose en "combinant" a posteriori est
souvent une erreur motivée par le patch sur le patch qui corrigerait
tout (en fait rien).
Un autre est de fournir la reproductibilité des résultats en cas
d'utilisation multithread en utilisant une instance par thread.
ces arguments allant donc dans le sens de déclarations d'instances, non
statiques, je ne suis pas sur de comprendre le "c'est pas sur" initial.
Tu as raison, je pensais au fait qu'utiliser une seule instance de RNG
permettait de le faire fonctionner sur un plus grand domaine. C'est pas
essentiel et sans doute inutile.
C'est pas sûr, plus on utilise un générateur de nombres aléatoire entre plusieurs modules, plus les nombres sont décorrélés (pour un module, ça correspond à un sampling de la sortie du générateur). Un des meilleur système que j'ai utilisé était un processus en arrière plan qui générait des nombre continuellement et de lui en demander un quand on en avait besoin.
tous les algos un tant soit peu sérieux que je connaisse dispose d'un pool - calculé en arrière plan ou quand c'est nécessaire (ie quand vide) - MT19937 utilise un pool de 624 int32 par exemple; pour autant générer des nombres en continu n'a pas d'intérêt / sens particulier, et la qualité de la distribution n'est nullement liée à la taille de ce pool, une implémentation certifiable FIPS basée sur DES aura par exemple un pool de 20 octets.
C'était une application de sécurité. Le Mersenne Twister n'était pas assez bon, il faut croire. Je ne suis pas un spécialiste mais intuitivement, j'avais compris que ce genre de technique permettais de sampler une séquence imprévisible sur le domaine de sortie du générateur (qui plus tard serait remplacé par un système hardware, c'est peut être la raison).
Un des intérêts d'avoir une classe de nombre aléatoire est éventuellement d'en utiliser plusieurs instances initialisés à des seeds différents pour généré des nombres en les combinant. Ca augmente la cyclicité du générateur global tout en diminuant la prédictibilité.
je pense plutôt que la qualité de la distribution est inhérente à l'algo seul, penser améliorer quelque chose en "combinant" a posteriori est souvent une erreur motivée par le patch sur le patch qui corrigerait tout (en fait rien).
Un autre est de fournir la reproductibilité des résultats en cas d'utilisation multithread en utilisant une instance par thread.
ces arguments allant donc dans le sens de déclarations d'instances, non statiques, je ne suis pas sur de comprendre le "c'est pas sur" initial.
Tu as raison, je pensais au fait qu'utiliser une seule instance de RNG permettait de le faire fonctionner sur un plus grand domaine. C'est pas essentiel et sans doute inutile.
