WIP: feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. #5340

Open
tcharlss wants to merge 1 commits from dev/hasard_fixe into master
tcharlss commented 6 days ago
Owner

À la différence de {par hasard} qui change l'ordre à chaque recalcul, l'ordre de {par hasard_fixe} persiste au court du temps.

Ainsi dans une pagination, on conserve l'ordre en faisant des allers retours sur les pages.

Edit : la seed est générée en fonction de Ymd, autrement dit l'aléatoire change chaque jour. Ça peut se changer facilement.


Nb : c'est inspiré de ce que fait le plugin pseudo_hasard, mais en générique.
Me suis dit que ça pourrait être pratique dans le core.

À noter :

  • L'ordre aléatoire pourrait être mis à jour de façon journalière en ajoutant le numéro du jour dans la seed je suppose, s'il y a besoin. Enfin un truc du genre.
  • C'est pas exactement le même aléatoire entre mysql et sqlite. J'ai pas été voir l'algorithme derrière RAND(seed) pour voir si ça peut être reproduit exactement à l'identique en php.
À la différence de `{par hasard}` qui change l'ordre à chaque recalcul, l'ordre de `{par hasard_fixe}` persiste au court du temps. Ainsi dans une pagination, on conserve l'ordre en faisant des allers retours sur les pages. Edit : la seed est générée en fonction de `Ymd`, autrement dit l'aléatoire change chaque jour. Ça peut se changer facilement. ---- Nb : c'est inspiré de ce que fait le plugin pseudo_hasard, mais en générique. Me suis dit que ça pourrait être pratique dans le core. À noter : * <strike>L'ordre aléatoire pourrait être mis à jour de façon journalière en ajoutant le numéro du jour dans la seed je suppose, s'il y a besoin. Enfin un truc du genre.</strike> * C'est pas exactement le même aléatoire entre mysql et sqlite. J'ai pas été voir l'algorithme derrière RAND(seed) pour voir si ça peut être reproduit exactement à l'identique en php.
tcharlss added 1 commit 6 days ago
5dfa8f7779 feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente.
tcharlss changed title from feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. to WIP: feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. 6 days ago
Poster
Owner

Pour tester / comparer :

<B_hasard>
#ANCRE_PAGINATION
<BOUCLE_hasard(ARTICLES) {par hasard, date} {pagination 10} {", "}>#ID_ARTICLE</BOUCLE_hasard>
<nav class="pagination">#PAGINATION</nav>
</B_hasard>

<B_hasard_fixe>
#ANCRE_PAGINATION
<BOUCLE_hasard_fixe(ARTICLES) {par hasard_fixe, date} {pagination 10} {", "}>#ID_ARTICLE</BOUCLE_hasard_fixe>
<nav class="pagination">#PAGINATION</nav>
</B_hasard_fixe>

Je laisse en WIP le temps d'en discuter et aussi parcequ'il faut que je vérifie quelque chose :^

Pour tester / comparer : ```html <B_hasard> #ANCRE_PAGINATION <BOUCLE_hasard(ARTICLES) {par hasard, date} {pagination 10} {", "}>#ID_ARTICLE</BOUCLE_hasard> <nav class="pagination">#PAGINATION</nav> </B_hasard> <B_hasard_fixe> #ANCRE_PAGINATION <BOUCLE_hasard_fixe(ARTICLES) {par hasard_fixe, date} {pagination 10} {", "}>#ID_ARTICLE</BOUCLE_hasard_fixe> <nav class="pagination">#PAGINATION</nav> </B_hasard_fixe> ``` Je laisse en WIP le temps d'en discuter et aussi parcequ'il faut que je vérifie quelque chose :^
tcharlss force-pushed dev/hasard_fixe from 5dfa8f7779 to 78134767aa 6 days ago
tcharlss added 1 commit 6 days ago
1078eb1c39 feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente.
tcharlss changed title from WIP: feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. to feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. 6 days ago
b_b approved these changes 6 days ago
rastapopoulos approved these changes 6 days ago
marcimat reviewed 5 days ago
$seed_objet = ($id_table ? $id_table.'.'.$cle_objet : 0);
$seed_boucle = base_convert(hash('crc32', $id_boucle . $table_objets), 36, 10); // texte transposé en nombre base 10
$seed_periode = date('Ymd'); // pour changer tous les jours
$par_hasard_fixe = "RAND($seed_objet + $seed_boucle + $seed_periode) AS hasard_fixe";
Owner

On ne peut pas calculer le résultat directement du RAND(int) là ?

  • J’ai l’impression que ça écrit RAND(articles.id_article + 1234567890 + 20220922)

Quel est l’intérêt de 'articles.id_article' ?
Quel est l’intérêt de l’addition à faire écrire ?

Autrement dit, pourquoi ne pas mettre 'articles.id_article' dans le CRC32 généré ($seed_boucle)
Et faire l’addition en PHP ?

  • $par_hasard_fixe = 'RAND(' . ($seed_boucle + $seed_periode) . ') AS hasard_fixe';

Ou tout mettre dans le CRC32 ?

$seed = base_convert(hash('crc32', $seed_objet . $id_boucle . $table_objets . $seed_periode), 36, 10);
$par_hasard_fixe = "RAND($seed) AS hasard_fixe";

Y a quelque chose que j’ai pas compris ?

On ne peut pas calculer le résultat directement du `RAND(int)` là ? - J’ai l’impression que ça écrit `RAND(articles.id_article + 1234567890 + 20220922)` Quel est l’intérêt de 'articles.id_article' ? Quel est l’intérêt de l’addition à faire écrire ? Autrement dit, pourquoi ne pas mettre 'articles.id_article' dans le CRC32 généré (`$seed_boucle`) Et faire l’addition en PHP ? - `$par_hasard_fixe = 'RAND(' . ($seed_boucle + $seed_periode) . ') AS hasard_fixe';` Ou tout mettre dans le CRC32 ? ```php $seed = base_convert(hash('crc32', $seed_objet . $id_boucle . $table_objets . $seed_periode), 36, 10); $par_hasard_fixe = "RAND($seed) AS hasard_fixe"; ``` Y a quelque chose que j’ai pas compris ?
Poster
Owner

J’ai l’impression que ça écrit RAND(articles.id_article + 1234567890 + 20220922)

C'est tout à fait ça :) C'est voulu.

articles.id_article, c'est le plus important, c'est la base qui permet d'avoir un nombre aléatoire propre à chaque objet.

Sauf que tout seul ça suffit pas : 2 boucles sur des objets différents mais avec les mêmes ids auraient le même ordre.

Donc à cette valeur qui est évaluée pendant la requête, je rajoute 2 nombres évalués en amont :

  • $seed_boucle correspond au type d'objet et à l'identifiant de la boucle, comme ça résultats différents d'une boucle à l'autre.
  • $seed_periode c'est pour renouveler l'ordre tous les jours. C'est une durée choisie arbitrairement, ça pourrait être 1h, ou alors pas de renouvellement du tout.

Donc voilà, j'espère que ça explique pourquoi il y a une partie dans le CRC32 et pas l'autre.

> J’ai l’impression que ça écrit RAND(articles.id_article + 1234567890 + 20220922) C'est tout à fait ça :) C'est voulu. `articles.id_article`, c'est le plus important, c'est la base qui permet d'avoir un nombre aléatoire propre à chaque objet. Sauf que tout seul ça suffit pas : 2 boucles sur des objets différents mais avec les mêmes ids auraient le même ordre. Donc à cette valeur qui est évaluée pendant la requête, je rajoute 2 nombres évalués en amont : * `$seed_boucle` correspond au type d'objet et à l'identifiant de la boucle, comme ça résultats différents d'une boucle à l'autre. * `$seed_periode` c'est pour renouveler l'ordre tous les jours. C'est une durée choisie arbitrairement, ça pourrait être 1h, ou alors pas de renouvellement du tout. Donc voilà, j'espère que ça explique pourquoi il y a une partie dans le CRC32 et pas l'autre.
cerdic commented 5 days ago
Owner

Oui mais RAND(1234567890 + 20220922) marche aussi bien, avec l'avantage de ne pas réinitialiser le seed à chaque ligne sql, ce qui en principe est bien plus performant.

Et du coup le 1234567890 + 20220922 pourrait être fait en PHP et in fine avoir un RAND(xxxxxxx) d'un seul nombre

Et je me demande si il faut vraiment introduire un nouveau critère ou si ça ne devrait pas être le comportement par défaut de {par hasard} au passage...

Oui mais `RAND(1234567890 + 20220922)` marche aussi bien, avec l'avantage de ne pas réinitialiser le seed à chaque ligne sql, ce qui en principe est bien plus performant. Et du coup le `1234567890 + 20220922` pourrait être fait en PHP et in fine avoir un `RAND(xxxxxxx)` d'un seul nombre Et je me demande si il faut vraiment introduire un nouveau critère ou si ça ne devrait pas être le comportement par défaut de `{par hasard}` au passage...
Owner

Si c'était le comportement de par hasard ça empêcherait d'avoir du vrai hasard qui se réhasarde à chaque calcul (et qui est donc dépendant du temps du cache du morceau de squelette où on le met), par ex pour avoir un contenu au hasard différent à chaque fois (sur un accueil ou ce genre). En tout cas sinon faudrait au moins un paramètre à passer. Ou alors inverser les noms et avoir un {par hasard_complet} qui fasse l'ancien (mais donc cassage de compat de ce qui est en place chez les gens)

Si c'était le comportement de par hasard ça empêcherait d'avoir du vrai hasard qui se réhasarde à chaque calcul (et qui est donc dépendant du temps du cache du morceau de squelette où on le met), par ex pour avoir un contenu au hasard différent à chaque fois (sur un accueil ou ce genre). En tout cas sinon faudrait au moins un paramètre à passer. Ou alors inverser les noms et avoir un {par hasard_complet} qui fasse l'ancien (mais donc cassage de compat de ce qui est en place chez les gens)
Owner

J’ai l’impression que ça écrit RAND(articles.id_article + 1234567890 + 20220922)

C'est tout à fait ça :) C'est voulu.

articles.id_article, c'est le plus important, c'est la base qui permet d'avoir un nombre aléatoire propre à chaque objet.

Bah oui mais non…

Une seed de randomisateur c’est pour initialiser… c’est pas fait pour être initialisé à chaque ligne sql…

En tout cas si tu fais en mysql

Select id_article, rand(1) as hasard FROM spip_articles ORDER BY hasard

Ça marche très bien : tu as pas le même "hasard" pour chaque ligne.

>> J’ai l’impression que ça écrit RAND(articles.id_article + 1234567890 + 20220922) > C'est tout à fait ça :) C'est voulu. > articles.id_article, c'est le plus important, c'est la base qui permet d'avoir un nombre aléatoire propre à chaque objet. Bah oui mais non… Une seed de randomisateur c’est pour initialiser… c’est pas fait pour être initialisé à chaque ligne sql… En tout cas si tu fais en mysql ```sql Select id_article, rand(1) as hasard FROM spip_articles ORDER BY hasard ``` Ça marche très bien : tu as pas le même "hasard" pour chaque ligne.
Poster
Owner

Une seed de randomisateur c’est pour initialiser… c’est pas fait pour être initialisé à chaque ligne sql…

En tout cas si tu fais en mysql

Select id_article, rand(1) as hasard FROM spip_articles ORDER BY hasard

Ça marche très bien : tu as pas le même "hasard" pour chaque ligne.

Ah oui je viens de voir ça, ça partait d'une méconception de ma part.

Donc ok la seed peut être entièrement donnée en amon, sans le id_patate.
Je vais amender.

> Une seed de randomisateur c’est pour initialiser… c’est pas fait pour être initialisé à chaque ligne sql… > >En tout cas si tu fais en mysql > >Select id_article, rand(1) as hasard FROM spip_articles ORDER BY hasard > >Ça marche très bien : tu as pas le même "hasard" pour chaque ligne. Ah oui je viens de voir ça, ça partait d'une méconception de ma part. Donc ok la seed peut être entièrement donnée en amon, sans le id_patate. Je vais amender.
Owner

Mais je pense que tu vas avoir un gros soucis avec SQLite

Car ne connaissant pas rand(?int) on le déclare en fonction PHP comme tu as vu.

SQLite connait random(), sans paramètre https://www.sqlite.org/lang_corefunc.html#random mais qui ne permet pas d’initialiser la graine.

Mais la fonction PHP va effectivement être appelée à chaque ligne du SQL, mais tu ne veux initialiser la graine que la première fois idéalement, sinon il va te sortir toujours le même nombre…

Mais je pense que tu vas avoir un gros soucis avec SQLite Car ne connaissant pas `rand(?int)` on le déclare en fonction PHP comme tu as vu. SQLite connait `random()`, sans paramètre https://www.sqlite.org/lang_corefunc.html#random mais qui ne permet pas d’initialiser la graine. Mais la fonction PHP va effectivement être appelée à chaque ligne du SQL, mais tu ne veux initialiser la graine que la première fois idéalement, sinon il va te sortir toujours le même nombre…
Poster
Owner

Mais je pense que tu vas avoir un gros soucis avec SQLite

En effet, en sqlite ça fonctionne en utilisant un nom de colonne dans la graine, mais pas si on en utilise une fixe.

Et je vois pas très bien s'il est possible de feinter au niveau de la fonction PHP avec la 2ème méthode.

> Mais je pense que tu vas avoir un gros soucis avec SQLite En effet, en sqlite ça fonctionne en utilisant un nom de colonne dans la graine, mais pas si on en utilise une fixe. Et je vois pas très bien s'il est possible de feinter au niveau de la fonction PHP avec la 2ème méthode.
Poster
Owner

Pour me faire une idée j'ai comparé la durée des requêtes sur une base ayant 50 000 articles.
Pour rappel :

  • Sans seed = {par hasard}
  • Seed avec nom de colonne = {par hasard_fixe} version actuelle
  • Seed fixe = {par hasard_fixe} version idéale si SQLite faisait pas chier

Mysql

Là c'est dans une console :

RAND() RAND(N) RAND(id + N)
1ère fois 0.06 0.06 0.08
Fois suivantes 0.05 0.05 0.05

Les requêtes dans l'ordre respectif pour s'amuser à la maison :

SELECT id_article, RAND() haz from spip_articles order by haz;
SELECT id_article, RAND(12345) haz from spip_articles order by haz;
SELECT id_article, RAND(id_article + 12345) haz from spip_articles order by haz;

SQLite

Là c'est les chiffres donnés par le debug de SPIP, avec des vraies boucles :

RAND() RAND( id + N )
0.000489(…) 0.001306(…)

Donc

En MySQL, utiliser un nom de colonne a l'air d'avoir un impact plutôt limité.

En SQLite, la différence est plus visible.

Mais si ça devient un nouveau critère complémentaire à celui existant, et que la doc mentionne cette histoire de perfs en SQLite, c'est jouable non ?

Pour me faire une idée j'ai comparé la durée des requêtes sur une base ayant 50 000 articles. Pour rappel : * Sans seed = `{par hasard}` * Seed avec nom de colonne = `{par hasard_fixe}` version actuelle * Seed fixe = `{par hasard_fixe}` version idéale si SQLite faisait pas chier ## Mysql Là c'est dans une console : || RAND() | RAND(N) | RAND(id + N) | |----|----|----|----| | 1ère fois | 0.06 | 0.06 | 0.08 | | Fois suivantes |0.05 | 0.05 | 0.05 | Les requêtes dans l'ordre respectif pour s'amuser à la maison : ```sql SELECT id_article, RAND() haz from spip_articles order by haz; SELECT id_article, RAND(12345) haz from spip_articles order by haz; SELECT id_article, RAND(id_article + 12345) haz from spip_articles order by haz; ``` ## SQLite Là c'est les chiffres donnés par le debug de SPIP, avec des vraies boucles : | RAND() | RAND( id + N ) | |----|----| | 0.000489(…) | 0.001306(…) | ## Donc En MySQL, utiliser un nom de colonne a l'air d'avoir un impact plutôt limité. En SQLite, la différence est plus visible. Mais si ça devient un nouveau critère complémentaire à celui existant, et que la doc mentionne cette histoire de perfs en SQLite, c'est jouable non ?
Owner

Ce qui me gène c’est que déclarer une graine à chaque entrée, ce n’est pas — a priori du moins — vraiment générer une suite de nombre aléatoires correcte… C’est pas certain qu’il y ait un gros impact dans ce cas ci, mais en théorie c’est pas comme ça qu’on s’en sert.

Et il ne semble pas y avoir de solution correcte pour SQLite pour ça.

Ce qui me gène c’est que déclarer une graine à chaque entrée, ce n’est pas — a priori du moins — vraiment générer une suite de nombre aléatoires correcte… C’est pas certain qu’il y ait un gros impact dans ce cas ci, mais en théorie c’est pas comme ça qu’on s’en sert. Et il ne semble pas y avoir de solution correcte pour SQLite pour ça.
maieul commented 5 days ago
Collaborator

De ce que je comprend, le facteur aleatoire là sera la détermination de la graine, qui est considéré comme suffisament aleatoire si on se base sur la second précise à laquelle on lancé la génération, car on ne peut prévoir à l'avance à quel moment le cache sera recalculé.

(Par contre : pas de piste pour sqlite)

De ce que je comprend, le facteur aleatoire là sera la détermination de la graine, qui est considéré comme suffisament aleatoire si on se base sur la second précise à laquelle on lancé la génération, car on ne peut prévoir à l'avance à quel moment le cache sera recalculé. (Par contre : pas de piste pour sqlite)
Poster
Owner

Quand tu dis c'est pas comme ça qu'on s'en sert, tu veux dire le fait d'utiliser un nom de colonne dans la graine @marcimat ? Ou autre chose ?

Cette possibilité est pourtant mentionnée dans la doc de RAND()
Me semble pas y avoir vu de de contre-indication particulière.

Tiens en relisant au passage, ils disent que s'il s'agit juste d'avoir un ordre aléatoire, alors mettre le RAND() directement dans le ORDER BY, pas dans le SELECT.

Quand tu dis c'est pas comme ça qu'on s'en sert, tu veux dire le fait d'utiliser un nom de colonne dans la graine @marcimat ? Ou autre chose ? Cette possibilité est pourtant mentionnée dans [la doc de RAND()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_rand) Me semble pas y avoir vu de de contre-indication particulière. Tiens en relisant au passage, ils disent que s'il s'agit juste d'avoir un ordre aléatoire, alors mettre le RAND() directement dans le ORDER BY, pas dans le SELECT.
Owner

bah le principe d’un initialiseur, c’est d’initialiser 1 fois pour une suite de N nombres aléatoires ensuite. Pas N fois pour N nombres. Du coup, le comportement prévu de mysql sur RAND(column_name) parait assez étrange, et aussi assez spécifique.

J’ai testé aussi sur MariaDB RAND (sa doc n’indiquait pas forcément autre chose qu’un seed integer, mais ça fonctionne effectivement pareil que Mysql pour le coup)

  • SQLite ne permet pas de définir de seed sur sa fonction random()… bon
  • MSSQL permet une seed (mais pas de colonne)
  • PostrgreSQL a une fonction SETSEED(0.16111981) qui accepte un flottant entre -1.0 et 1.0 (et donc pas de colonne)

Y a pas une implémentation qui semble pareille entre SGBD de ce truc.

Si c’est une solution qui fonctionne… après tout… mais ça semble un rien étonnant.

bah le principe d’un initialiseur, c’est d’initialiser 1 fois pour une suite de N nombres aléatoires ensuite. Pas N fois pour N nombres. Du coup, le comportement prévu de mysql sur `RAND(column_name)` parait assez étrange, et aussi assez spécifique. J’ai testé aussi sur MariaDB [RAND](https://mariadb.com/kb/en/rand/) (sa doc n’indiquait pas forcément autre chose qu’un seed integer, mais ça fonctionne effectivement pareil que Mysql pour le coup) - SQLite ne permet pas de définir de seed sur sa fonction random()… bon - [MSSQL](https://learn.microsoft.com/fr-fr/sql/t-sql/functions/rand-transact-sql?view=sql-server-ver16) permet une seed (mais pas de colonne) - PostrgreSQL a une fonction `SETSEED(0.16111981)` qui accepte un flottant entre -1.0 et 1.0 (et donc pas de colonne) Y a pas une implémentation qui semble pareille entre SGBD de ce truc. Si c’est une solution qui fonctionne… après tout… mais ça semble un rien étonnant.
Poster
Owner

Étant donné que c'est juste une rustine pour faire marcher le truc avec SQLite, ça se ferait de tester le moteur pour utiliser le nom de colonne que si c'est SQLite ? Comme ça, MySQL = un beau RAND() tout propre, SQLite = on fait comme on peut.

Ou c'est pas recommandé d'avoir ce genre de tests éparpillés dans le code ?

Étant donné que c'est juste une rustine pour faire marcher le truc avec SQLite, ça se ferait de tester le moteur pour utiliser le nom de colonne que si c'est SQLite ? Comme ça, MySQL = un beau RAND() tout propre, SQLite = on fait comme on peut. Ou c'est pas recommandé d'avoir ce genre de tests éparpillés dans le code ?
Collaborator

Et je me demande si il faut vraiment introduire un nouveau critère ou si ça ne devrait pas être le comportement par défaut de {par hasard} au passage...

je rejoins Rastapopoulos. Le seul usage que j'ai eu dans ma vie de "par hasard" c'est précisement pour mettre en valeur un truc différent chaque jour (en l'occurence une citation).

> Et je me demande si il faut vraiment introduire un nouveau critère ou si ça ne devrait pas être le comportement par défaut de {par hasard} au passage... je rejoins Rastapopoulos. Le seul usage que j'ai eu dans ma vie de "par hasard" c'est précisement pour mettre en valeur un truc différent chaque jour (en l'occurence une citation).
Owner

oui mais chaque jour différent c'est exactement ce que fait la proposition de @tcharlss

La seule perte de feature c'est si tu veux tu hasard qui varie plus souvent que chaque jour.

Dans ce cas on peut alors choisir de passer un seed complémentaire au critère, qui sera ajouté au seed qu'il calcule. Et du coup tu peux y passer la date en seconde, en minutes, en heures, arrondies à X heures selon la fréquence à laquelle tu veux que ç varie.

Et au final on y gagne en fonctionnalité puisqu'on peut choisir la fréquence de renouvelement du hasard !

Amha que certains sites lors de l'upgrade passent d'un hasard qui change toutes les heures à tous les jours est pas un drame, et ils peuvent corriger la boucle si c'est vraiment important pour eux

oui mais chaque jour différent c'est exactement ce que fait la proposition de @tcharlss La seule perte de feature c'est si tu veux tu hasard qui varie plus souvent que chaque jour. Dans ce cas on peut alors choisir de passer un seed complémentaire au critère, qui sera ajouté au seed qu'il calcule. Et du coup tu peux y passer la date en seconde, en minutes, en heures, arrondies à X heures selon la fréquence à laquelle tu veux que ç varie. Et au final on y gagne en fonctionnalité puisqu'on peut choisir la fréquence de renouvelement du hasard ! Amha que certains sites lors de l'upgrade passent d'un hasard qui change toutes les heures à tous les jours est pas un drame, et ils peuvent corriger la boucle si c'est vraiment important pour eux
Collaborator

@cerdic dans ce cas la ok :)

@cerdic dans ce cas la ok :)
Owner

Oui du coup c'est ce que je disais, si ça remplace à terme le critère faut pouvoir passer un param, et donc si c'est bien possible bah oui c'est super cool et mieux et gogo ! :)

Oui du coup c'est ce que je disais, si ça remplace à terme le critère faut pouvoir passer un param, et donc si c'est bien possible bah oui c'est super cool et mieux et gogo ! :)
JLuc commented 5 days ago

{par hasard 3600} donc pour renouveler le hasard toutes les 3600s (?)

`{par hasard 3600}` donc pour renouveler le hasard toutes les 3600s (?)
Owner

@JLuc non plutôt {par hasard, xxx} ou xxx est un seed lui aussi, ajouté aux autres.

Du coup tu peux faire

  • {par hasard, #ENV{date}|affdate{Y-m-d H:i:s}} pour changer ton seed toutes les secondes
  • {par hasard, #ENV{date}|affdate{Y-m-d H:i:s}} pour changer ton seed toutes les minutes etc.

Mais aussi tu peux passer juste un seed différent sur 2 boucles identiques par ailleurs si tu veux un hasard différent

@JLuc non plutôt `{par hasard, xxx}` ou xxx est un seed lui aussi, ajouté aux autres. Du coup tu peux faire * `{par hasard, #ENV{date}|affdate{Y-m-d H:i:s}}` pour changer ton seed toutes les secondes * `{par hasard, #ENV{date}|affdate{Y-m-d H:i:s}}` pour changer ton seed toutes les minutes etc. Mais aussi tu peux passer juste un seed différent sur 2 boucles identiques par ailleurs si tu veux un hasard différent
Poster
Owner

@cerdic Ok pour le paramètre.

Par contre je me demande si ça risque pas de rebuter les gens de devoir mettre une seed sous la forme #ENV{date}|affdate{Y-m-d H:i:s}}. Ça va être compliqué à expliquer, et surtout à retenir.

La forme proposée par @JLuc a le mérite d'être facilement compréhensible par tout le monde : «je veux renouveler l'alea tous les X minutes ».

(Me semble que des minutes suffisent comme base 99% du temps, en dessous autant pas mettre de seed du tout).

  • {par hasard} = pas de seed comme le critère actuel (ou alors une par défaut = 24h)
  • {par hasard, 1} = renouveler toutes les minutes
  • {par hasard, 60} = renouveler toutes les heures

Voir même accepter les calculs ?

  • {par hasard, 24*60} = renouveler toutes les 24h
  • {par hasard, 1/2} = renouveler toutes les 30s
@cerdic Ok pour le paramètre. Par contre je me demande si ça risque pas de rebuter les gens de devoir mettre une seed sous la forme `#ENV{date}|affdate{Y-m-d H:i:s}}`. Ça va être compliqué à expliquer, et surtout à retenir. La forme proposée par @JLuc a le mérite d'être facilement compréhensible par tout le monde : «je veux renouveler l'alea tous les X minutes ». (Me semble que des minutes suffisent comme base 99% du temps, en dessous autant pas mettre de seed du tout). * `{par hasard}` = pas de seed comme le critère actuel (ou alors une par défaut = 24h) * `{par hasard, 1}` = renouveler toutes les minutes * `{par hasard, 60}` = renouveler toutes les heures Voir même accepter les calculs ? * `{par hasard, 24*60}` = renouveler toutes les 24h * `{par hasard, 1/2}` = renouveler toutes les 30s
JLuc commented 5 days ago

En effet c'est plus puissant pour les devs mais ça peut être coton de documenter {par hasard, seed} pour qui ignore ce qu'est une graine de hasard quand il ne s'agit pas de poésie...
Si l'élan est là pour le raffinement du code, alors peut on trouver une syntaxe et sa variante pour faire cohabiter les 2 formes ?

En effet c'est plus puissant pour les devs mais ça peut être coton de documenter `{par hasard, seed}` pour qui ignore ce qu'est une `graine de hasard` quand il ne s'agit pas de poésie... Si l'élan est là pour le raffinement du code, alors peut on trouver une syntaxe et sa variante pour faire cohabiter les 2 formes ?
JLuc commented 4 days ago

Par exemple :

  • {par hasard, graine #ENV{date}|affdate{Y-m-d H:i:s}}}
  • {par hasard, delai 3600} ; yc {par hasard, delai #ENV{delai}}
Par exemple : - `{par hasard, graine #ENV{date}|affdate{Y-m-d H:i:s}}}` - `{par hasard, delai 3600}` ; yc `{par hasard, delai #ENV{delai}}`
tcharlss changed title from feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. to WIP: feat: un tri {par hasard_fixe} pour trier au hasard mais de façon persistente. 10 hours ago

Reviewers

b_b approved these changes 6 days ago
rastapopoulos approved these changes 6 days ago
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
Sign in to join this conversation.
Loading…
There is no content yet.