On peut faire un truc rigolo sur la partie travail, on garde packet et input() identiques, et on reste sur du générateur/itérateur jusqu'à la fin avec le sort :
defanalyse(decoder):score=0forid,(a,b)inenumerate(input()):yieldayieldbifa<=b:score+=id+1print(f"Pairs in the right order : {score}")fordindecoder:yieldddecoder=[packet([[2]]),packet([[6]])]s=sorted(analyse(decoder))print(f"Decoder Key = {(s.index(decoder[0])+1) * (s.index(decoder[1])+1)}")
J'ai un code équivalent, avec un peu plus de modélisation, mais sinon, c'est algorithmiquement identique :
importsysimportjsonfromfunctoolsimporttotal_ordering@total_orderingclasspacket:def__init__(self,data):self.data=datadefcompare(self,a,b):iftype(a)==type(b)==int:ifa==b:returnNonereturna<biftype(a)==int:a=[a]iftype(b)==int:b=[b]fori,jinzip(a,b):c=self.compare(i,j)ifcisnotNone:returncelse:returnself.compare(len(a),len(b))returnNonedef__lt__(self,other):returnself.compare(self.data,other.data)isTruedef__eq__(self,other):returnself.compare(self.data,other.data)isNonedefinput():x=Noneforlineinsys.stdin:ifline=="\n":x=NoneelifxisnotNone:yieldx,packet(json.loads(line))else:x=packet(json.loads(line))score=0all_packets=[]forid,(a,b)inenumerate(input()):all_packets+=[a,b]ifa<=b:score+=id+1print(f"Pairs in the right order : {score}")decoder=[packet([[2]]),packet([[6]])]s=sorted(all_packets+decoder)print(f"Decoder Key = {(s.index(decoder[0])+1) * (s.index(decoder[1])+1)}")
Je n'ai pas songé à split("\n\n"), ça fait que j'ai une première partie qui bosse en flux, mais comme pour la seconde il faut trier, on est obligé d'avoir toutes les données chargées, change rien.
Et ma fonction de comparaison est très centrée sur l'exercice : a < b c'est True, a > b c'est False et a == b c'est None, ergo on poursuit. C'est plus propre de faire -1/0/1.
classdisplay:def__init__(self,input,width,heights):self.heights=heightsself.bgcolors=[[min(255,max(232,heights[c]+231))forcinline]forlineininput]self.background="\n".join("".join(f"{self.color(c)} "forcinline)forlineinself.bgcolors)self.bgcolors=sum(self.bgcolors,[])self.width=widthdefcolor(self,bg=None,fg=None,rgb=None):bg=f"\033[48;5;{bg}m"ifbgelse""fg=f"\033[38;5;{fg}m"iffgelse""fg=f"\033[38;2;{rgb[0]};{rgb[1]};{rgb[2]}m"ifrgbelsefgreturnf"{bg}{fg}"defcursor(self,row=0,col=0):returnf"\033[{row};{col}H"def__call__(self,*visited):print(self.cursor(),end='')print(self.background)forvinvisited:print(f"{self.cursor(*divmod(v, self.width))}{self.color(bg=self.bgcolors[v], fg=160)}o")time.sleep(.1)# On ajoute ces deux lignes juste avant la troisième :d=display(input,w,heights)d()input="".join(input)# Et enfin en dernière ligne de main():d(*v1,*v2)# Et pour éviter d'avoir les résultats en tout moche au milieu :s1=main([start],[end])s2=main([posforpos,heightinenumerate(map)ifheight==1],[end])print(d.cursor(row=h+1),end='')print("\033[0m",end='')print(f"Path found in {s1} moves !")print(f"Path found in {s2} moves !")
Et il faut mettre le terminal en grand, parce que sinon ça va faire très très moche et buggé !
On a une animation des cases en cours de visite, sur fond de montagne enneigée (dégradé noir en bas, et blanc en haut).
Ah, classe :)
J'ai rien de joli à montrer ce coup-ci.
Mais bon, journée présentiel au taf hier, trois heures dans la voiture, 4h en réunions, j'ai à peine eu le temps de bricoler une solution, en ayant réfléchi sur le trajet…
J'ai fait un parcours de graphe inventé à la volée : je n'ai jamais été fichu de retenir le moindre des algos de parcours que j'ai pu apprendre, alors je suis condamné à réinventer la roue !
J'ai des cases en entrée, je regarde pour chacune d'elles où elles peuvent aller (haut, bas, gauche, droite, si la différence de hauteur est bonne), et si je n'ai pas déjà été là (donc matrice des cases visitées avec distance au départ dedans).
Je note l'ensemble des cases nouvellement visitées, et j'itère sur cet ensemble.
Donc a priori inutile de stocker le score pour le retrouver et calculer la suite comme dans mon code plus bas : il suffit de compter les étapes.
Instinctivement, je me suis dis que ça pouvait grossir, et donc j'ai décidé de manger le problème par les deux bouts, donc j'explore en montant depuis "S" et en descendant depuis "E".
Je stocke des scores positifs en montant, et négatifs en descendant.
Si je rencontre une case visitée depuis l'autre bout (case négative si je monte ou positive si je descends), j'ai fait la liaison.
En pratique je peux m'arrêter là : si je suis en train de monter c'est étape*2+1, si je suis en train de descendre c'est étape*2+2.
Dans mon code j'additionne les valeurs absolues : la valeur que j'aurais dû mettre dans la case, et celle déjà présente, et j'ai mon résultat.
Pour l'exercice 2, comme je fournis déjà une liste de case par itération, il suffit de mettre comme liste de démarrage tout les "a" et le "S", vraiment rien à coder, la dernière ligne du programme et basta.
Ah, et j'ai aligné, je bosse sur un tableau à une dimension, au lieu d'une matrice.
Et les mouvements possibles ne sont pas (haut, bas, gauche droite) mais (-1, +1, -largeur, +largeur) et un mouvement doit être dans [0, taille[
Allez, trêve de blabla, code !
heights={v:(26ifk==27elsek)or1fork,vinenumerate("SabcdefghijklmnopqrstuvwxyzE")}input=[lineforlineinsys.stdin.read().strip().splitlines()]w,h=len(input[0]),len(input)size=w*hmoves=[1,-1,w,-w]input="".join(input)map=[heights[c]forcininput]start=input.index("S")end=input.index("E")deftest(score,newpos,height,sign):""" False : mouvement impossible True : mouvement possible vers case non visitée int : mouvement possible vers case visitée, retourne le score de cette case """ifnewpos<0ornewpos>=size:returnFalseif(sign>0andmap[newpos]>height+1)\
or(sign<0andmap[newpos]<height-1):returnFalseifscore[newpos]isNone:returnTruereturnscore[newpos]defmove(score,pos,sign=1):height=map[pos]visited=[]solution=Falseforminmoves:newpos=pos+mt=test(score,newpos,height,sign)ifnott:# Movement not allowedcontinueiftisTrue:# New tile visitedscore[newpos]=score[pos]+signvisited.append(newpos)continueift*sign>0:# Already visitedcontinue# Visited from the other side : solution found !visited.append(newpos)solution=min(solutionorsize,1+sign*score[pos]-sign*score[newpos])returnvisited,solutiondefmain(s1,s2):score=[0if(posins1orposins2)elseNoneforposinrange(size)]unfinished=Truewhileunfinished:v1,v2=[],[]forposins1:v,solution=move(score,pos,1)v1+=vifsolution:print(score)print(f"Path found in {solution} moves !")unfinished=Falseforposins2:v,solution=move(score,pos,-1)v2+=vifsolution:print(score)print(f"Path found in {solution} moves !")unfinished=Falses1,s2=v1,v2main([start],[end])main([posforpos,heightinenumerate(map)ifheight==1],[end])
Pour le « truc qui scale pas » de la seconde partie, un bug dans la première partie m'a fait tomber dessus très tôt, et la solution est assez simple.
Un mélange de propre et de hack tout moche pour celui-là, avec un affichage qui montre l'avancement des calculs, ya 9s pour la seconde partie tout de même…
L'idée pour la seconde passe c'est que tout peut se passer au modulo du produit de tous les modulos. Même au PGCM de tous les modulos des différents singes, mais le produit suffit, on a des nombres suffisamment petits pour que ça roule vite et bien.
Donc la première passe retourne ce produit des modulos, qui est nourri à la seconde passe, en modifiant la classe de base avant instanciation des nouveaux singes.
Joli hack bien crade quoi :)
Après on a quelques bidouilles d'affichage pour lister les singes et faire défiler le n° de round, et ainsi voir l'avancement des calculs.
Et bien sûr, le cœur du problème avec un bon gros eval sur l'opération à effectuer, sinon c'pas drôle !
J'aime bien l'idée, c'est bourrin, c'est fun, ça fait du code plus léger, et ça ressemble à ce qu'on ferait à la main avec une maquette ou une feuille de papier : on fait tourner (ou on tourne autour) !
Par contre c'est faux je pense.
Il y a des arbres visibles depuis plusieurs côtés, et tu vas les compter plusieurs fois…
Posté par Yth (Mastodon) .
En réponse au message Avent du Code, jour 10.
Évalué à 2.
Dernière modification le 10 décembre 2022 à 20:17.
C'est un peu l'idée derrière mon propre code.
Et si on l'enrichissait ?
Par exemple si on veut ajouter une commande affxy a b - qui fait la fonction affine a*x+b - à deux arguments et trois cycles par exemple, dans mon code il suffit d'ajouter cette méthode :
defaffxy(self,a,b):self.noop()# ou :self.noop()# self.history.append(self.X)self.noop()# pour la première versionself.X=int(a)*self.X+int(b)
On a un fond en échiquier, qui bascule quand on « déplace la caméra », ça permet de visuellement voir que ça défile.
Ça marche parce qu'on décale toujours de 1, et ça alterne entre les deux fonds quelle que soit la direction du déplacement.
Et avec des caractères utf-8 de bloc plein, ou gris, c'est plus joli.
Il faut te connecter, d'une façon ou d'une autre, j'utilise mon compte github perso.
Et là tu as un jeu de donnée personnalisées en entrée, et tu peux fournir le résultat dans un champs spécifique en bas de page.
Ça te donne accès au second exercice.
Le premier point, d'utiliser for l in sys.stdin permet de ne pas lire tout l'input, mais simplement d'itérer sur les lignes, on reste plus bas en RAM, on traite un flux.
Le second point, c'est d'utiliser *q pour prendre « ce qui reste ».
Dans le cas d'une ligne "noop" on a m="noop" et q=[].
Dans le cas de "addx XX" on a m="addx" et q=[XX], une list avec la valeur en premier (et unique) élément.
Mais en refilant *q à int, il « unpack » et int(*q) devient équivalent à int(XX).
Avec ça tu gères des instructions différentes, avec autant de paramètres que tu veux, tu t'en fous au niveau du parsing, tu veux juste connaître l'instruction et passer le reste à la gestion de l'instruction.
Ça évite de rajouter un argument factice, et de splitter en ne prenant que les deux premiers.
Yth.
PS: et aussi, chapeau pour la maîtrise d'awk, j'en suis pas là !
importsysdefinput():forlineinsys.stdin:yieldtuple(line.split())classcpu:def__init__(self):self.X=1self.history=[]defnoop(self):self.history.append(self.X)defaddx(self,n):self.history.append(self.X)self.history.append(self.X)self.X+=int(n)def__getitem__(self,n):# Cycle 1 is history 0returnself.history[n-1]def__call__(self,row,col):return"#"ifabs(self.history[row*40+col]-col)<=1else" "mycpu=cpu()foraction,*valuesininput():getattr(mycpu,action)(*values)signal_strength=sum(mycpu[n]*nforninrange(20,221,40))print(f"Signal Strength : {signal_strength}")screen="\n".join("".join(mycpu(row,col)forcolinrange(40))forrowinrange(6))print(screen)
Là je conserve tout l'historique des valeurs de X à chaque cycle, ça n'est évidemment pas viable sur un long programme.
Il faudrait optimiser pour la demande, c'est à dire écrire instruction après instruction l'état de l'écran pour le cycle qui passe, et faire un hook sur les valeurs de la première question, pour additionner/stocker par ailleurs.
Au début j'avais mis un compteur de cycle dans ma classe cpu mais à la fin je ne l'utilisais pas, alors je l'ai viré…
C'est assez facile d' « optimiser » la classe cpu pour qu'elle dessine l'écran au fur et à mesure, on fait une méthode comme ça :
Et définir self.col = 0; self.screen = [] dans l'init.
On remplace les appels à self.history.append(self.X) par self.cycle().
On réalise que cpu.noop ne fait plus qu'exécuter cpu.cycle, donc on garde noop et addx devient :
On vire le cpu.call puisqu'on dessine l'écran à la volée dans mycpu.screen et on affiche print("".join(mycpu.screen)) à la fin. On n'a plus qu'à rajouter un history à 0 pour le cycle 0 inexistant, et on n'a plus besoin de faire return self.history[n-1] dans cpu.__getitem__()
Avec tout ça mis en place on a un code plus concis, plus clair, mais on conserve toujours l'historique pour la question 1, et s'en débarrasser oblige a faire un hook un peu crados dans cpu.noop(), conserver le numéro du cycle courant, et si cycle%40==20 ajouter à self.signal_strengthself.X * self.cycle.
On se débarrasse de l'historique.
Plus propre ?
Moins propre ?
Difficile à dire…
Mais il s'agit de débuggage, donc on peut introduire un hook cpu.debug à chaque cycle, qui servirait à ça.
Bilan ?
8 octets de différence dans le fichier final, temps d'exécution rigoureusement similaire.
En pratique si on bourrine sur les entrées, le second code est plus lent puisqu'il maintient à jour un écran.
On peut utiliser un deque pour cpu.screen et avoir un scroll automatique, ça restreint la RAM utilisée, qui reste stable quelles que soient les données en entrées.
Alors que le premier fait juste un history.append(), ça pompe de la RAM (à l'infini d'ailleurs) mais pas du CPU.
J'espère que dans vos solutions perso, vous aurez pensé à utiliser, en arrivant à la deuxième partie, à utiliser une seule corde pour simuler les deux…
Pas lors de la première résolution, mais après en nettoyant un peu le code oui… Comme d'hab, le problème arrivant en deux fois, on n'optimise pas dès le début pour la seconde partie :)
Pas trop modélisé, des vecteurs numpy juste pour avoir des simplifications comme l'addition, la soustraction ou la valeur absolue.
J'aime bien ton import_line qui fait un unique itérateur pour chaque mouvement unitaire, c'est propre !
Mon premier parcours est moins bourrin, je ne cherche pas à savoir pour chaque arbre s'il est visible, mais bien à noter les arbres vus depuis chaque angle de vue, donc au lieu d'avoir size=width*height traitements, j'en ai 2*(width+height).
defcheck(rows,cols):h=-1forrinrows:forcincols:ifinput[r][c]>h:visible[r*width+c]=Trueh=input[r][c]visible=[Falsefor_inrange(size)]forrinrange(height):check([r],range(width))check([r],range(width-1,-1,-1))forcinrange(width):check(range(height),[c])check(range(height-1,-1,-1),[c])print(f"Visible Trees : {sum(visible)}")
Pour la seconde partie c'est algorithmiquement équivalent :
deflook(h,rows,cols):n=0forrinrows:forcincols:n+=1ifinput[r][c]>=h:returnnreturnnscenic=[0for_inrange(size)]forrinrange(1,height-1):forcinrange(1,width-1):h=input[r][c]scenic[r*width+c]=(look(h,range(r-1,-1,-1),[c])# top*look(h,range(r+1,height),[c])# bottom*look(h,[r],range(c-1,-1,-1))# left*look(h,[r],range(c+1,width))# right)print(f"Best scenic tree : {max(scenic)}")
Et là pour chopper le sous-répertoire "toto" de mon Directory(truc) je fais truc['toto'].
Je n'ai même pas pensé à inclure le '..' dans mes fichiers, j'ai un cas particulier si on fait cd .., c'était tellement évident de faire ça !
On pourrait accéder à truc/toto via truc.toto en implémentant __getattr__ comme j'ai fait le __getitem__, mais si "toto" est dans une variable il faut faire getattr(truc, variable_toto), ça ne simplifie pas la lecture, c'est plus simple d'utiliser truc[variable_toto].
Après on peut implémenter __truediv__ et faire que truc/"toto" retourne Directory(truc/toto).
Là on a root/"a"/"b"/".."/"c"/".."/".."/"e"/"f" = Directory("/e/f") :)
Mais les guillemets partout alourdissent la lecture et l'écriture…
Sinon, côté algo, et même implémentation, c'est pareil rien à signaler, pas de subtilité, j'ai juste utilisé du if line.startswith("$ cd"): cwd = cwd[line[5:]] plutôt qu'une regexp.
J'ai fait du Caml, j'ai joué un peu avec OCaml, et même un poil de Lisp Jadis, mais je ne code pas régulièrement dans ces langages là.
Réutiliser les opérateurs, c'est bien pour jouer, mais ça peut péter complètement la lisibilité, donc il faut faire très très attention quand on veut partager le code…
J'aime bien réutiliser les opérateurs, mais j'ai fait ça assez rapidement, donc la pertinence est celle d'un truc pondu en vingt minutes.
Le ~chifumi est pratique et plutôt lisible, comme ça on normalise tout le temps.
Par contre réutiliser la classe chifumi pour qu'elle représente une choix ou un résultat d'affrontement, c'est plutôt moche, ça rendrait illisible un code plus gros, et c'est totalement lié à la présentation de la seconde partie du problème après la résolution de la première : comment bricoler vite fait du code qui répond à la question. C'était plus simple de rajouter un opérateur à une classe existante que de gérer une nouvelle classe.
Mais en plus propre on pourrait avoir une classe resultat d'affrontement, qui sait se multiplier (par exemple) avec une classe chifumi, avec __mul__ et __rmul__, pour pouvoir faire chifumi * resultat = resultat * chifumi = "mais qu'a donc joué mon adversaire ?"
On apprends à resultat à se multiplier dans les deux sens avec chifumi sans que celle-ci sache comment se multiplier avec resultat.
On pourrait garder le même opérateur partout, et faire du __mod__ et __rmod__ sur resultat. Sachant que dans tous les cas on retourne un score qui est un entier et n'a rien à voir avec aucune des deux classes.
Pour le total_ordering, c'est vrai, mais en pratique j'ai implémenté __lt__ qui n'est jamais utilisé. J'aurais pu nettoyer ça du code avant de le poster.
Je viens de voir le message, j'ai rejoins alors :)
Bon, par contre le leaderboard a la valeur qu'on lui donne : hors de question de me lever à 6h du matin pour faire ça parmi les premiers…
[^] # Re: python, en trichant
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 13. Évalué à 2.
On peut faire un truc rigolo sur la partie travail, on garde packet et input() identiques, et on reste sur du générateur/itérateur jusqu'à la fin avec le sort :
[^] # Re: En Pypthon
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 13. Évalué à 2.
Ah, j'avoue, j'ai même pas imaginé deux secondes faire un vrai parsing des données :)
[^] # Re: python, en trichant
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 13. Évalué à 2.
J'ai un code équivalent, avec un peu plus de modélisation, mais sinon, c'est algorithmiquement identique :
Je n'ai pas songé à split("\n\n"), ça fait que j'ai une première partie qui bosse en flux, mais comme pour la seconde il faut trier, on est obligé d'avoir toutes les données chargées, change rien.
Et ma fonction de comparaison est très centrée sur l'exercice : a < b c'est True, a > b c'est False et a == b c'est None, ergo on poursuit. C'est plus propre de faire -1/0/1.
[^] # Re: Étoile
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 12. Évalué à 3.
Le rendu de mon paysage, en doublant la largeur pour faire moins écrasé.
Complètement Numénor oui.
[^] # Re: python et lib de graph
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 12. Évalué à 3.
Pour faire du joli on fait ça :
Et il faut mettre le terminal en grand, parce que sinon ça va faire très très moche et buggé !
On a une animation des cases en cours de visite, sur fond de montagne enneigée (dégradé noir en bas, et blanc en haut).
[^] # Re: python et lib de graph
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 12. Évalué à 2.
Ah, classe :)
J'ai rien de joli à montrer ce coup-ci.
Mais bon, journée présentiel au taf hier, trois heures dans la voiture, 4h en réunions, j'ai à peine eu le temps de bricoler une solution, en ayant réfléchi sur le trajet…
J'ai fait un parcours de graphe inventé à la volée : je n'ai jamais été fichu de retenir le moindre des algos de parcours que j'ai pu apprendre, alors je suis condamné à réinventer la roue !
J'ai des cases en entrée, je regarde pour chacune d'elles où elles peuvent aller (haut, bas, gauche, droite, si la différence de hauteur est bonne), et si je n'ai pas déjà été là (donc matrice des cases visitées avec distance au départ dedans).
Je note l'ensemble des cases nouvellement visitées, et j'itère sur cet ensemble.
Donc a priori inutile de stocker le score pour le retrouver et calculer la suite comme dans mon code plus bas : il suffit de compter les étapes.
Instinctivement, je me suis dis que ça pouvait grossir, et donc j'ai décidé de manger le problème par les deux bouts, donc j'explore en montant depuis "S" et en descendant depuis "E".
Je stocke des scores positifs en montant, et négatifs en descendant.
Si je rencontre une case visitée depuis l'autre bout (case négative si je monte ou positive si je descends), j'ai fait la liaison.
En pratique je peux m'arrêter là : si je suis en train de monter c'est étape*2+1, si je suis en train de descendre c'est étape*2+2.
Dans mon code j'additionne les valeurs absolues : la valeur que j'aurais dû mettre dans la case, et celle déjà présente, et j'ai mon résultat.
Pour l'exercice 2, comme je fournis déjà une liste de case par itération, il suffit de mettre comme liste de démarrage tout les "a" et le "S", vraiment rien à coder, la dernière ligne du programme et basta.
Ah, et j'ai aligné, je bosse sur un tableau à une dimension, au lieu d'une matrice.
Et les mouvements possibles ne sont pas (haut, bas, gauche droite) mais (-1, +1, -largeur, +largeur) et un mouvement doit être dans [0, taille[
Allez, trêve de blabla, code !
[^] # Re: À la chasse aux singes, j'envoie le Python !
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 11. Évalué à 2.
Ah oui, j'ai sorti l'eval avec réticence, mais c'est tellement adapté à ce cas précis…
Professionnellement il faudrait salement valider la chaîne, et probablement qu'un parseur aurait été la solution, pour ne pas faire d'eval.
# À la chasse aux singes, j'envoie le Python !
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 11. Évalué à 3.
Pour le « truc qui scale pas » de la seconde partie, un bug dans la première partie m'a fait tomber dessus très tôt, et la solution est assez simple.
Un mélange de propre et de hack tout moche pour celui-là, avec un affichage qui montre l'avancement des calculs, ya 9s pour la seconde partie tout de même…
L'idée pour la seconde passe c'est que tout peut se passer au modulo du produit de tous les modulos. Même au PGCM de tous les modulos des différents singes, mais le produit suffit, on a des nombres suffisamment petits pour que ça roule vite et bien.
Donc la première passe retourne ce produit des modulos, qui est nourri à la seconde passe, en modifiant la classe de base avant instanciation des nouveaux singes.
Joli hack bien crade quoi :)
Après on a quelques bidouilles d'affichage pour lister les singes et faire défiler le n° de round, et ainsi voir l'avancement des calculs.
Et bien sûr, le cœur du problème avec un bon gros
eval
sur l'opération à effectuer, sinon c'pas drôle ![^] # Re: En Python, modélisé
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 9. Évalué à 2.
C'est Tanguy qui a pensé à l'utf8 en premier pour le jour 10, je reprends les bonnes idées :)
[^] # Re: En faisant pivoter la forêt
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 8. Évalué à 2. Dernière modification le 10 décembre 2022 à 20:25.
Ya ça en numpy :
https://numpy.org/doc/stable/reference/generated/numpy.rot90.html
J'aime bien l'idée, c'est bourrin, c'est fun, ça fait du code plus léger, et ça ressemble à ce qu'on ferait à la main avec une maquette ou une feuille de papier : on fait tourner (ou on tourne autour) !
Par contre c'est faux je pense.
Il y a des arbres visibles depuis plusieurs côtés, et tu vas les compter plusieurs fois…
[^] # Re: Plus simple
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 10. Évalué à 2. Dernière modification le 10 décembre 2022 à 20:17.
C'est un peu l'idée derrière mon propre code.
Et si on l'enrichissait ?
Par exemple si on veut ajouter une commande
affxy a b
- qui fait la fonction affinea*x+b
- à deux arguments et trois cycles par exemple, dans mon code il suffit d'ajouter cette méthode :Voilà, c'est géré.
[^] # Re: En Python, modélisé
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 9. Évalué à 3.
Bonne idée de remettre le curseur en haut !
Et encore une petite amélioration inutile donc indispensable :
On a un fond en échiquier, qui bascule quand on « déplace la caméra », ça permet de visuellement voir que ça défile.
Ça marche parce qu'on décale toujours de 1, et ça alterne entre les deux fonds quelle que soit la direction du déplacement.
Et avec des caractères utf-8 de bloc plein, ou gris, c'est plus joli.
[^] # Re: Où est la partie 2 ?
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 10. Évalué à 3.
Il faut te connecter, d'une façon ou d'une autre, j'utilise mon compte github perso.
Et là tu as un jeu de donnée personnalisées en entrée, et tu peux fournir le résultat dans un champs spécifique en bas de page.
Ça te donne accès au second exercice.
[^] # Re: quick python
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 10. Évalué à 4. Dernière modification le 10 décembre 2022 à 15:14.
Tu peux simplifier un peu ta gestion des input en faisant ça :
Le premier point, d'utiliser
for l in sys.stdin
permet de ne pas lire tout l'input, mais simplement d'itérer sur les lignes, on reste plus bas en RAM, on traite un flux.Le second point, c'est d'utiliser *q pour prendre « ce qui reste ».
Dans le cas d'une ligne "noop" on a m="noop" et q=[].
Dans le cas de "addx XX" on a m="addx" et q=[XX], une list avec la valeur en premier (et unique) élément.
Mais en refilant *q à int, il « unpack » et int(*q) devient équivalent à int(XX).
Avec ça tu gères des instructions différentes, avec autant de paramètres que tu veux, tu t'en fous au niveau du parsing, tu veux juste connaître l'instruction et passer le reste à la gestion de l'instruction.
Ça évite de rajouter un argument factice, et de splitter en ne prenant que les deux premiers.
PS: et aussi, chapeau pour la maîtrise d'awk, j'en suis pas là !
# Entre deux.
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 10. Évalué à 3.
Moins modélisé que Tanguy, mais plus que steph.
Là je conserve tout l'historique des valeurs de X à chaque cycle, ça n'est évidemment pas viable sur un long programme.
Il faudrait optimiser pour la demande, c'est à dire écrire instruction après instruction l'état de l'écran pour le cycle qui passe, et faire un hook sur les valeurs de la première question, pour additionner/stocker par ailleurs.
Au début j'avais mis un compteur de cycle dans ma classe
cpu
mais à la fin je ne l'utilisais pas, alors je l'ai viré…C'est assez facile d' « optimiser » la classe cpu pour qu'elle dessine l'écran au fur et à mesure, on fait une méthode comme ça :
Et définir
self.col = 0; self.screen = []
dans l'init.On remplace les appels à
self.history.append(self.X)
parself.cycle()
.On réalise que
cpu.noop
ne fait plus qu'exécutercpu.cycle
, donc on gardenoop
etaddx
devient :On vire le
cpu.call
puisqu'on dessine l'écran à la volée dansmycpu.screen
et on afficheprint("".join(mycpu.screen))
à la fin. On n'a plus qu'à rajouter un history à 0 pour le cycle 0 inexistant, et on n'a plus besoin de fairereturn self.history[n-1]
danscpu.__getitem__()
Avec tout ça mis en place on a un code plus concis, plus clair, mais on conserve toujours l'historique pour la question 1, et s'en débarrasser oblige a faire un hook un peu crados dans
cpu.noop()
, conserver le numéro du cycle courant, et sicycle%40==20
ajouter àself.signal_strength
self.X * self.cycle
.On se débarrasse de l'historique.
Plus propre ?
Moins propre ?
Difficile à dire…
Mais il s'agit de débuggage, donc on peut introduire un hook cpu.debug à chaque cycle, qui servirait à ça.
Bilan :
Bilan ?
8 octets de différence dans le fichier final, temps d'exécution rigoureusement similaire.
En pratique si on bourrine sur les entrées, le second code est plus lent puisqu'il maintient à jour un écran.
On peut utiliser un deque pour cpu.screen et avoir un scroll automatique, ça restreint la RAM utilisée, qui reste stable quelles que soient les données en entrées.
Alors que le premier fait juste un history.append(), ça pompe de la RAM (à l'infini d'ailleurs) mais pas du CPU.
[^] # Re: Vivement , le 1
Posté par Yth (Mastodon) . En réponse au journal Calendrier de l'Avent du code. Évalué à 3.
Et je suis repassé tout juste devant avec encore un nouvel inscrit !
C'est rigolo remarque de voir ça évoluer :)
Tu remarqueras que si on trie par global score on est tous à égalité à 0 hein…
[^] # Re: En Python, modélisé
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 9. Évalué à 3.
C'est vrai !
Bon, comme j'aime bien les trucs rigolos qui bougent, j'ai fait une animation en terminal.
On ajoute ça :
Et dans la boucle on ajoute à la fin :
d(knots)
J'ai 11460 mouvements dans mon input, à cette vitesse -
sleep(.01)
- ça prends 2 minutes et quelques.Ça commence centré sur le démarrage, et quand la tête déborde d'un côté, on translate tout pour garder dans le champs.
[^] # Re: En Python, modélisé
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 9. Évalué à 4.
Pas lors de la première résolution, mais après en nettoyant un peu le code oui… Comme d'hab, le problème arrivant en deux fois, on n'optimise pas dès le début pour la seconde partie :)
Voici mon code :
Pas trop modélisé, des vecteurs numpy juste pour avoir des simplifications comme l'addition, la soustraction ou la valeur absolue.
J'aime bien ton
import_line
qui fait un unique itérateur pour chaque mouvement unitaire, c'est propre !Et donc :
[^] # Re: Procrastination
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 8. Évalué à 3.
Ouais, c'est des glandus ces elfes, on dirait moi le lundi matin…
[^] # Re: python procédural, moche mais efficace
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 8. Évalué à 3.
Mon premier parcours est moins bourrin, je ne cherche pas à savoir pour chaque arbre s'il est visible, mais bien à noter les arbres vus depuis chaque angle de vue, donc au lieu d'avoir
size=width*height
traitements, j'en ai2*(width+height)
.Pour la seconde partie c'est algorithmiquement équivalent :
[^] # Re: En Python
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 7. Évalué à 3.
Et un peu d'utilisation de fonction magiques chez moi ici :
Et là pour chopper le sous-répertoire
"toto"
de monDirectory(truc)
je faistruc['toto']
.Je n'ai même pas pensé à inclure le
'..'
dans mes fichiers, j'ai un cas particulier si on faitcd ..
, c'était tellement évident de faire ça !On pourrait accéder à
truc/toto
viatruc.toto
en implémentant__getattr__
comme j'ai fait le__getitem__
, mais si"toto"
est dans une variable il faut fairegetattr(truc, variable_toto)
, ça ne simplifie pas la lecture, c'est plus simple d'utilisertruc[variable_toto]
.Après on peut implémenter
__truediv__
et faire que truc/"toto" retourneDirectory(truc/toto)
.Là on a
root/"a"/"b"/".."/"c"/".."/".."/"e"/"f" = Directory("/e/f")
:)Mais les guillemets partout alourdissent la lecture et l'écriture…
Sinon, côté algo, et même implémentation, c'est pareil rien à signaler, pas de subtilité, j'ai juste utilisé du
if line.startswith("$ cd"): cwd = cwd[line[5:]]
plutôt qu'une regexp.[^] # Re: En Python bref
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 2. Évalué à 3.
J'ai fait du Caml, j'ai joué un peu avec OCaml, et même un poil de Lisp Jadis, mais je ne code pas régulièrement dans ces langages là.
Réutiliser les opérateurs, c'est bien pour jouer, mais ça peut péter complètement la lisibilité, donc il faut faire très très attention quand on veut partager le code…
Bien fait c'est génial par contre.
[^] # Re: En Python bref
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 2. Évalué à 3.
J'aime bien réutiliser les opérateurs, mais j'ai fait ça assez rapidement, donc la pertinence est celle d'un truc pondu en vingt minutes.
Le
~chifumi
est pratique et plutôt lisible, comme ça on normalise tout le temps.Par contre réutiliser la classe
chifumi
pour qu'elle représente une choix ou un résultat d'affrontement, c'est plutôt moche, ça rendrait illisible un code plus gros, et c'est totalement lié à la présentation de la seconde partie du problème après la résolution de la première : comment bricoler vite fait du code qui répond à la question. C'était plus simple de rajouter un opérateur à une classe existante que de gérer une nouvelle classe.Mais en plus propre on pourrait avoir une classe
resultat
d'affrontement, qui sait se multiplier (par exemple) avec une classechifumi
, avec__mul__
et__rmul__
, pour pouvoir fairechifumi * resultat = resultat * chifumi = "mais qu'a donc joué mon adversaire ?"
On apprends à
resultat
à se multiplier dans les deux sens avecchifumi
sans que celle-ci sache comment se multiplier avecresultat
.On pourrait garder le même opérateur partout, et faire du
__mod__
et__rmod__
surresultat
. Sachant que dans tous les cas on retourne un score qui est un entier et n'a rien à voir avec aucune des deux classes.Pour le total_ordering, c'est vrai, mais en pratique j'ai implémenté
__lt__
qui n'est jamais utilisé. J'aurais pu nettoyer ça du code avant de le poster.[^] # Re: Vivement , le 1
Posté par Yth (Mastodon) . En réponse au journal Calendrier de l'Avent du code. Évalué à 4.
Je viens de voir le message, j'ai rejoins alors :)
Bon, par contre le leaderboard a la valeur qu'on lui donne : hors de question de me lever à 6h du matin pour faire ça parmi les premiers…
[^] # Re: En mode 10 minutes
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 1. Évalué à 2. Dernière modification le 07 décembre 2022 à 10:08.
Ma solution vite faite.