Générateur de nombre décimal aléatoire

Si la borne minimale n'est pas strictement inférieure à la maximale, la tâche échoue avec invalid_input au lieu d'inventer un ordre.

Comment un générateur congruentiel linéaire à graine devient un décimal

Un générateur de nombre décimal aléatoire que l'on ne peut pas rejouer est un passif dans les tests, les corrigés et les carnets de simulation. Il fait avancer un générateur congruentiel linéaire 32 bits dont les constantes sont le couple 1664525 et 1013904223 de Numerical Recipes, prises modulo deux à la puissance trente-deux. Une étape de la récurrence produit un entier non signé X, que l'on divise par deux à la puissance trente-deux pour obtenir un échantillon u de l'intervalle unité, dans la plage semi-ouverte de zéro inclus à un exclu. La précision facultative arrondit ensuite le décimal affiché entre zéro et douze chiffres fractionnaires afin que les goldens et les tableurs comparent octet pour octet. Cet endpoint refuse donc la source aléatoire de l'hôte et l'horloge système. Cet échantillon unitaire est ensuite mis à l'échelle de l'intervalle de l'appelant par l'application affine valeur égale à minimum plus u fois la largeur maximum moins minimum. Avant tout arrondi, le décimal brut vit donc dans l'intervalle semi-ouvert qui inclut le minimum et exclut le maximum. La même graine, les mêmes bornes et la même précision donnent toujours le même unit_interval et le même value sur tout runtime qui implémente la multiplication-addition 32 bits de la même façon, ce qui est exactement le contrat dont une assertion d'intégration continue a besoin. Rien dans le chemin n'est stochastique au niveau du système d'exploitation ; deux workers auxquels on donne le même corps JSON ne peuvent pas diverger.

Contrat d'entrée, bornes, précision et comportement d'erreur

Les bornes égales et l'intervalle inversé sont tous deux rejetés, car une largeur nulle ou négative ne définit pas un tirage uniforme et inventer un échange cacherait un bogue de l'appelant. L'arrondi après la mise à l'échelle peut tomber exactement sur une extrémité ; traitez la valeur affichée comme un décimal au nombre de décimales demandé, non comme une promesse que la borne supérieure exclusive survive à tout arrondi. L'échec de validation n'est pas facturé. Associez la graine renvoyée à vos propres registres si vous devez prouver qu'une relecture ultérieure a utilisé le même flux. Envoyez par POST un corps JSON avec trois champs obligatoires. minimum est la borne inférieure de l'intervalle et peut aussi arriver comme min, lower ou lo. maximum est la borne supérieure et peut aussi arriver comme max, upper ou hi. seed est la graine du générateur et peut aussi arriver comme key ou salt. Un champ facultatif precision, accepté aussi comme decimals, places ou digits, fixe le nombre de chiffres fractionnaires du décimal renvoyé ; il vaut dix par défaut et doit être un entier de zéro à douze. Chaque champ numérique peut être un nombre JSON ou une chaîne numérique ; les valeurs non finies, les chaînes vides et les champs obligatoires manquants échouent avec invalid_input qui nomme le champ. La règle géométrique dure est que minimum doit être strictement inférieur à maximum. En cas de succès le corps répète le minimum et le maximum analysés, la graine 32 bits non signée qui est réellement entrée dans la récurrence, et la précision appliquée. Il renvoie aussi unit_interval, le u brut arrondi à douze décimales pour inspection, value, le décimal mis à l'échelle arrondi à la précision demandée, et une courte chaîne formula qui reformule l'application affine. Les appels réussis utilisent le tarif de base publié $0.002.

Où un tirage décimal rejouable justifie son emploi

Chaque appel API réussi coûte $0.002 ; une entrée invalide ne consomme pas de solde. L'outil n'est pas une source aléatoire cryptographique, ni un générateur de vecteurs multi-échantillons, ni un remplacement d'une bibliothèque Monte Carlo complète : il renvoie un décimal par requête.