YBoy360 a écrit 673 commentaires

Source ? Car cela semblait démenti jusqu'à présent.

https://academic.oup.com/nsr/advance-article/doi/10.1093/nsr/nwaa036/5775463

Si ceux qui démentent sont les mêmes qui émettent des réserves sur l'efficacité de la chloroquine …

Je ne vois pas le rapport. Le but d'une simulation est d'essayer de coller au maximum à la réalité en tenant compte des facteurs connus et facilement reproductibles.

On sait que si le nombre de patients ayant besoin d'assistance respiratoire dépasse les capacités hospitalières, le nombre de décès sera bien plus élevé qu'en temps normal.

Donc un modèle un minimum crédible dépend de ce facteur de charge à un instant donné. C'est triste mais c'est la réalité des choses. Comme c'est une simulation, je ne vois pas l'implication éthique dedans qui incombera hélas uniquement à l'équipe soignante.

Pour l'Italie, le nombre de lits est pas important pendant le pic. Donc ça ne change pas la date. Je ferais évoluer le modèle pour la France.

Dans notre entreprise, il y avait 6 cas suspectés lundi qui ont des symptômes. J'ai la gueule de bois, mais pas de fièvre (et je ne me compte pas. Un nombre substantiel de personnes toussait aussi). Il y a 80 personnes au total en France. Nous avons fermé et pris toutes les mesures nécessaires.

Donc lundi, déjà dans mon entourage professionnel, une proportion non négligeable… ça vaut ce que ça vaut.

Si les symptômes du virus sont effectifs (désolé pour ce mot) après 10 jours, avec une variance de 5 jours (et pas 3 comme je l'ai marqué plus haut), on a la courbe "théorique" dans l'autre commentaire :

https://linuxfr.org/nodes/119702/comments/1802877

à partir du moment où on observe 1% de mort par rapport au nombre de mort final, le nombre d'infecté est du genre de 10%.

Honnêtement, j'espère ne pas trop me tromper, car c'est un résultat optimiste.

Ces taux de mortalité viennent des études scientifiques. Par exemple, cette étude publiée chez Nature avance 1,4% : https://www.nature.com/articles/s41591-020-0822-7.

L'article en question pose une simple division comme postulat…

On n'a pas de mesure très précise mais on commence quand même à avoir une idée de l'ordre de grandeur. Il y a eu des cas où on a testé toute la population après une vague d'épidémie (paquebot de croisière mis en quarantaine, quelques petites villes italiennes pour lesquelles la vague est passée). L'ordre de grandeur, c'est environ 50% des contaminés ne vont pas développer de symptômes (et 50% des contaminations par une personne qui va développer des symptômes se fait avant l'apparition des symptômes => 75% des contaminations se fait par une personne qui ne présente pas de symptôme). Quand je parle de 50%, ça sera peut-être 30% ou 70%, mais en tout cas, ça paraît très peu probable qu'il y ait dix fois plus de contaminés sans symptômes.

C'est très intéressant, seulement, il y a 3 "mais" :

• les tests mettent 4 jours à donner des résultats, comment établir une vraie mesure dans ces conditions ?
• Le virus à 2 souches, celle qui sévi en Europe est bien plus virulente que pour la Corée ou pour les confinés du paquebot.
• Chloroquine a été massivement utilisée en Corée.

La forme de la courbe dépend de R0, qui dépend des mesures de confinement. Et la courbe du nombre de malades ne dépend pas du nombre de lits. Le nombre de morts, par contre, dépend du nombre de malades et du nombre de lits. Et c'est très important de respecter les mesures de précaution pour limiter le nombre de malades, et surtout éviter de surcharger les hôpitaux.

Oui, seulement je trouve cynique de parler de nombre de lits dans une simulation. Elle implique des décisions éthiques. Je ne veux pas parler d’hôpital, on verra à la fin qui avait la bonne stratégie.

On est encore très très loin d'avoir 20% de la population infectée.

On verra dans 2 jours.

d'où tu sors ce taux de mortalité ??? le taux que je calcule est le même que la grippe (0,002). On a AUCUNE information sur ce taux, puisqu'il dépend du nombre total de porteurs sains qui n'est pas mesuré …

Bien sûr que les hôpitaux ont une influence sur ce taux, mais ce n'est pas ce que je dis : La forme de la courbe ne dépend pas de ce taux … On peut donc facilement déterminer le moment où la courbe s'infléchie, qqs le nombre de lits.

Pour l'Italie, ça semble être demain (j'ai mal lu le graphe lors de l'envoie) c.a.d. le 21 .. Pour l'Espagne et la France, la variance est encore trop importante. J'ai tout mis sur github.

Pour les mesures de confinement, elles sont très importante en début d'épidémie. Une fois que 20 % de la population est infectée, elles permettent aussi de protéger les populations sensibles. Et les lits d’hôpitaux sont, bien sûr, très important pour limiter le nombre de mort. Tu vas sur un terrain où personne ne veut s'engager.

J'ai mis le tout sur github :
https://github.com/Taack/coronavirus

On crée une série en respectant les principes ci-dessus, voilà ce que ça donne:

Un graphique vaut mieux qu'un long discourt, je résume la démarche théorique :

Concernant le nombre d'infectés

• Accélération du virus est une constante, dont la formule est Acc=PUISSANCE(2;1/2.5)
• la "demie-vie" est =LOG(PopulationTotal;Acc)
• le nombre d'infecté pour un jour est Fj=Fj-1+Fj-1*(Acc-1)*(1-RatioDesInfectés)
• le ratio des infecté est RatioDesInfectés = =(Fj)/(PopulationTatal)

Concernant le nombre de mort

• on convolue le nombre d'infectés obtenu par une gaussienne centrée en 10 et de largeur 3.

Je peux vous filer l'ODS si vous voulez … Dites moi comment faire pour l'envoyer..

P-e, mais une grosse part de la population est déjà infectée, les mesures ont été bien trop tardive. Elles vont quand même p-e infléchir la courbe dans quelques jours.

C'est l'intégrale d'une gaussienne centrée en LOG("POPULATION";PUISSANCE(2;1/2,5)).

On part du principe comme évoqué dans le précédant journal que le virus :

• à l'instant 0 multiplie par 2 le nombre d'infectés tous les 2,5 jours ;
• au début des mesures de prévention, une part importante de la population est déjà infectée donc elles n'ont que très peu d'effets ;

on peut établir que nombre d'infectés >> nombre de mort (c'est une très bonne nouvelle) et que la propagation s'apparente à la diffusion d'information au sein d'un mouvement brownien.

• la vitesse de propagation du virus est proportionnelle au reste de la population à infecté, sur la population infectés (si 10 % infectés, le virus se propagera à 90 % de sa vitesse d'origine, et ainsi de suite) ;
• le nombre de mort est proportionnel (quelque soit le nombre de lits d’hôpital) au nombre d'infectés décalé de plusieurs jours.

Le moment ou la dérivé seconde du nombre d'infecté est nul (le fameux pic) est
LOG(;PUISSANCE(2;1/2,5))

Il y a pas de code (enfin 1 ligne)…

Pour l'Espagne, la distribution est :

spain = c(1, 2, 8, 10, 17, 30, 36, 55, 86, 133, 196, 294, 342, 533, 638, 803)
simulation2 = pnorm(1:30, mean = 20.12, sd = 5.09) * 1600 / 0.4

plot(simulation2)
points(spain, pch = "*")

Il n'y a rien de plus… Je minimise à la main la variance :

var(simulation2 - spain)
C'est moins fiable pour l'Espagne. Si on trace la courbe, on obtient : 3896 morts, et un pic dans 4 jours.

C'est simplement la distribution normal (c.f. précédant journal). La courbe est simplement :

pnorm(1:50, mean = 30.07, sd = 7.447) * 3500 / 0.4

sa dérivé indique le nombre de mort par jours :

d = c(-1, 1)
mItaly = convolve(pnorm(1:50, mean = 30.07, sd = 7.447) * 3500 / 0.4, d, type = "filter")


Il y a l'Espagne qui m'intéresse en priorité. Je vais le faire pour la France après.

Si le nombre de lits est suffisant pendant toute la pandémie, le nombre de décès reste proportionnel au nombre d'infectés (mais décalé dans le temps). De même si le nombre de lits est très inférieur au nombre de cas graves, le nombre de décès reste proportionnel au nombre d'infectés (toujours décalé dans le temps, peut-être un temps plus court). Par contre, la létalité constatée du virus sera différente.

Le décalage entre la courbe du nombre d'infecté et celle du nombre de décès peut-être significatif. Tant que le nombre de décès est faible, aucune mesure n'est prise, et la courbe des infectés évolue librement comme l'intégrale d'une gaussienne.

voir le lien simulation du Washington Post : ça montre graphiquement l'évolution d'un virus.

Oui, la Corée du Sud à de plus l'expérience du SARS et du H1N1.

Juste pour compléter ce que je disais plus haut, pour une population de 10 000 000 000 d'habitants, avec un doublement des décès tous les 2,5 jours (donc un doublement des infectés tous les 2,5 jours), si on ne fait rien, le moment d'inflexion de la courbe est de 83 jours :

LOG(10000000000;PUISSANCE(2;1/2,5))

C'est en supposant que les infectés se déplacent au hasard (ce qui n'est plus le cas), que personne n'est isolé et a autant de chance de rencontrer tous les autres habitants.

La demie vie du virus pour une population de N membre, avec un facteur de propagation F, c'est

Log(N, F) (Log base F …)

Je me rappelle doucement de mes vieux cours.

Pour 1000, ça fait 9,96 pour 1 000 000 ça fait 19,93. Avec un facteur de propagation de 2.

Hilbert, c'est bien pour les informations discontinues.

Une chose qui n'est pas clair dans ce que j'ai écrit, c'est que le nombre d'infectés dont je parle, c'est proportionnel au nombre de morts. Ce n'est pas le nombre d'infectés à un instant T (qui est sa dérivé), c'est bien le nombre d'infecté qu'il y a eu, au total.

Ce nombre d'infecté total est limité par la taille de la population.

Lorsque 50 % de la population est malade, le virus aura une accélération de propagation moitié inférieur à lorsque le virus apparaît. pour 75% 1/4, 90% 1/10.. Par ce qu'il tombe sur des cas déjà infecté.

La vitesse de propagation est proportionnelle à l'accélération par le nombre de malade.

Pour une population de 1000, avec une accélération initiale de 2 infectés pour un infecté :

Acc	#Infectés	#Non Infecté	Ratio
2	1	999	1,001001001001
2	1,998	997,002	1,002
2	3,98802395209581	995,011976047904	1,00399201596806
2	7,94433399602386	991,055666003976	1,00795228628231
2	15,7633136094675	983,236686390533	1,01577909270217
2	31,0368932038835	967,963106796116	1,03106796116505
2	60,2033898305085	938,796610169491	1,06026365348399
2	113,563055062167	885,436944937833	1,11367673179396
2	203,942583732057	795,057416267943	1,20414673046252
2	338,733774834437	660,266225165563	1,33907284768212
2	505,922848664689	493,077151335312	1,50642927794263
2	671,684832567302	327,315167432698	1,67235718975706
2	803,279151943463	195,720848056537	1,80408323517864
2	890,512295973885	108,487704026115	1,89140369967356
2	941,641698308595	57,3583016914049	1,94258428259119
2	969,47319789137	29,52680210863	1,9704436415329
2	984,015150148796	14,984849851204	1,9850001502991
2	991,450957825396	7,54904217460444	1,99244340122662
2	995,211163554279	3,78883644572136	1,9962073709252
2	997,101982539036	1,89801746096418	1,99810008262166
2	998,050088893208	0,949911106791888	1,99904913803124
2	998,52481853061	0,475181469389668	1,99952434287348

Si on fait une courbe, on obtiens une symétrie autours 500.

Normalement la fonction Jn n'est pas forcement hyper symétrique, car elle n'est pas continue. Il faudrait convoluer les instants de la mort avec une fonction continue et dont l'intégrale est 1 sur 24h pour vraiment avoir une fonction symétrique en Jn.

Bref, si le max de mort est à 22h le jour n, le jour n+1 ne sera pas parfaitement symétrique avec le jour n-1…

ça manque de Y tout ça..

Je n'aurais pas appelé "branchless" un algorithme avec des boucles for. Pour

    result += v * usable_column[i];
    usable_column[i] *= (v != 0);

Ce n'est pas évident que ce branchement soit inliné, il aurait été bien d'avoir un extrait du code assembleur, et de comparer avec une version sans multiplication.

Pour faire vraiment de l'optimisation CPU, il faut presque obligatoirement un "profiler" pour observer l'impact des accès mémoire sur le binaire optimisé. Il faut donc faire un peu d'assembleur, c'est la partie la plus intéressante. Enfin, le C ou même le Fortran simplifie ce travail et offre plus de liberté par rapport au C++ (on peut toujours faire du C dans du C++ ??).

Le meilleur est celui qui accède à la mémoire de façon contiguë, en en faisant le moins. Comme les matrices sont de tailles fixes, on peut imaginer d'autres optimisations, du style en C, accéder à la prochaine adresse pour chauffer le cache sans rien faire, du prefetch, donner de la visibilité au compilateur en déroulant un peu ces boucles ou en utilisant des indices connus à la compilation.. , mais on navigue en aveugle sans un extrait du code désassemblé.

Micronaut ajoute le byte code en utilisant l'infrastructure que propose Gradle sans plugin via les "annotationProcessor". On peut faire du build incremental, agréger ces annotationProcessor pour reconstruire rapidement.. Mais gradle ne sait pas recharger le contexte, il sait juste Builder et redémarrer le tout en cas de changement.

L'impacte est limité pour Micronaute, car le temps de redémarrage est de quelques courtes secondes.

Je ne connais pas la complexité de développement d'un plugin Gradle qui pourrait faire le rechargement de contexte pour Micronaut.

Concernant JRebel, on peut s'en passer pour les applications Grails (qui est bien plus lourd que Micronaut). On utilise finalement Spring DevTools, et on optimise.

Tu t'embarques dans les comparaisons puisque tu parles de live coding :)

On utilise JRebel avec Grails. Il y a d'autres solutions comme utiliser Spring DevTools (qui fonctionne pour les applications SpringBoot), mais dans notre cas, l'application est assez volumineuse et le rechargement des classes se fait en plusieurs longues secondes. Ce n'est pas optimal, mais on survit.

C'est donc la grosse différence entre les framework (je ne connais pas trop le pour et le contre des 2 approches) :

• Quarkus modifie le bytecode directement lors du build, il utilise un plugin gradle ou maven pour pouvoir le faire, ce plugin sait comment recharger les classes modifiées ;
• Micronaut enrichi le bytecode pendant l'analyse des sources. Il n'utilise pas de plugin Gradle / Maven et ne connait pas les classes à recharger.

ça rend Quarkus intéressant pour le coup, ne serait-ce que pour voir comment ça fonctionne.

Gitea nous convient pour le moment. Je l'ai choisi car il est très simple à configurer et simple à déployer, et nous n'avons pas beaucoup de test d'intégration qui justifierai autre chose (pour le moment).

Gitlab embarque son propre Postgres … Il y a un fichier de configuration de 2300 lignes, contre 5 lignes pour Gitea.

on a minutieusement enchaîné les petites erreurs pour péter mon WE :
- Nous avons installé le paquet Gitlab de Debian sur une Debian Stretch sur ARM à l’origine. C'était un bon choix car ce package utilisait la version Debian de Postgres et était disponible sur ARM.
- Le serveur n'était pas très stable, aussi je n'aime pas l'ancienne interface de Gitlab, j'arrive jamais à retrouver ce que je cherche, et je trouve ça lent. Alors, je décide de migrer sur Gitea…
- Pour la migration, il fallait disposer de la version 4 de l'API de Gitlab. Donc on décide de mettre à jour notre Gitlab.

Et là, c'est le drame …
- d'abord je le backup du serveur
- La mise à jour du paquet ne fonctionnant pas, je mets à jour la distribution. Tout ce passe nickel, sauf que Gitlab n'est toujours pas installable…
- Je remets encore à jour le serveur (vers SID), idem
- Je cherche à installer la version officielle, mais pas d'image pour l'architecture ARM.

En installant la version officiel sur un serveur x86-64, je constate la complexité délirante de ce produit : il faut 5 minutes au serveur pour "générer sa configuration"… Jamais je n'aurais installé Gitlab si j'avais assisté à ça. Ce n'est pas moi qui ai installé le serveur, et je comprends bien que les packageur officiel de Debian ont du se tirer une balle en essayant de packager cette bouse.

N'arrivant pas à importer la backup Postgres dans la version embedded de Postgres, je décide de remettre le backup. Et là, problème :
pour installer le backup, il faut créer une instance ARM (identique à celle d'où provient le backup), cool, sauf que Scaleway n'a plus d'instance ARM depuis un baille, et comme c'est installé dans la partition Root, je ne peux rien en faire.

Donc ce We, je vais me coltiner le modèle de Gitlab, l'API de Gitea, et faire l'importation de ce que je peux (utilisateur, clés, repos, organisation, tickets). Je fais ça en Groovy pour l'info. C'est pas compliqué, mais très chiant.

Au final, j'aime bien Debian et ARM. Il faut juste faire très attention lors du choix d'un logiciel, surtout aussi fondamental qu'une forge qui doit être pérenne, à la complexité de celui-ci.

Clairement Gitlab est trop complexe à intégrer. Puis j'aime vraiment pas avoir Postgres10.2 installé, alors que Debian propose déjà 3 versions de Postgres..

Je connais pas bien Quarkus, il semble y avoir peu de différences. Les 2 jouissent d'un développement très actif, et ont plein de dépendances communes.

à l’avantage de Micronaut, je dirais:
- support Groovy, Gorm, Kotlin (pour moi c'est important)
- plus de fonctionnalités intégrées (Micronaut Data par exemple, il y a Panache pour QuarkUs, mais peut-on utiliser les Validator pour autre chose qu'Hibernate ??)
- doc qui montre le code dans les langages supporté, et que je trouve très bien faite. Moins bordélique que celle de QuarkUS
- il parle moins de Kubernate, mais plus d'ASM.
- L'auteur

à l'avantage de Quarkus :
- peut-être plus minimaliste
- plus orienté performance

Il faut que je regarde comment fonctionne l'injection de dépendance pour vraiment les différencier.

3615MaVie, Je ne peux vraiment pas le faire en ce moment, pour une histoire de Gitlab qui a craché, et de backup qui n'est pas restaurable (merci ARM, merci Gitlab, merci Scaleway, ça c'est dit …).

Pour nous c'est critique, je pense que ça va m'occuper le WE. Je passe sur Gitea pour le moment, après je le fais, promis (et j'arrête de fumer aussi).

Merci pour ces corrections.

Je ferais un autre journal, bien rédigé, pour expliquer comment fonctionne l'AOP à la compilation dans Micronaut, il n'y a pas beaucoup de ressources sur ce sujet.

Avec le support des DSL, on peut vraiment faire des miracles avec ce cadriciel (ça mérite un autre journal, avec des exemples de code).