Pourquoi est - (rand() % rien) toujours 0 en C++?

J'ai de la difficulté à obtenir rand() en C++. rand() donne moi un très grand nombre. Lorsque j'essaie d'utiliser l'opérateur modulo (%) à lui donner une portée, il retourne toujours 0, n'importe quoi.

Semis, le générateur de nombre aléatoire au début du programme n'aide pas non plus.

Pouvez-vous poster une partie du code que vous utilisez?
Ne pas rand() vous donner un nombre entre 0 et 1, de sorte que vous avez à se multiplier avant d'appliquer le modulo?
Pas de. rand() en C/C++ donne un nombre entre 0 et RAND_MAX, qui est garanti pour être au moins 32767.
Alors vous ne devrait vraiment pas être à leur offrir des conseils. Ses pas comme si j'offre mes conseils équestre des cavaliers.
Par ailleurs, évitez d'utiliser % pour générer des nombres aléatoires dans une gamme. c-faq.com/lib/randrange.html

OriginalL'auteur Zachary Hinchliffe | 2010-01-25

  1. 7

    Le code suivant fonctionne très bien pour moi (par émission d'un nombre aléatoire entre 0 inclus et 1000 exclus chaque fois qu'il est exécuté):

    #include <cstdlib>
#include <ctime>
#include <iostream>

int main()
{
    std::srand(time(0));
    std::cout<<(std::rand() % 1000)<<std::endl;
    return 0;
}
    Problème résolu! Je n'étais pas à l'aide #include <ctime> quand j'ai semé le générateur de nombre aléatoire! Merci beaucoup!
    Vous voulez probablement pour activer les avertissements de votre compilateur. C'est le genre de chose que vous pouvez obtenir le compilateur à attraper.

    OriginalL'auteur Alex Martelli

  2. 8

    Je pense que c'est commun, si le générateur aléatoire de l'algorithme laisse une certaine forme de bits à zéro. (Par exemple, si les bits sont à zéro, le nombre de mod à faible constante sera toujours zéro.)

    Peut être devrais tu essayer quelque chose comme:

    const int desired_maximum = /* ... */;

int r = (((double)rand()) / RAND_MAX) * desired_maximum;

    Par exemple dans cette page de manuel lien, il dit:

    Numérique, de Recettes dans C: L'Art de Calcul Scientifique (William H. de Presse, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New York: Cambridge University Press, 1992 (2e ed., p. 277)), les commentaires suivants sont faits:

    "Si vous voulez générer un nombre entier aléatoire entre 1 et 10, vous devez toujours le faire en utilisant les bits d'ordre élevé, comme dans

    j = 1 + (int) (10.0 * (rand() /(RAND_MAX + 1.0)));

    et jamais par quelque chose ressemblant à 

    j = 1 + (rand() % 10);

    (qui utilise les bits de niveau inférieur)."

    Il ne serait pas une très bonne PNRG si elle revenait toujours des multiples de N 🙂
    Merci de ne pas aveuglément recommander les bits de poids fort. Cela dépend entièrement de l'GÉNÉRATEUR utilisé. Recettes ou numérique est un beau livre, mais surtout les anciennes éditions sont pleine de dangereuses conseils. C'est l'une de ces instances. D'ailleurs, même ceux C/C++ implémentations utiliser un LCG jetez bits. Les gens ont appris depuis les années 70.
    si N est de 1, alors je n'ai pas de problème avec ça 😉
    Eh bien, dans ce cas, vous n'avez pas vraiment besoin d'un générateur de nombres aléatoires; il n'est tout simplement pas beaucoup de choix dans les nombres entre 1 et N, lorsque N==1 😉
    eh bien, il retourne multiples N, donc 1 est en fait le meilleur que vous pouvez y arriver 🙂

    OriginalL'auteur asveikau

  3. 4

    Il semble que votre problème a été traité, mais je pense qu'il est toujours utile de mentionner un point de plus. En utilisant le reste de la pince sorties de rand à une plage spécifiée sera généralement provoquer des biais dans les résultats. Pour être plus précis, si la gamme de la génératrice (RAND_MAX dans le cas de C ou C++) n'est pas un multiple de la plage que vous êtes de serrage, certaines sorties se produire plus souvent que les autres. Pour comparaison, envisager d'essayer de diviser 11 bonbons équitablement entre les 3 enfants (sans casser les en morceaux). La seule façon vous pouvez le faire n'est PAS la main sur certains des bonbons. De même, avec un générateur de nombre aléatoire, la seule façon d'obtenir une distribution égale de votre sortie est de ne pas utiliser certaines des entrées.

    int rand_lim(int limit) {
/* return a random number between 0 and limit inclusive.
 */
    int divisor = RAND_MAX/(limit+1);
    int retval;

    do { 
        retval = rand() / divisor;
    } while (retval > limit);

    return retval;
}

    Comme asveikau l'a souligné dans son post, en général, vous voulez utiliser les bits de poids à partir d'un type générateur linéaire à congruence. Les bits de poids faible sont généralement de plus en plus prévisible. En divisant au lieu de prendre un reste, il conserve bits de poids. Même si cela ne veut avoir une boucle while, il est souvent exécute qu'une seule fois, et rarement plus de deux fois, de sorte que son impact sur les performances est assez minime.

    De savoir si cela en vaut la peine dépend de l'utilisation que vous faites de ces numéros, vous générer -- si vous voulez des dés ou des cartes pour un jeu que vos enfants vont jouer une couple de fois, à l'aide d'un reste n'est généralement pas de mal à une chose. Si vous essayez de faire une sorte de simulation de Monte Carlo (par exemple), vous voudrez probablement être un peu plus prudent quand même...

    Java est java.util.Random.nextInt(int) a aussi une très intéressante mise en œuvre de l'impartialité du choix d'un nombre aléatoire entre 0 et n. Comme pour les bits de poids fort ... voir mon commentaire sur asveikau de réponse. Je n'ai pas vu une libc dans un tout qui a rendu la vraie basse-ordre des bits du mot d'état. Et il y a des producteurs qui ont de faibles bits d'ordre élevé. C ne vous garantit pas un LCG pour rand().
    ne garantit pas beaucoup de chose à propos de rand() -- en fait, à une époque, elle avait vraiment une mauvaise générateur comme un exemple, et les textes que apparemment convaincu au moins un peu de maîtres d'œuvre qui mieux générateur n'était pas autorisé. Néanmoins, bas-bits afin d'être pire que le supérieur de l'ordre des bits est assez commun que le maintien de l'ordre supérieur bits est une bonne règle de base. Tandis que certaines implémentations de rand() throw quelques bits d'ordre inférieur, 1), elle est souvent insuffisante, et 2) encore quelques-uns n'en ont pas.
    Et quelques générateurs ont faible de bits d'ordre élevé. Où les résultats seront pire que ce que vous avez commencé avec. Le meilleur conseil pour C serait probablement pour éviter le haut-RNG complètement car il n'est pas spécifié n'importe où, et vous pourriez obtenir quelque chose de BIEN pour RANDU. Encore, beaucoup de gens ne comprennent pas quelque chose à propos de nombres aléatoires et des généralisations de "ne Jamais faire cela" tri sont dommageables dans ces cas. En général, l'ingérence de générateurs sans la moindre idée ne fait qu'empirer les choses, pas mieux.

    OriginalL'auteur Jerry Coffin