Faith a écrit :



Même pas. En déplaçant le cercle, tu vas récupérer d’autres malades.

Ton chiffre va passer à 0, 2, 3 ou 10. Parfois à 1, mais ce sera un autre malade à l’autre extrémité du cercle…

Et de tous ces chiffres, tu ne sauras jamais si celui que tu veux repérer en fait partie ou non.







Tu trompes. Comme je l’ai indiqué, je décris uniquement le cas le plus simple (1 seul cas relativement isolé) pour expliquer le principe. Mais c’est juste pour introduire les bases de ce que l’on appelle la triangulation. Comme je le précise après, il est possible d’étendre la logique pour en traiter plusieurs dans une même zone. Il sont juste traités les uns après les autres. Une fois que l’on en a isolé un, on tire le fil pour en isoler un autre (quand le système répond 2 mais que l’on en connaît déjà un, c’est comme si il n’y en avait qu’un). En pratique, il existera toujours au moins un endroit ou on pourra isoler un cas et, à partir de là, tirer le fil pour les récupérer un par un. L’image du Mastermind est assez bonne. Le principe de résolution est assez proche. La recherche se fait sur le principe de l’algorithme de Montecarlo.



Tout le temps que ça part des coordonnées GPS originales pour afficher le résultat, peut importe la dimension des zones sur lequelles repose l’application en interne. Tout le temps qu’il est garanti que la distance minimale est bien inférieure ou égale à 500m pour les résultats retournés, ça fonctionne pareil.



Sinon, si l’application s’appuie d’une grille pré-découpée et ne fait que recenser le nombre de cas par cellule (sans s’appuyer sur les coordonnées GPS) alors, effectivement, il devient plus difficile de localiser précisément (précision maximale = la taille des cellules). Mais l’application donnerait alors des résultats faux. Les cellules traversées par le rayon à 500m délimitant la zone de résultat ne peuvent être traitées que par le biais un ratio proportionnel à la surface incluse. Ce ne sont plus des valeurs justes. Ce qui, en pratique, peut être acceptable si les cellules sont très petites par rapport aux 500m et que l’extrapolation statistique n’intervient vraiment qu’a la marge. Mais alors, plus les résultats sont exacts, plus la localisation est précise et, sur 500 m, ça ne devrait pas excéder quelques dizaines de mètres pour que les résultats retournés ne soient pas complétement déconnants.



Sinon, sur l’intérêt de localiser un malade, ce n’était pas mon propos. Je suis d’accord sur le fait que ce soit sans intérêt. Mais je pense que, si c’est possible, certains sortiront des cartes. Le nombre de requêtes à effectuer n’est pas vraiment un problème. Ça converge très vite si c’est bien écrit donc il ne faut pas tant de requêtes que ça (surtout si on limite la précision à 10 ou 20 de mètres). il y a de grandes zones vierges. Ce sont donc des îlots qui sont à traiter et non pas un grand maillage serré.



Ça peut devenir problématique pour les relations de voisinage des malades. Il y en a qui ne sont vraiment pas très malins…

psikobare a écrit :



Ben non, pas forcément. Dès que l’app est un peu utilisé, tu te retrouves avec 10 000 personnes par km². L’app donne des infos dans un cercle de 500m de rayon. Donc ern fait c’est “exploitable” que dans les endroits isolés.







Non pas du tout. Globalement ce sont des îlots. Même si ces îlots sont très denses, il reste facile d’isoler les cas en périphérie. A partir de là, on peut tout “détricoter”.



Contrairement à la première impression, la présence d’une multitude de résultats dans une zone restreinte permet au contraire de converger plus rapidement. On cherche à progresser de 1 en 1 et dès qu’il y a plus de résultats qu’attendu, c’est qu’on est allé trop loin et que l’on peut restreindre la zone recherche pour converger sur le point étudié.







psikobare a écrit :



Ça ne marche pas ça. Tu pars du principe que les points ne bougent pas, ou qu’on puisse leur associer une identité que l’on peut retrouver entre deux ping. Mais ce n’est pas le cas.







Non je ne part pas du principe que les points aient une identité. La même identité peut se trouver “flashée” en deux points différents. Dans ce cas on la voit comme deux résultats différents.



En revanche, oui je considère que sur une zone étudié le point étudié est stable. C’est à dire qu’il ne disparaît pas pendant que l’on essaie de le localiser. Les points qui disparaissent (ou qui se déplacent, ça revient au même) ne peuvent pas être localisés ainsi. Si le système est vraiment en temps réel, alors oui c’est une grosse limite de ce que je décris. Seuls les points fixes peuvent être localisés. Mais, ce sont aussi les seuls qui soient potentiellement identifiables et pour lesquels un identité peut être devinée, donc les seuls potentiellement dignes “d’intérêt”.



Ce que tu soulève est le talon d’Achile de l’approche. Vu que la progression sur une zone se fait de point en point, si le système est très dynamique, et que les points de références disparaissent, ça oblige à revenir en arrière ou repartir du bord de l’îlot, ce qui peut empêcher toute progression.







psikobare a écrit :



Si par chance tu arrive à isoler un point de donnée, faut encore le relier à une identité. Étant donné que l’app ne fuite aucune donnée, c’est juste débile d’annoncer qu’elle permet de retrouver une information sur qui que ce soit.







Quand la position pointe sur un bâtiment, voir une maison individuelle, ça identifie quand même un peu, et justement, là ce sont des points fixes…







psikobare a écrit :



Ben si, la complexité de l’algorithme évolue exponentiellement avec le nombre d’utilisateurs. Donc un throttling minimal rend caduque tout exploitation.







La complexité est constante quelque soit le nombre d’utilisateurs. Le nombre de requêtes augmente en fonction du nombre d’utilisateurs (plus de points à localiser) mais sur une zone données le nombre de requêtes par utilisateur est inversement proportionnelle au nombre d’utilisateurs présents dans cette zone (les positions convergent plus rapidement).



Le nombre de requêtes dépend plus de la surface à couvrir plus que du nombre d’utilisateurs présents dans cette surface et il n’augmente pas exponentiellement en fonction du nombre d’utilisateurs. Plus il y a d’utilisateur, meilleur est le rendement. On aurait plutôt à faire à un profil de courbe de type logarithmique plutôt qu’exponentiel. C’est à dire tout l’inverse.

Touriste, tu, me fais bien rire " />



La résolution de ce genre de problèmes, ça touche souvent le le cœur de mon métier. Par exemple, si tu défragmente des disques sous avec le défragmenteur Windows, tu fais tourner la base code que j’ai créé il y a maintenant 32 ans. Pour VMS de Digital à l’époque, et c’est encore la même base de code aujourd’hui. Si tu est développeur Java, ou si tu travaille avec BD Oracle par exemple, la aussi tu fais probablement tourner pas mal de choses dont certains algos repose sur une conception faite par un touriste. Et surtout, attention si tu prend le train, la plateforme qui permettant plannification des trains, leur constitution et l’affectation des conducteurs avait été conçue par le même touriste.



Je n’ai jamais parlé de complexité de code! Quand je dis que ça converge, c’est qu’il n’y a pas de récursion ou de branches parallèles à explorer pour aboutir à une solution. Ce sont de simples boucles imbriquées qui convergent vers une solution unique sur chaque point. Leur profondeur maximale est connue et limitée. Plus il y a de points, et plus ils sont concentrés, plus la profondeur nécessaire pour traiter individuellement chaque point diminue.



Sinon, j’arrête là. C’est relativement simple et tu veux absolument que ce soit complexe. C’est fatiguant de parler dans le vide.