Reprise du message précédent :
Comme on l'a déjà dis a moins que tu sois dans la compétition, l'AOC c'est un bon moyen s'initier à un autre langage

Ah le théorème des résidus, trop puissant ce truc, dernier truc que j'ai vu en maths.

j'arrive pas à faire la partie un de l'advent of code

tout le monde a pas le même input    
 
Perso j'ai rien en théorie toussa, j'ai fait de l'incrément...
 

Il me semble que chacun a une entrée différente

Comme pour pataluc, la solution que tu proposes marche par accident ; l'incrément est plus grand que nécessaire donc tu peux rater de meilleurs candidats (cf quelques messages plus haut).

ah mais je suis pas dans le même jour que vous. je viens de foirer le bateau

Si ça en intéresse certains, une vidéo sur comment est analysé par un labo un test covid en PCR : https://www.youtube.com/watch?v=yfBKnkgyLtM
On y voit la machine qui automatise tout le test avec une explication sur son fonctionnement, son étalonnage...
J'aime bien cette chaîne, notamment sa série sur Youtube vs la TV.

Mais lol le type il fait des robots holonomiques à 6 degrés de liberté, et il galère à simuler un bateau qui avance sur une grille 2D

ah oui, les bus c'est le lièvre et la tortue.  

3
 
mais oui, et pire : les tests marchent, le code est simple, et il me dit que j'ai faux. Y'a un bug dans le site, c'est la seule explication possible

Ça me le fait tout le temps, c'est le gros défaut de la compétition à mon avis, il y a trop de bugs dans le site...

 
Bah non. Je vois pas pourquoi je louperais de solution.
 
Je commence par incrémenter de la période du premier bus. Quand je choppe une solution qui colle pour un autre bus, vu qu'on sait que la période qui matche 2 bus est de période le produit des période des bus (ils sont gentils ils ont filé que des périodes de bus premières), je peux augmenter mon incrément (et tous mes tests futurs matcheront ces deux bus). Et rebelote avec le 3e, etc,...

Une autre vidéo sur les CPU faits par Apple (en ARM) qui, selon les dire du mec, vont enterrer les CPU d'AMD et Intel parce qu'ils ont de bien meilleurs perfs que les x86 et sont plus simples et consomment moins : https://www.youtube.com/watch?v=cLVuk14ivD4
 
Vous en pensez quoi ?
 
Perso, j'aurais tendance à dire que les chiffres annoncés sont au moins en partie biaisée car Apple maîtrise toute la chaîne hardware, logiciel, distribution, ligne produit, maintenance... contrairement à AMD et Intel qui font des CPU qui doivent évoluer dans des contextes très hétérogènes dont ils n'auront jamais la maîtrise comme Apple peut avoir sur son écosystème.
 
Ca me rappelle un peu la comparaison PC et Mac avec la stabilité de l'OS. Là où Mac sait exactement les matériels qu'il va pouvoir accueillir et donc disposer de drivers optimisés, un PC (on va dire sous Windows) ne le sais pas et va accueillir des matériels de grandes firmes comme des trucs d'obscures entreprises avec des drivers coder à l'arrache qui vont te mettre une merde pas possible dans l'OS Or, dans un certain nb de cas, on a besoin d'avoir des machines capables d'accueillir pleins de types de matériels différents et pas juste quelques uns d'une liste préétablie.
 
Donc, à mon sens, dire que dans quelques années, il n'y aura que des CPU ARM et plus de x86 parce qu'un CPU RSIC est plus performant en toutes circonstances, ça me paraît peu réaliste.

Mettons que pour les bus 6 et 9, tu as une valeur t qui colle. Elle marchera aussi pour t + 18, alors que si on utilise ta solution on ne testera que t + 54. Il ne faut pas multiplier toutes les valeurs entre elles, mais trouver leur plus petit multiple commun.

(Cf le lièvre et la tortue, je sais pas trop pourquoi mais il semble y avoir un rapport)

 
Elles ne pivotent pas, les roues ?
/edit ah non j'ai compris, le robot a 3 degrés de liberté, mais 6 entrées. J'ai bossé que 6 ans dans un labo d'automatique, je suis pas hyper au courant du vocabulaire...

 
Certes. Mais là toutes les entrées sont premières (donc premières entre elles). Donc PPMC = produit.

C'est ce que je veux dire quand je dis que ça marche "par accident", parce que rien ne dit dans l'énoncé que les entrées sont premières.

Tu peux regarder ton input et checker que toutes tes entrées sont premières, dans AoC c'est une méthode valide

Ce sont certaines des propriétés de 70. Ma question c'est comment tu trouves 70 simplement à partir des propriétés.  
Tu itères sur les multiples du ppcm des 2 nombres jusqu'à en trouver un qui a un reste de 1 dans sa division par 3 ?

 
A mon avis il bluffe

J’imagine que oui.

 
   
 
au passage, of course 41 est premier aussi...
 
 
 

 
en fait tous les nombres des exemples, et ceux de mon input sont premiers... et même si tu as raison qu'il faudrait le PPCM, j'arrive pas à trouver de contre exemple, j'ai l'impression que si un multiple se retrouve dans 2 id de bus de l'input, soit on a une soluce évidente (genre 6,x,8 -> 8 ou 8,x,6 -> 16), soit il y a l'air de ne pas en avoir.    
 

 
pourquoi 6 entrées ? y'a 3 moteurs de contrôle et j'ai 2 translation et une rotation de dispo, et le système est parfaitement déterminé. Je suis en 2D et y'a aucun piège ou truc compliqué.

Ah j'ai pas compris le système de base. Ils contrôlent quoi les trois moteurs ?

 
Okayyyy

Quand on dis que c'est vite fait avant le boulot ces puzzles

Le mec s'est ajouté de la difficulté en résolvant avec un one liner, c'était trop facile sinon ²²²

 
Ben ce qui compte aussi c'est justement d'adéquation SW + HW non ? Ce que Microsoft devrait être capable de faire et est visiblement incapable de faire avec ses surfaces ?
 
Ceci étant dit, on a vu que lorsque Windows ARM est émulé via QEMU depuis Apple M1, les perfs sont meilleures que sur les surfaces X... Donc à mon avis, non seulement il y a une très bonne adéquation entre le HW et le SW qui sont développés de concert, mais EN PLUS, les CPUs faits par Apple roxent.  

Y'a aussi la possibilité de lire l'énoncé en diagonale et donc n'importe comment, comme moi sur le jeu de Conway (les sièges libre/occupés) où il fallait compter les sièges occupés, et bien sûr j'ai lu "inoccupés". Et j'ai effectivement demandé ici s'il n'y avait pas une erreur dans l'énoncé

Rien n'est gratuit. En x86 tu n'as pas a gérer la cohérence de cache et le contrat est plutôt simple en tant que dev. En RISC cette perf se fait au détriment de tout ça.

Pose toi la question : pourquoi autant de succès pour le x86 depuis tant d'années ?

Merci pour ton retour sur les Surfaces. Effectivement, dans ce cas là, ils sont dans des circonstances similaires à Apple. Mais ça veut peut-être juste dire que le choix d'un x89 pour une tablette, c'est pas adapté (un peu comme les rares tablettes Androïd à base de CPU Intel). Mais ça veut pas dire que les CPU M1 sont adaptés à toutes les situations.

Je confirme, tous les nombres de mon entrée sont premiers aussi. Ce n'est donc pas un hasard, je vois deux raisons à cela:
- cela évite que les congruences soient trop courtes, et donc cela exclut le brute force
- cela évite que les participants qui n'ont pas un calcul de PPCM tout prêt (disclaimer: je suis allé sur stackoverflow pour savoir comment calculer un PPCM en Python) d'avoir à en coder un
 
Donc ta solution est parfaitement valide, même si elle n'est pas générale.

Intéressant : tu peux développer, svp ?
Perso, je ne défends justement pas la thèse du mec de la vidéo. Je dis justement que l'ARM n'est pas forcément adapté à toutes les situations et ne serait pas systématiquement plus performant qu'un x86.

 
https://youtu.be/7NmaETJjRnM
J’ai essayé de montrer la cinématique de la chose.

Sauf que c’est une cohérence dont t’as généralement pas besoin donc tu paies pour rien, et quand tu en as besoin il faut généralement des garanties plus hautes donc tu repaies. Ça limite la visibilité / l’impact de bugs latents mais il n’est pas clair que ce soit un véritable avantage. Suffit de voire que Apple a implémenté la cohérence x86 dans le M1 mais n’a pas jugé utile d’en faire le seul mode.

C’est pas exactement le cas notes. Intel s’est bien posé dans les années 90 dans un segment qui a explosé (la bureautique) et leur a permis de conquérir un segment lié-mais-pas (les serveurs qui jusqu’aux années 2000 étaient très multiarch).

Sauf que le succès depuis 10 ans il est plus chez ARM, Intel ayant raté le virage mobile.

Bien sûr c'est légitime d'utiliser les propriétés de nos entrées pour résoudre le problème, c'est juste que c'est pas résoudre le problème général. Mais effectivement il n'y a aucun problème à cela.

Au passage, une entrée pour lequel cet algorithme ne marche pas :
x,4,6,x,x,x,7
La bonne réponse est 20, l'algorithme qui ajoute sans calculer le PPCM donnera bien plus.

Dites, en python, j'ai un tableau de nombres, et je voudrais avoir non seulement le minimum, mais l'index de sa première apparition dans le tableau. Je n'arrive pas à trouver la façon idiomatique d'écrire ça.

Bonus point si vous arrivez à faire un one-liner de ceci:

minimum, idx = 1000000, 0
for n, bus in enumerate(buses):
    if bus != 'x':
        mod = bus - (departure % bus)
        if mod < minimum:
            minimum = mod
            idx = n
(on retourne à la fois minimum et idx)

Pour l'instant, je pars sur

minima = itertools.accumulate(map(lambda departure, bus: bus - departure % bus if bus != 'x', buses), min)
 
... et ensuite on cherche l'index du minimum dans le tableau minima

Il y a p-ê plus simple.

min prends un paramètre key que tu peux utiliser pour lui dire sur quoi choisir le minimum. enumerate renvoie la liste + ses indices, donc une liste de paires (indice, valeur).

from operator import itemgetter
l = [1, 3, 2, 0, 4]
m = min(enumerate(l), key=itemgetter(1)) # (3, 0)

Oui enfin il faut surtout parler du monde serveur dans lequel le x86 a tout écrabouillé aussi. C'est pas un hasard mais bien une facilité technologique. Dommage là j'ai pas trop le temps de développer ce soir…

edit : j'ai lu en vitesse tu parles bien des serveurs. Je pense que tu sous-estimes les problèmes de cohérence et l'impact sur la difficulté à débug.

edit 2 : et dans le « meilleur » des cas pour ARM, la fragmentation des plateformes va pas être jojo pour « nous » les concepteurs d'OS. Cf mon post ici : https://medium.com/@olivier.lambert [...] ddca7a6268

edit 3 : et ne pas oublier les innombrables flops d'ARM dans le monde serveur. Même POWER est encore bien au dessus

from operator import itemgetter
l = [1, 3, 2, 0, 4]
m = min(enumerate(l), key=itemgetter(1)) # (3, 0)

rho putain j'aurais pu chercher longtemps... merci

Du coup je l'ai mon "one liner":

from operator import itemgetter
m = min(enumerate(map(lambda bus: bus - (departure % bus), buses)), key=itemgetter(1))
print(m[1], m[0], m[1] * buses[m[0]])

Je suis vraiment pas convaincu par cette idée. Il y avait des serveurs Alpha par un moment et on peut pas faire moins cohérent. x86 qui a tout écrabouillé dans le monde serveur je vois ça comme un résultat de la simplification machine, le matériel serveur est passé d'équipements complètement dédié à la "version haut de gamme" des équipements de bureau, dans ce cadre maintenir une archi custom sans présence bureau avait un intérêt discutable pour la majorité, et hors exceptions (principalement IBM) c'était pas vraiment un moyen de générer de la valeur.
 
Torvalds notait d'ailleur exactement ça dans le cadre d'ARM il y a pas longtemps:

C'est exactement le pont que M1 offre, une solution qu'il avait d'ailleurs noté:

from operator import itemgetter
m = min(enumerate(map(lambda bus: bus - (departure % bus), buses)), key=itemgetter(1))
print(m[1], m[0], m[1] * buses[m[0]])

Généralement on utilise `map` quand on a déjà une fonction qui fait le boulot à lui donner, sinon une gencomp va tendre à être plus courte, claire, et rapide:

from operator import itemgetter
m = min(enumerate(bus - (departure % bus) for bus in buses), key=itemgetter(1))
print(m[1], m[0], m[1] * buses[m[0]])