J essaie de faire generer des nombres aleatoires à X processus venant de
X fork() d'un processus père.
Quand chacun d'eux genere un nombre aleatoire avec random() ou rand(),
meme avec (1+(int) (10.0*rand()/(RAND_MAX+1.0))) , tous me renvoient la
meme valeur exactement.
Comment cela se fait il ?
Et comment avoir X processus générant des valeurs différentes ?
Je suis moyennement d'accord, l'histoire du fork() est certes HS, mais il ne s'agit là que d'une petite partie de la question. Il est évident que le problème d'Axel vient plus d'une mauvaise compréhension du fonctionnement de rand() que de celui de fork().
Mwais, c'est vrai, mais les réponses (à base de getpid ou de /dev/urandom) sont elles aussi HS ;)
Oui c'est vrai, mais ce n'est pas une raison pour lui jeter des pierres alors :)
Dans le doute, il a parlé des deux aspects de son programme, et c'est normal.
Donc, si on évite d'être trop méchant, on lit complètement le post pour isoler la vraie question avant de le classer HS.
Euh, j'ai répondu au post du mieux que je pouvais (donc je l'ai lu) et je n'estime pas avoir été particulièrement méchant
Ce n'est pas ce que je voulais dire, je ne faisais pas référence à ta réponse puisque tu lui as répondu en premier et efficacement. Je voulais juste mettre l'accent sur le fait que certains classent un peu vite les posts comme étant HS, simplement à base de "mots-clés" (fork) et parfois sans prendre la peine de réellement lire la question.
Et, personnellement, je ne le classe pas HS du tout (mais cela n'engage que moi).
Le post initial peut-être pas, mes réponses le sont ;) Mais je ne vois pas comment répondre au post sans parler de choses non standards (au sens standard du C, fork() est POSIX)
Moi non plus :)
L'important c'est que la question ne soit pas HS, non ? Dans ce cas tes réponses ne le sont pas, puisqu'elles répondent de manière pertinente à la question, alors que beaucoup se seraient contentés d'un vulgaire "RTFM" (souvent, un débutant ne sait pas ce que veut dire RTFM, cela ne l'aide donc pas plus).
a+ Florent
Gaël Le Mignot wrote:
Gaël Le Mignot wrote:
Mais je suis d'accord, c'est HS.
Je suis moyennement d'accord, l'histoire du fork() est certes HS,
mais il ne s'agit là que d'une petite partie de la question. Il est
évident que le problème d'Axel vient plus d'une mauvaise
compréhension du fonctionnement de rand() que de celui de fork().
Mwais, c'est vrai, mais les réponses (à base de getpid ou de
/dev/urandom) sont elles aussi HS ;)
Oui c'est vrai, mais ce n'est pas une raison pour lui jeter des pierres
alors :)
Dans le doute, il a parlé des deux aspects de son programme, et c'est
normal.
Donc, si on évite d'être trop méchant, on lit complètement le post
pour isoler la vraie question avant de le classer HS.
Euh, j'ai répondu au post du mieux que je pouvais (donc je l'ai lu) et
je n'estime pas avoir été particulièrement méchant
Ce n'est pas ce que je voulais dire, je ne faisais pas référence à ta
réponse puisque tu lui as répondu en premier et efficacement.
Je voulais juste mettre l'accent sur le fait que certains classent un
peu vite les posts comme étant HS, simplement à base de "mots-clés"
(fork) et parfois sans prendre la peine de réellement lire la question.
Et, personnellement, je ne le classe pas HS du tout (mais cela
n'engage que moi).
Le post initial peut-être pas, mes réponses le sont ;) Mais je ne vois
pas comment répondre au post sans parler de choses non standards (au
sens standard du C, fork() est POSIX)
Moi non plus :)
L'important c'est que la question ne soit pas HS, non ? Dans ce cas tes
réponses ne le sont pas, puisqu'elles répondent de manière pertinente à
la question, alors que beaucoup se seraient contentés d'un vulgaire
"RTFM" (souvent, un débutant ne sait pas ce que veut dire RTFM, cela ne
l'aide donc pas plus).
Je suis moyennement d'accord, l'histoire du fork() est certes HS, mais il ne s'agit là que d'une petite partie de la question. Il est évident que le problème d'Axel vient plus d'une mauvaise compréhension du fonctionnement de rand() que de celui de fork().
Mwais, c'est vrai, mais les réponses (à base de getpid ou de /dev/urandom) sont elles aussi HS ;)
Oui c'est vrai, mais ce n'est pas une raison pour lui jeter des pierres alors :)
Dans le doute, il a parlé des deux aspects de son programme, et c'est normal.
Donc, si on évite d'être trop méchant, on lit complètement le post pour isoler la vraie question avant de le classer HS.
Euh, j'ai répondu au post du mieux que je pouvais (donc je l'ai lu) et je n'estime pas avoir été particulièrement méchant
Ce n'est pas ce que je voulais dire, je ne faisais pas référence à ta réponse puisque tu lui as répondu en premier et efficacement. Je voulais juste mettre l'accent sur le fait que certains classent un peu vite les posts comme étant HS, simplement à base de "mots-clés" (fork) et parfois sans prendre la peine de réellement lire la question.
Et, personnellement, je ne le classe pas HS du tout (mais cela n'engage que moi).
Le post initial peut-être pas, mes réponses le sont ;) Mais je ne vois pas comment répondre au post sans parler de choses non standards (au sens standard du C, fork() est POSIX)
Moi non plus :)
L'important c'est que la question ne soit pas HS, non ? Dans ce cas tes réponses ne le sont pas, puisqu'elles répondent de manière pertinente à la question, alors que beaucoup se seraient contentés d'un vulgaire "RTFM" (souvent, un débutant ne sait pas ce que veut dire RTFM, cela ne l'aide donc pas plus).
a+ Florent
Richard Delorme
PS : les fonctions time() et clock() ne fonctionnent pas forcément sur tout les systèmes.
Sauf que dans le cas de deux processus et d'un fork, time() est souvent peu précis (time() aura souvent la même valeur dans le fils et dans le père). Je ne connaissais pas clock(), mais en effet il est précisé dans le man que ça peut renvoyer MAX-1 si le système ne le supporte pas.
enfin même clock() peut éventuellement ne pas être assez précis suivant la vitesse du système.
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
-- Richard
PS : les fonctions time() et clock() ne fonctionnent pas forcément sur
tout les systèmes.
Sauf que dans le cas de deux processus et d'un fork, time() est
souvent peu précis (time() aura souvent la même valeur dans le fils et
dans le père). Je ne connaissais pas clock(), mais en effet il est
précisé dans le man que ça peut renvoyer MAX-1 si le système ne
le supporte pas.
enfin même clock() peut éventuellement ne pas être assez précis suivant
la vitesse du système.
En plus, clock() mesure le temps CPU consommé depuis le lancement du
programme, donc si l'appel à srand() est effectué au même moment
(c'est-à-dire dans la précision de clock()) dans les deux processus, on
aura le même point de départ.
PS : les fonctions time() et clock() ne fonctionnent pas forcément sur tout les systèmes.
Sauf que dans le cas de deux processus et d'un fork, time() est souvent peu précis (time() aura souvent la même valeur dans le fils et dans le père). Je ne connaissais pas clock(), mais en effet il est précisé dans le man que ça peut renvoyer MAX-1 si le système ne le supporte pas.
enfin même clock() peut éventuellement ne pas être assez précis suivant la vitesse du système.
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
-- Richard
espie
In article , DINH Viêt Hoà wrote:
Emmanuel Delahaye wrote:
Il n'y a pas de 'processus' ou de 'fork()' en langage C. Merci de reposter sur un forum dédié à ton système. Celui-ci a probalement un générateur de random multi-processus. (au hasard : '/dev/random')
Je suis en partie d'accord avec toi, mais une partie de sa question traite du C. Tu as tendance a jouer au modérateur, mais la je trouve que t'exagère. Je ne crois pas que son post pollue le ng, et je pense que t'aurais pu t'abstenir de poster une réponse aussi inutile.
Enfin je pense qu'en repostant sa question sur fr.comp.os.unix, il aurait eu des réponses plus élaborée qu'ici.
Et puis ? savoir qu'est-ce qui est standard dans ce qu'il utilise, et ce qui ne l'est pas, peut etre la partie interessante de la reponse.
Imagine-toi en debutant, avec des besoins de nombres pseudo-aleatoires. Realiser les limitations de rand/srand, et a quel point c'est complique d'obtenir une graine correcte (et tous les aspects qui vont avec), euh, c'est pas sur fr.comp.os.unix qu'il faut la poser la question, c'est sur fr.*.math !
In article <etPan.3fd4522c.3d5364da.60f7@homer>,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Emmanuel Delahaye wrote:
Il n'y a pas de 'processus' ou de 'fork()' en langage C. Merci de reposter
sur un forum dédié à ton système. Celui-ci a probalement un générateur de
random multi-processus. (au hasard : '/dev/random')
Je suis en partie d'accord avec toi, mais une partie de sa question
traite du C. Tu as tendance a jouer au modérateur, mais la je trouve que
t'exagère. Je ne crois pas que son post pollue le ng, et je pense que
t'aurais pu t'abstenir de poster une réponse aussi inutile.
Enfin je pense qu'en repostant sa question sur fr.comp.os.unix, il
aurait eu des réponses plus élaborée qu'ici.
Et puis ? savoir qu'est-ce qui est standard dans ce qu'il utilise, et ce
qui ne l'est pas, peut etre la partie interessante de la reponse.
Imagine-toi en debutant, avec des besoins de nombres pseudo-aleatoires.
Realiser les limitations de rand/srand, et a quel point c'est complique
d'obtenir une graine correcte (et tous les aspects qui vont avec), euh,
c'est pas sur fr.comp.os.unix qu'il faut la poser la question, c'est sur
fr.*.math !
Il n'y a pas de 'processus' ou de 'fork()' en langage C. Merci de reposter sur un forum dédié à ton système. Celui-ci a probalement un générateur de random multi-processus. (au hasard : '/dev/random')
Je suis en partie d'accord avec toi, mais une partie de sa question traite du C. Tu as tendance a jouer au modérateur, mais la je trouve que t'exagère. Je ne crois pas que son post pollue le ng, et je pense que t'aurais pu t'abstenir de poster une réponse aussi inutile.
Enfin je pense qu'en repostant sa question sur fr.comp.os.unix, il aurait eu des réponses plus élaborée qu'ici.
Et puis ? savoir qu'est-ce qui est standard dans ce qu'il utilise, et ce qui ne l'est pas, peut etre la partie interessante de la reponse.
Imagine-toi en debutant, avec des besoins de nombres pseudo-aleatoires. Realiser les limitations de rand/srand, et a quel point c'est complique d'obtenir une graine correcte (et tous les aspects qui vont avec), euh, c'est pas sur fr.comp.os.unix qu'il faut la poser la question, c'est sur fr.*.math !
Alexandre Gouraud
Richard Delorme wrote:
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ou bien suis-je en train de réinventer le pid ?
Je suis persuadé qu'il est tout à fait possible de se passer des fonctions non standards, mis à part ce qui concerne la création de processus.
Richard Delorme wrote:
En plus, clock() mesure le temps CPU consommé depuis le lancement du
programme, donc si l'appel à srand() est effectué au même moment
(c'est-à-dire dans la précision de clock()) dans les deux processus, on
aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du
get_pid()) que le processus père initialise une séquence aléatoire, et
transmette à ses fils un nombre de cette séquence, qui servira à
l'initialisation de leur propre séquence aléatoire ?
Ou bien suis-je en train de réinventer le pid ?
Je suis persuadé qu'il est tout à fait possible de se passer des
fonctions non standards, mis à part ce qui concerne la création de
processus.
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ou bien suis-je en train de réinventer le pid ?
Je suis persuadé qu'il est tout à fait possible de se passer des fonctions non standards, mis à part ce qui concerne la création de processus.
kilobug
Richard Delorme wrote:
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Oui, c'est possible aussi (mais il faut toujours penser à mettre la graine du père avant)
Ou bien suis-je en train de réinventer le pid ?
Le PID est rarement aléatoire, sur la plupart des systèmes il est incrémenté à chaque process créé, puis revient à 0 quand le max est atteint (en faisant gaffe de ne jamais reprendre un PID déjà utilisé). Maintenat, ça dépend du système.
Je suis persuadé qu'il est tout à fait possible de se passer des fonctions non standards, mis à part ce qui concerne la création de processus.
En effet, ça doit marcher comme ça :)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Richard Delorme wrote:
En plus, clock() mesure le temps CPU consommé depuis le lancement du
programme, donc si l'appel à srand() est effectué au même moment
(c'est-à-dire dans la précision de clock()) dans les deux processus, on
aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du
get_pid()) que le processus père initialise une séquence aléatoire, et
transmette à ses fils un nombre de cette séquence, qui servira à
l'initialisation de leur propre séquence aléatoire ?
Oui, c'est possible aussi (mais il faut toujours penser à mettre la
graine du père avant)
Ou bien suis-je en train de réinventer le pid ?
Le PID est rarement aléatoire, sur la plupart des systèmes il est
incrémenté à chaque process créé, puis revient à 0 quand le max est
atteint (en faisant gaffe de ne jamais reprendre un PID déjà
utilisé). Maintenat, ça dépend du système.
Je suis persuadé qu'il est tout à fait possible de se passer des
fonctions non standards, mis à part ce qui concerne la création de
processus.
En effet, ça doit marcher comme ça :)
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Oui, c'est possible aussi (mais il faut toujours penser à mettre la graine du père avant)
Ou bien suis-je en train de réinventer le pid ?
Le PID est rarement aléatoire, sur la plupart des systèmes il est incrémenté à chaque process créé, puis revient à 0 quand le max est atteint (en faisant gaffe de ne jamais reprendre un PID déjà utilisé). Maintenat, ça dépend du système.
Je suis persuadé qu'il est tout à fait possible de se passer des fonctions non standards, mis à part ce qui concerne la création de processus.
En effet, ça doit marcher comme ça :)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
DINH Viêt Hoà
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid())
puisqu'on garde fork(), pourquoi ne pas garder getpid() ?
que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ou bien suis-je en train de réinventer le pid ?
tout à fait.
Je suis persuadé qu'il est tout à fait possible de se passer des fonctions non standards, mis à part ce qui concerne la création de processus.
en général, lorsque tu as des fonctions de créations de processus, tu as également des fonctions pour identifier les processus créés.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du
get_pid())
puisqu'on garde fork(), pourquoi ne pas garder getpid() ?
que le processus père initialise une séquence aléatoire, et
transmette à ses fils un nombre de cette séquence, qui servira à
l'initialisation de leur propre séquence aléatoire ?
Ou bien suis-je en train de réinventer le pid ?
tout à fait.
Je suis persuadé qu'il est tout à fait possible de se passer des
fonctions non standards, mis à part ce qui concerne la création de
processus.
en général, lorsque tu as des fonctions de créations de processus, tu as
également des fonctions pour identifier les processus créés.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid())
puisqu'on garde fork(), pourquoi ne pas garder getpid() ?
que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ou bien suis-je en train de réinventer le pid ?
tout à fait.
Je suis persuadé qu'il est tout à fait possible de se passer des fonctions non standards, mis à part ce qui concerne la création de processus.
en général, lorsque tu as des fonctions de créations de processus, tu as également des fonctions pour identifier les processus créés.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Jean-Marc Bourguet
Alexandre Gouraud writes:
Richard Delorme wrote:
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Alexandre Gouraud <ag@tb.fr> writes:
Richard Delorme wrote:
En plus, clock() mesure le temps CPU consommé depuis le lancement du
programme, donc si l'appel à srand() est effectué au même moment
(c'est-à-dire dans la précision de clock()) dans les deux processus, on
aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du
get_pid()) que le processus père initialise une séquence aléatoire,
et transmette à ses fils un nombre de cette séquence, qui servira à
l'initialisation de leur propre séquence aléatoire ?
Ca depend du generateur. Pour certains, utiliser un nombre de la
sequence comme graine permet de regenerer la sequence... donc tu
n'auras pas l'effet voulu.
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
En plus, clock() mesure le temps CPU consommé depuis le lancement du programme, donc si l'appel à srand() est effectué au même moment (c'est-à-dire dans la précision de clock()) dans les deux processus, on aura le même point de départ.
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
DINH Viêt Hoà
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
effectivement, si l'on génère des processus à 1 seconde d'intervalle on obtiendra la même graine pour les processus fils et la même séquence.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du
get_pid()) que le processus père initialise une séquence aléatoire,
et transmette à ses fils un nombre de cette séquence, qui servira à
l'initialisation de leur propre séquence aléatoire ?
Ca depend du generateur. Pour certains, utiliser un nombre de la
sequence comme graine permet de regenerer la sequence... donc tu
n'auras pas l'effet voulu.
effectivement, si l'on génère des processus à 1 seconde d'intervalle on
obtiendra la même graine pour les processus fils et la même séquence.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Ne pourrait-on imaginer (tout cela pour essayer de se débarasser du get_pid()) que le processus père initialise une séquence aléatoire, et transmette à ses fils un nombre de cette séquence, qui servira à l'initialisation de leur propre séquence aléatoire ?
Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
effectivement, si l'on génère des processus à 1 seconde d'intervalle on obtiendra la même graine pour les processus fils et la même séquence.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Alexandre Gouraud
Jean-Marc Bourguet wrote:
Alexandre Gouraud writes: Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
Tu peux expliquer un peu plus, parce que je ne suis pas sur de comprendre. Des séquences aléatoires, j'imagine qu'il n'y en a qu'une sur un générateur de bruit. La seul différence, c'est qu'on la démarre à chaque fois à un endroit différent. Donc de toute façon, utiliser un nombre de la séquence ou pas, on en revient toujours à regenérer la séquence, décalée, quelle que soit la méthode utilisée. Est-ce que c'est ce que tu voulais dire ?
J'ai l'impression qu'on pinaille là ?
Alexandre, curieux.
Jean-Marc Bourguet wrote:
Alexandre Gouraud <ag@tb.fr> writes:
Ca depend du generateur. Pour certains, utiliser un nombre de la
sequence comme graine permet de regenerer la sequence... donc tu
n'auras pas l'effet voulu.
Tu peux expliquer un peu plus, parce que je ne suis pas sur de
comprendre. Des séquences aléatoires, j'imagine qu'il n'y en a qu'une
sur un générateur de bruit. La seul différence, c'est qu'on la démarre à
chaque fois à un endroit différent. Donc de toute façon, utiliser un
nombre de la séquence ou pas, on en revient toujours à regenérer la
séquence, décalée, quelle que soit la méthode utilisée. Est-ce que c'est
ce que tu voulais dire ?
Alexandre Gouraud writes: Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
Tu peux expliquer un peu plus, parce que je ne suis pas sur de comprendre. Des séquences aléatoires, j'imagine qu'il n'y en a qu'une sur un générateur de bruit. La seul différence, c'est qu'on la démarre à chaque fois à un endroit différent. Donc de toute façon, utiliser un nombre de la séquence ou pas, on en revient toujours à regenérer la séquence, décalée, quelle que soit la méthode utilisée. Est-ce que c'est ce que tu voulais dire ?
J'ai l'impression qu'on pinaille là ?
Alexandre, curieux.
Jean-Marc Bourguet
Alexandre Gouraud writes:
Jean-Marc Bourguet wrote:
Alexandre Gouraud writes: Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
Tu peux expliquer un peu plus, parce que je ne suis pas sur de comprendre. Des séquences aléatoires, j'imagine qu'il n'y en a qu'une sur un générateur de bruit. La seul différence, c'est qu'on la démarre à chaque fois à un endroit différent. Donc de toute façon, utiliser un nombre de la séquence ou pas, on en revient toujours à regenérer la séquence, décalée, quelle que soit la méthode utilisée. Est-ce que c'est ce que tu voulais dire ?
Ca regenere la sequence a partir du nombre ayant servi a l'initialisation.
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Alexandre Gouraud <ag@tb.fr> writes:
Jean-Marc Bourguet wrote:
Alexandre Gouraud <ag@tb.fr> writes:
Ca depend du generateur. Pour certains, utiliser un nombre de la
sequence comme graine permet de regenerer la sequence... donc tu
n'auras pas l'effet voulu.
Tu peux expliquer un peu plus, parce que je ne suis pas sur de
comprendre. Des séquences aléatoires, j'imagine qu'il n'y en a qu'une sur
un générateur de bruit. La seul différence, c'est qu'on la démarre à chaque
fois à un endroit différent. Donc de toute façon, utiliser un nombre de la
séquence ou pas, on en revient toujours à regenérer la séquence, décalée,
quelle que soit la méthode utilisée. Est-ce que c'est ce que tu voulais
dire ?
Ca regenere la sequence a partir du nombre ayant servi a
l'initialisation.
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Alexandre Gouraud writes: Ca depend du generateur. Pour certains, utiliser un nombre de la sequence comme graine permet de regenerer la sequence... donc tu n'auras pas l'effet voulu.
Tu peux expliquer un peu plus, parce que je ne suis pas sur de comprendre. Des séquences aléatoires, j'imagine qu'il n'y en a qu'une sur un générateur de bruit. La seul différence, c'est qu'on la démarre à chaque fois à un endroit différent. Donc de toute façon, utiliser un nombre de la séquence ou pas, on en revient toujours à regenérer la séquence, décalée, quelle que soit la méthode utilisée. Est-ce que c'est ce que tu voulais dire ?
Ca regenere la sequence a partir du nombre ayant servi a l'initialisation.
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
