faces=" 12 3 56 4 "# positions des faces du d6 dans mon input, mis en lignesmax=cubesize-1forrowinrange(totalsize):forcolinrange(totalsize):c=board2[row][col]ifc==" ":continuecolor={".":"Blue","#":"Gray","<":"White",">":"White","v":"White","^":"White"}[c]face=faces[(col//cubesize)+(row//cubesize)*4]a,b=col%cubesize,row%cubesizeifface=="1":x,y,z,X,Y,Z=a,b,smax+1,1,1,.01elifface=="2":x,y,z,X,Y,Z=smax+1,b,smax-a,.01,1,1elifface=="3":x,y,z,X,Y,Z=a,0,smax-b,1,.01,1elifface=="4":x,y,z,X,Y,Z=b,smax+1,smax-a,1,.01,1elifface=="5":x,y,z,X,Y,Z=0,smax-b,smax-a,.01,1,1elifface=="6":x,y,z,X,Y,Z=a,smax-b,0,1,1,.01print(f"color(\"{color}\") translate([{x},{y},{z}]) cube([{X},{Y},{Z}]);")
Le switch de 1 à 6 applique les rotations, et déplacements en 3D pour poser la surface de la face du cube sur la face du cube 3D, j'ai dû inverser des trucs à des endroits.
C'est sous optimisé pour de l'openScad, mais j'ai fait ça rapidement, on génère tout de même 15000 objets (50x50x6), ça le perturbe pas beaucoup cela dit !
Ma grippe m'a rattrapé, le premier exo nickel, le second j'ai cédé comme toi sur les données des faces et rotations, et passé des heures à débugger un code bon à jeter !
Mon dernier code tombe enfin sur le bon résultat, mais je sais pas bien pourquoi par rapport aux précédents.
L'algo est bon depuis ce matin 9h30 environ…
C'est juste qu'il est mal écrit, et que j'arrive à rien :)
Dommage, si j'avais été plus vite, j'aurais peut-être essayé une représentation.
Oui, je l'ai fait instinctivement, mais après c'est apparu évident.
En pratique on maximise toujours l'ore dans les chemins gagnants, mais pas en construisant tout d'un coup.
Pour l'exo 1 je fais du re.findall, str.replace, re.sub, et un gros eval dès que j'ai root.
Youpi, bourrin :)
Pour le 2, bah non.
On remplace root: truc * much par root: truc - much, et humn: ???? par humn: X
À la fin on a une grosse opération bourrée de parenthèses, avec au fond du fond (X), il faut résoudre ce truc = 0.
Donc on remonte en inversant les opérations, chaque parenthèse est (nombre opération (trucs...)) ou ((trucs...) opération nombre), des gros if tout moches, et à la fin le résultat.
Sans finesse ça va assez vite : une demi seconde.
importredefiteration1(data):reg=re.compile(r"^([a-z]{4}): ([^a-z]+?)$",re.MULTILINE)whileTrue:numbers={a:f"({b})"if'X'inbelsestr(eval(b))fora,binreg.findall(data)}if"root"innumbers:yieldnumbers['root']returndata=reg.sub("",data)forname,valueinnumbers.items():data=data.replace(name,value)yielddatadefiteration2(data,r=0):reg1=re.compile(r"^\((.*) (.) ([\d.]+)\)$")reg2=re.compile(r"^\(([\d.]+) (.) (.*)\)$")whileTrue:# r = a o ba,o,b=(reg1.findall(data)+reg2.findall(data))[0]if'X'ina:data=aifo=='+':r=r-float(b)ifo=='-':r=r+float(b)ifo=='*':r=r/float(b)ifo=='/':r=r*float(b)else:data=bifo=='+':r=r-float(a)ifo=='-':r=float(a)-rifo=='*':r=r/float(a)ifo=='/':r=float(a)/ryielddata,rifdata=="(X)":returndata=sys.stdin.read().strip()# Exercice 1r=0fordiniteration1(data):r=dprint(eval(d))# Exercice 2data2=re.sub(r"root: ([a-z]{4}) . ([a-z]{4})",r"root: \1 - \2",re.sub(r"humn: \d+","humn: X",data))fordiniteration1(data2):r=dfordiniteration2(r,0):r=dprint(r[1])
Zéro modélisation, à peine de la réflexion, zéro optimisations sauf l'eval ajouté dans l'iteration1 quand on peut réduire à un nombre, basta.
Je n'ai jamais écrit que laposte.net était responsable de ce qui se passe :
on constate que laposte.net ne se foule pas beaucoup beaucoup pour essayer d'arranger la situation de leur côté, d'où la grogne…
Ce n'est pas rendre laposte.net responsable.
C'est l'explication des mécontentements.
Et oui, ils sont mal dirigés les mécontentements, mais on est en France, c'est vachement plus facile de tape sur La Poste que sur un MAGAF, c'est limite culturel !
Par contre Ferrari serait un peu responsable de continuer à te vendre une voiture qui ne peut plus rouler nulle part…
C'est pas mal de ne pas aller jusqu'au bout si on sait déjà qu'on sera en-dessous du meilleur temps.
J'ai ajouté un truc comme ça sur mon code, ça fonctionne nickel, et je divise le temps par deux, je suis à 5s pour les deux exercices.
Je passe de 492 462 chemins à 46 859 sur l'exo 1.
Et au total de 4 661 927 à 755 262 sur l'exo 2.
Vu la réduction sévère du nombre de chemins, je me demande où le temps est perdu tout de même…
Posté par Yth (Mastodon) .
En réponse au message Avent du Code, jour 20.
Évalué à 4.
Dernière modification le 20 décembre 2022 à 15:02.
C'est tellement plus intelligent que ce que j'ai fait, je suis jaloux !
Je ne pensais pas que les listes seraient assez performantes, j'aurais dû essayer.
Alors, juste comme ça, j'ai aussi une adresse @laposte.net, depuis une vingtaine d'années, que j'utilise de moins en moins.
Le service rendu pendant 15 ans était parfait, c'est à dire que je pouvais envoyer des mails à des gens, et en recevoir.
Donc je n'ai pas souscrits une adresse mail pour utiliser une Ferrari dans la gadoue ou forer de la pierre avec un forêt à métal, et le service a été parfaitement adapté au besoin - qui n'a pas changé - pendant 15 années.
Mais force est de constater que ça n'est pas le cas : ça fonctionne mais moins bien, c'est comme si ma voiture ne pouvait plus dépasser le 110 sur l'autoroute, alors que c'est la même voiture et qu'elle faisait ça très bien avant.
Aujourd'hui les Google, Microsoft et Cie essaient de flinguer le mail.
Google en faisant un immense silo Gmail vers lequel il est difficile de communiquer quand on n'est pas dedans, mais qui envoie sans soucis : utilisateur@gmail = chez-moi-ça-marche, viens ici !
Microsoft en remplaçant le mail par Exchange, ce qui fait une autre forme de silo partiellement incompatible. On a moins de difficulté à communiquer depuis l'extérieur, mais ça noyaute énormément d'entreprise qui de fait n'utilise plus le mail mais un service propriétaire nommé Exchange.
laposte.net c'est du mail.
Et aujourd'hui ça fonctionne moins bien parce que Google, Microsoft et Cie essaient de tuer le mail.
Voilà le cœur du problème.
Et on constate que laposte.net ne se foule pas beaucoup beaucoup pour essayer d'arranger la situation de leur côté, d'où la grogne…
@dataclass(frozen=False)classNumber:v:intp:intn:intdef__call__(self):returnself.v,self.p,self.n@propertydefnext(self):returnself.problem[self.n]@propertydefprevious(self):returnself.problem[self.p]@cached_propertydefmoves(self):returnself.value%(len(self.problem)-1)@cached_propertydefvalue(self):returnself.v*self.decryptionkey# Input handlingdefnumbers(data):lastid=len(data)-1yieldNumber(data[0],lastid,1)foriinrange(1,lastid):yieldNumber(data[i],i-1,i+1)yieldNumber(data[-1],lastid-1,0)defresult(problem):number=[xforxinproblemifx.v==0][0]for_inrange(1000):number=number.nextn1000=number.valuefor_inrange(1000):number=number.nextn2000=number.valuefor_inrange(1000):number=number.nextn3000=number.valuer=n1000+n2000+n3000returnrdefdecrypt(problem):fori,numberinenumerate(problem):ifnumber.v==0:continue# removes number from listnumber.previous.n=number.nnumber.next.p=number.psearch=numberfor_inrange(number.moves):search=search.next# search is now the new previousnumber.n=search.nnumber.p=search.next.p# Inserting numbernumber.next.p=inumber.previous.n=idata=[int(x)forxinsys.stdin.read().strip().splitlines()]# Problème n°1problem=list(numbers(data))Number.problem=problemNumber.decryptionkey=1decrypt(problem)print(f"First answer = {result(problem)}")# Problème n°2problem=list(numbers(data))Number.problem=problemNumber.decryptionkey=811589153for_inrange(10):decrypt(problem)print(f"Final answer = {result(problem)}")
Posté par Yth (Mastodon) .
En réponse au message Avent du Code, jour 20.
Évalué à 3.
Dernière modification le 20 décembre 2022 à 11:43.
J'ai codé ma propre liste chaînée, j'ai été intelligent avec mes modulos, j'ai une réponse sans ultra-optimiser en 4 secondes pour les données de test et les données réelles.
Et j'ai un bug.
Tout fonctionne au poil sur les données de test, les deux exercices, et les données réelles, mais pas le second sur données réelles !
Mauvais résultat.
Et j'ai beau triturer, je tombe toujours sur le mauvais résultat.
Alors j'ai recodé un peu différemment mes quelques lignes qui servent à déplacer un nombre dans la liste, je suis persuadé que fonctionnellement c'est identique, et ça fonctionne au super poil avec les données de test.
Mais je suis malade, ça explique peut-être.
En tout cas : résultat différent et correct cette fois-ci, avec un code un zest plus propre, mais à peine.
Sauf que dans le cas où le mouvement est de zéro, modulo, ben j'avais un effet de bord débile, je cassais ma liste…
Ici j'ai pas mal de modélisation de mon Block Tétris.
Vu l'ampleur de la tâche avant grosse réduction, cf messages précédents, je prévoyais de gagner le moindre micro-cycle d'horloge.
Donc quand on déplace à gauche, on teste les blocs de gauche, à droite ceux de droite, en bas ceux du bas.
La Simulation par contre devient complexe entre ma première version et la seconde…
Le code en brut. C'est bourré d'itérateurs de partout
importsysfromcollectionsimportdequedefleft(block,board=None):block.left(board)returnTruedefright(block,board=None):block.right(board)returnTruedefdown(block,board=None):returnblock.down(board)classBlock:x,y,w,h,X=2,0,0,0,6color=1def__init__(self,*tiles,color=None):self.color=colororself.colorself.all=tilesself.w=max(xforx,yintiles)+1self.h=max(yforx,yintiles)+1self.X=7-self.wself._left=set()self._right=set()self._down=set()forxinrange(self.w):down=Noneforyinrange(self.h):ifdownisNoneand(x,y)intiles:down=(x,y)self._down.add(down)foryinrange(self.h):left=Noneright=Noneforxinrange(self.w):ifleftisNoneand(x,y)intiles:left=(x,y)self._left.add(left)forxinreversed(range(self.w)):ifrightisNoneand(x,y)intiles:right=(x,y)self._right.add(right)def__call__(self,y):"""Reinit Block position at specific height, x always starts at 2"""self.y=yself.x=2returnselfdef__iter__(self):forx,yinself.all:yieldx+self.x,y+self.y@propertydefiright(self):forx,yinself._right:yieldx+self.x,y+self.y@propertydefileft(self):forx,yinself._left:yieldx+self.x,y+self.y@propertydefidown(self):forx,yinself._down:yieldx+self.x,y+self.ydefright(self,board):# move rightifself.x==self.X:returnFalseself.x+=1ifboardandself.irightinboard:self.x-=1returnFalsereturnTruedefleft(self,board):# move leftifself.x==0:returnFalseself.x-=1ifboardandself.ileftinboard:self.x+=1returnFalsereturnTruedefdown(self,board):# move downifself.y==0:returnFalseself.y-=1ifboardandself.idowninboard:self.y+=1returnFalsereturnTrueclassBoard:def__init__(self,w=7,h=0):self.w=wself.h=hself.dy=0self.map=[]self.resize()def__call__(self,x,y):returnself.map[y][x]defresize(self):for_inrange(len(self.map)+self.dy,self.h+4):# buffer of 4 blank linesself.map.append([0forxinrange(self.w)])iflen(self.map)>1000:self.dy+=len(self.map)-1000self.map=self.map[-1000:]definsert(self,block):forx,yinblock:self.map[y-self.dy][x]=block.colorself.h=max(self.h,block.y+block.h)self.resize()def__contains__(self,block):forx,yinblock:ifself.map[y-self.dy][x]:returnTruereturnFalseclassSimulation:def__init__(self,data,minblocks=2022,maxblocks=1000000000000):# Initialize thingsself.maxblocks=maxblocksself.minblocks=minblocksself.imoves=self.itermoves(data)self.iblocks=self.iterblocks()self.board=Board()self.heights=deque([0])self.history=dict()self.boardhash=dict()self.boardsnapshot=dict()self.count=0self.start()defstart(self):# Search for the first repeated full cycleself.searchfirstcycle()self.startlen=self.cycleend-2*self.cyclelenself.nbcycle,self.endlen=divmod(self.maxblocks-self.cycleend,self.cyclelen)self.extremities=self.cycleend+self.endlenwhileself.count<max(self.extremities,self.minblocks):self.iteration()self.startheight=self.heights[self.startlen]self.cycleheight=self.heights[self.cycleend]-self.heights[self.cyclestart]defsearchfirstcycle(self):whileTrue:status=self.iteration()# , str(self.board.map[-999:-5])ifstatusinself.history:# We may have a cycle, take a full snapshot !heightstart=self.heights[self.history[status]]heightend=self.heights[self.count]cycleboard=str(self.board.map[heightstart-heightend-5:-5])cyclehash=hash(cycleboard)if(self.boardhash.get(status,False)==cyclehashandself.boardsnapshot.get(status,False)==cycleboard):self.cyclestart=self.history[status]-1self.cycleend=self.count-1self.cyclelen=self.cycleend-self.cyclestartreturnself.boardhash[status]=cyclehashself.boardsnapshot[status]=cycleboardself.history[status]=self.countdefiteration(self):block=self.nextblock(self.board.h+3)for_inrange(7):# 7 automatic moves, no board impliedself.nextmove(block)whileself.nextmove(block,self.board):passself.board.insert(block)self.count+=1self.heights.append(self.board.h)returnself.idblock,self.idmovedefitermoves(self,input):_moves=[leftifc=='<'elserightforcininput]whileTrue:forid,moveinenumerate(_moves):self.idmove=idyieldmoveyielddown@propertydefnextmove(self):returnnext(self.imoves)defiterblocks(self):b1=Block((0,0),(1,0),(2,0),(3,0),color=1)b2=Block((0,1),(1,0),(1,1),(1,2),(2,1),color=2)b3=Block((0,0),(1,0),(2,0),(2,1),(2,2),color=3)b4=Block((0,0),(0,1),(0,2),(0,3),color=4)b5=Block((0,0),(0,1),(1,0),(1,1),color=5)whileTrue:self.idblock=0yieldb1self.idblock=1yieldb2self.idblock=2yieldb3self.idblock=3yieldb4self.idblock=4yieldb5@propertydefnextblock(self):returnnext(self.iblocks)s=Simulation(sys.stdin.read().strip())print("""[demo] Height of 2022 blocks: 3068[demo] Cycle of 35 blocks, 1 Cycle 60, 2 Cycles 113, Cycle height 53, Extremities height 131[demo] Total Height = 1514285714288[real] Height of 2022 blocks: 3153[real] Cycle of 1705 blocks, 1 Cycle 2648, 2 Cycles 5297, Cycle height 2649, Extremities height 7766[real] Total Height = 1553665689155""")print(f"2022 Blocks : {s.heights[2022]}")print(f"First part : {s.startlen}[{s.heights[s.startlen]}]")print(f"One Cycle : {s.cyclelen}[{s.cycleheight}]")print(f"Extremities : {s.extremities}[{s.heights[s.extremities]}]")s.totalheight=s.heights[s.extremities]+s.nbcycle*s.cycleheightprint(f"Total Height : {s.totalheight}")
D'abord la modélisation, avec des opérations sur triplets de matière Matters(ore, clay, obsidian). Dans un premier temps j'avais aussi geode, mais en vrai on ne produit, ne consomme, ni ne stocke de geode : c'est le score, on le gère à part.
En vrai ça change pas grand chose…
Un frozen dataclass, et les opérations retournent une nouvelle instance, ça permet d'éviter des risques de modifier un truc référencé ailleurs, et on y gagne en bugs et en perfs au bout du compte.
Chaque blueprint génère une Factory qui ne sert pas à grand chose, c'est des données, c'est figé, ça bouge pas.
Ensuite une classe d'état, State, qui stocke le temps restant, les stocks, la production, et le nombre de géodes à la fin si on touche plus à rien, donc le score actuel de cet état à la fin du temps imparti. Aussi un dataclass, je découvre, j'en mets partout, selon le biais bien connu de waooouh-nouveauté !
importsysimportreimportmathfromdataclassesimportdataclassfromfunctoolsimportcached_property@dataclass(frozen=True)classMatters():ore:int=0clay:int=0obsidian:int=0def__add__(self,other):returnMatters(self.ore+other.ore,self.clay+other.clay,self.obsidian+other.obsidian,)def__sub__(self,other):returnMatters(self.ore-other.ore,self.clay-other.clay,self.obsidian-other.obsidian,)def__mul__(self,t):# Calculate production in t minutesreturnMatters(self.ore*t,self.clay*t,self.obsidian*t,)def__call__(self,name):returnself.__dict__[name]@dataclass(frozen=True)classFactory:id:introbots:dict[Matters]@cached_propertydefmaxproduction(self):returnMatters(*(max(x)forxinzip(*[(m.ore,m.clay,m.obsidian)forminself.robots.values()])))@dataclassclassState:timeleft:intstock:Matters=Matters()production:Matters=Matters(1,0,0)geode:int=0def__lt__(self,other):returnself.geode<other.geodedefbuildable(self):return[(robot,self.factory.robots[robot],self.test_build_time)forrobotin["geode","obsidian","clay","ore"]ifself.isbuilduseful(self.factory.robots[robot])]defisbuilduseful(self,cost):t=self.timetobuild(cost)iftisFalse:returnFalse# This robot should have the time to produce somethingift>=self.timeleft:returnFalseself.test_build_time=treturnTruedeftimetobuild(self,cost):t=0ifcost.ore>self.stock.ore:t=max(math.ceil((cost.ore-self.stock.ore)/self.production.ore),t)ifcost.clay>self.stock.clay:ifnotself.production.clay:returnFalset=max(math.ceil((cost.clay-self.stock.clay)/self.production.clay),t)ifcost.obsidian>self.stock.obsidian:ifnotself.production.obsidian:returnFalset=max(math.ceil((cost.obsidian-self.stock.obsidian)/self.production.obsidian),t)returnt+1# Time to collect enough resources, +1 to build the robotdefbuildrobot(self,robot,cost,time):stock=self.stock+self.production*time-costtime=self.timeleft-timeifrobot=="geode":returnState(time,stock,self.production,self.geode+time)returnState(time,stock,self.production+Matters(**{robot:1}),self.geode)def__str__(self):returnf"State Score={self.geode}, TimeLeft={self.timeleft}, "\
f"Production={self.production}, Stocks={self.stock}"
Ensuite le code en lui-même :
defiteration(state):buildable=state.buildable()ifnotbuildable:# end of the line !returnstate,1explored=0r=stateifbuildable[0][0]=="geode"andbuildable[0][2]==1:buildable=buildable[:1]forrobot,cost,timeinbuildable:ifrobot!="geode"andstate.production(robot)>=state.factory.maxproduction(robot):continues,e=iteration(state.buildrobot(robot,cost,time))explored+=er=sifr<selserifnotexplored:# robot limit attainedstate,1returnr,exploreddefinput():rematter=r"ore|clay|obsidian|geode"rerobot=re.compile(fr"Each ({rematter}) robot costs (.*)")recost=re.compile(fr"(\d+) ({rematter})")forblueprintinsys.stdin:id,blueprint=blueprint.strip().split(":")yieldFactory(int(id.split()[-1]),{build:Matters(**{b:int(a)fora,binrecost.findall(cost)})forrobotinblueprint.strip(".").split(".")forbuild,costin(rerobot.match(robot.strip()).groups(),)})defex1(factories):score=0expl=0forfinfactories:State.factory=fbeststate,explored=iteration(State(timeleft=24))print(f"Blueprints#{f.id} Best of {explored} State {str(beststate)}")score+=f.id*beststate.geodeexpl+=exploredprint(f"Score final = {score} (33, 1599) {expl} chemins explorés")defex2(factories):score=1expl=0forfinfactories:State.factory=fbeststate,explored=iteration(State(timeleft=32))print(f"Blueprints#{f.id} Best of {explored} State {str(beststate)}")score*=beststate.geodeexpl+=exploredprint(f"Score final = {score} ({56*62}, {49*18*16}) {expl} chemins explorés")factories=list(input())ex1(factories)ex2(fforfinfactoriesiff.id<=3)
Posté par Yth (Mastodon) .
En réponse au message Avent du Code, jour 19.
Évalué à 2.
Dernière modification le 19 décembre 2022 à 15:24.
Non, on n'a qu'une seule usine de robots, donc c'est un par tour…
À noter ici que la différence entre cpython et pypy est assez délirante.
J'ai nettoyé le code, je suis à 8 secondes avec pypy3, et 2 minutes 30 avec python3 !
Et en optimisant un pouille mes structures de données (dataset immutable, ne pas recopier les données statiques dans les nouvelles instances de classes, mais les mettre en dur dans la classe, etc), je descends à 29 secondes pour les données de test et 10s pour les données réelles !
[^] # Re: Mode triche on
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 22. Évalué à 4.
Le switch de 1 à 6 applique les rotations, et déplacements en 3D pour poser la surface de la face du cube sur la face du cube 3D, j'ai dû inverser des trucs à des endroits.
C'est sous optimisé pour de l'openScad, mais j'ai fait ça rapidement, on génère tout de même 15000 objets (50x50x6), ça le perturbe pas beaucoup cela dit !
Le fichier scad est xzippé ici : aoc-2022-22-01.scad.xz
Et OpenScad se trouve dans toutes les bonnes crémeries de logiciels libres ;)
[^] # Re: Mode triche on
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 22. Évalué à 4.
Un truc dans ce goût là mais mieux fait parce que là c'est pas raccord, j'ai dû me planter dans mes rotations ^
[^] # Re: Mode triche on
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 22. Évalué à 5.
Ma grippe m'a rattrapé, le premier exo nickel, le second j'ai cédé comme toi sur les données des faces et rotations, et passé des heures à débugger un code bon à jeter !
Mon dernier code tombe enfin sur le bon résultat, mais je sais pas bien pourquoi par rapport aux précédents.
L'algo est bon depuis ce matin 9h30 environ…
C'est juste qu'il est mal écrit, et que j'arrive à rien :)
Dommage, si j'avais été plus vite, j'aurais peut-être essayé une représentation.
[^] # Re: Question naïve aux lutins du Père Noël qui font l'Avent du code
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 21. Évalué à 2.
Parfois, les résultats, c'est juste un nombre débile sans autre intérêt que de valider qu'on a un algo qui fonctionne.
Par contre dans certains exercices il y a des visualisations sympas, comme les écoulements de sables, ou la géode en OpenSCAD.
[^] # Re: Modélisation trop longue à débugger
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 19. Évalué à 2.
Oui, je l'ai fait instinctivement, mais après c'est apparu évident.
En pratique on maximise toujours l'ore dans les chemins gagnants, mais pas en construisant tout d'un coup.
[^] # Re: Un bug que j'ai résolu sans jamais le trouver.
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 20. Évalué à 2.
C'est clair, on fait de belles modélisations, alors que la solution d'Éric cartonne tout.
Possible que la liste chaînée devienne plus performante si on a des millions d'éléments, mais à 5000, on se fait laminer.
[^] # Re: Pas de force brute, mais soyons bourrins, oh oui, bourrins !
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 21. Évalué à 2. Dernière modification le 21 décembre 2022 à 10:51.
Donc je vire mon iteration2 puis :
Et voilà !
Finalement c'était facile à utiliser :D
[^] # Re: Pas de force brute, mais soyons bourrins, oh oui, bourrins !
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 21. Évalué à 2.
Nope, si j'avais connu sympy je l'aurais utilisé.
Jadis j'avais un truc qui faisait ça sur ma HP48GX !
Je savais qu'un truc du genre existait en Python, mais j'ai jugé que le chercher et apprendre à l'utiliser serait plus long que de bourriner :)
# Pas de force brute, mais soyons bourrins, oh oui, bourrins !
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 21. Évalué à 2.
Pour l'exo 1 je fais du re.findall, str.replace, re.sub, et un gros eval dès que j'ai root.
Youpi, bourrin :)
Pour le 2, bah non.
On remplace
root: truc * much
parroot: truc - much
, ethumn: ????
parhumn: X
À la fin on a une grosse opération bourrée de parenthèses, avec au fond du fond
(X)
, il faut résoudrece truc = 0
.Donc on remonte en inversant les opérations, chaque parenthèse est
(nombre opération (trucs...))
ou((trucs...) opération nombre)
, des gros if tout moches, et à la fin le résultat.Sans finesse ça va assez vite : une demi seconde.
Zéro modélisation, à peine de la réflexion, zéro optimisations sauf l'eval ajouté dans l'iteration1 quand on peut réduire à un nombre, basta.
[^] # Re: pour les raleurs : Que disent les conditions d'utilisation sur la fiabilité du service fourni ?
Posté par Yth (Mastodon) . En réponse au journal La Poste pas nette a encore du mal avec le courrier. Évalué à 4.
Je n'ai jamais écrit que laposte.net était responsable de ce qui se passe :
Ce n'est pas rendre laposte.net responsable.
C'est l'explication des mécontentements.
Et oui, ils sont mal dirigés les mécontentements, mais on est en France, c'est vachement plus facile de tape sur La Poste que sur un MAGAF, c'est limite culturel !
Par contre Ferrari serait un peu responsable de continuer à te vendre une voiture qui ne peut plus rouler nulle part…
[^] # Re: Erreur bete
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 19. Évalué à 2.
Parcourir en largeur et virer les chemins pourraves, c'pas mal.
Mon algo parcours en profondeur, j'ai pas cette possibilité sauf à le refaire…
Une idée de comment être raisonnablement sûr que tu as la meilleure solution en limitant à 100 ?
[^] # Re: Modélisation trop longue à débugger
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 19. Évalué à 2.
C'est pas mal de ne pas aller jusqu'au bout si on sait déjà qu'on sera en-dessous du meilleur temps.
J'ai ajouté un truc comme ça sur mon code, ça fonctionne nickel, et je divise le temps par deux, je suis à 5s pour les deux exercices.
Je passe de 492 462 chemins à 46 859 sur l'exo 1.
Et au total de 4 661 927 à 755 262 sur l'exo 2.
Vu la réduction sévère du nombre de chemins, je me demande où le temps est perdu tout de même…
[^] # Re: Un bug que j'ai résolu sans jamais le trouver.
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 20. Évalué à 2. Dernière modification le 20 décembre 2022 à 15:18.
Faut aussi que 0 reste (0, 0), pour le retrouver à la fin.
Mais ça gagne 35% de temps :)
Bravo, j'admire la simplicité !
[^] # Re: Un bug que j'ai résolu sans jamais le trouver.
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 20. Évalué à 4. Dernière modification le 20 décembre 2022 à 15:02.
C'est tellement plus intelligent que ce que j'ai fait, je suis jaloux !
Je ne pensais pas que les listes seraient assez performantes, j'aurais dû essayer.
Bravo !
Tu peux pas faire ça plutôt ?
Tu t'en fous du nombre d'occurrence, ce que tu veux c'est que chaque élément de la liste soit unique.
[^] # Re: pour les raleurs : Que disent les conditions d'utilisation sur la fiabilité du service fourni ?
Posté par Yth (Mastodon) . En réponse au journal La Poste pas nette a encore du mal avec le courrier. Évalué à 10.
Alors, juste comme ça, j'ai aussi une adresse @laposte.net, depuis une vingtaine d'années, que j'utilise de moins en moins.
Le service rendu pendant 15 ans était parfait, c'est à dire que je pouvais envoyer des mails à des gens, et en recevoir.
Donc je n'ai pas souscrits une adresse mail pour utiliser une Ferrari dans la gadoue ou forer de la pierre avec un forêt à métal, et le service a été parfaitement adapté au besoin - qui n'a pas changé - pendant 15 années.
Mais force est de constater que ça n'est pas le cas : ça fonctionne mais moins bien, c'est comme si ma voiture ne pouvait plus dépasser le 110 sur l'autoroute, alors que c'est la même voiture et qu'elle faisait ça très bien avant.
Aujourd'hui les Google, Microsoft et Cie essaient de flinguer le mail.
Google en faisant un immense silo Gmail vers lequel il est difficile de communiquer quand on n'est pas dedans, mais qui envoie sans soucis : utilisateur@gmail = chez-moi-ça-marche, viens ici !
Microsoft en remplaçant le mail par Exchange, ce qui fait une autre forme de silo partiellement incompatible. On a moins de difficulté à communiquer depuis l'extérieur, mais ça noyaute énormément d'entreprise qui de fait n'utilise plus le mail mais un service propriétaire nommé Exchange.
laposte.net c'est du mail.
Et aujourd'hui ça fonctionne moins bien parce que Google, Microsoft et Cie essaient de tuer le mail.
Voilà le cœur du problème.
Et on constate que laposte.net ne se foule pas beaucoup beaucoup pour essayer d'arranger la situation de leur côté, d'où la grogne…
[^] # Re: Un bug que j'ai résolu sans jamais le trouver.
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 20. Évalué à 4.
# Un bug que j'ai résolu sans jamais le trouver.
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 20. Évalué à 3. Dernière modification le 20 décembre 2022 à 11:43.
J'ai codé ma propre liste chaînée, j'ai été intelligent avec mes modulos, j'ai une réponse sans ultra-optimiser en 4 secondes pour les données de test et les données réelles.
Et j'ai un bug.
Tout fonctionne au poil sur les données de test, les deux exercices, et les données réelles, mais pas le second sur données réelles !
Mauvais résultat.
Et j'ai beau triturer, je tombe toujours sur le mauvais résultat.
Alors j'ai recodé un peu différemment mes quelques lignes qui servent à déplacer un nombre dans la liste, je suis persuadé que fonctionnellement c'est identique, et ça fonctionne au super poil avec les données de test.
Mais je suis malade, ça explique peut-être.
En tout cas : résultat différent et correct cette fois-ci, avec un code un zest plus propre, mais à peine.
Sauf que dans le cas où le mouvement est de zéro, modulo, ben j'avais un effet de bord débile, je cassais ma liste…
Bref, ça aurait dû aller vite, mais pas.
[^] # Re: python tranquille
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 18. Évalué à 2.
Ah, super idée OpenSCAD !
Je connais un poil…
Merci !
[^] # Re: pour les raleurs : Que disent les conditions d'utilisation sur la fiabilité du service fourni ?
Posté par Yth (Mastodon) . En réponse au journal La Poste pas nette a encore du mal avec le courrier. Évalué à 4.
Ouais !
Et pis c'est toujours mieux quand c'est la faute de la victime en plus !
[^] # Re: Côté code
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 17. Évalué à 2.
et le Block.color sert à un truc :
On affiche en couleur le Tetris des n-4 dernières lignes (les 4 du haut sont toujours vides).
# Côté code
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 17. Évalué à 2.
Ici j'ai pas mal de modélisation de mon Block Tétris.
Vu l'ampleur de la tâche avant grosse réduction, cf messages précédents, je prévoyais de gagner le moindre micro-cycle d'horloge.
Donc quand on déplace à gauche, on teste les blocs de gauche, à droite ceux de droite, en bas ceux du bas.
La Simulation par contre devient complexe entre ma première version et la seconde…
Le code en brut. C'est bourré d'itérateurs de partout
# Du code, du code, du code !
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 19. Évalué à 4.
D'abord la modélisation, avec des opérations sur triplets de matière Matters(ore, clay, obsidian). Dans un premier temps j'avais aussi geode, mais en vrai on ne produit, ne consomme, ni ne stocke de geode : c'est le score, on le gère à part.
En vrai ça change pas grand chose…
Un frozen dataclass, et les opérations retournent une nouvelle instance, ça permet d'éviter des risques de modifier un truc référencé ailleurs, et on y gagne en bugs et en perfs au bout du compte.
Chaque blueprint génère une Factory qui ne sert pas à grand chose, c'est des données, c'est figé, ça bouge pas.
Ensuite une classe d'état, State, qui stocke le temps restant, les stocks, la production, et le nombre de géodes à la fin si on touche plus à rien, donc le score actuel de cet état à la fin du temps imparti. Aussi un dataclass, je découvre, j'en mets partout, selon le biais bien connu de waooouh-nouveauté !
Ensuite le code en lui-même :
Voilà voilà…
[^] # Re: Modélisation trop longue à débugger
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 19. Évalué à 2. Dernière modification le 19 décembre 2022 à 15:24.
Non, on n'a qu'une seule usine de robots, donc c'est un par tour…
À noter ici que la différence entre cpython et pypy est assez délirante.
J'ai nettoyé le code, je suis à 8 secondes avec pypy3, et 2 minutes 30 avec python3 !
[^] # Re: python tranquille
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 18. Évalué à 2.
Jolie la visualisation !
Tu fais ça comment ?
[^] # Re: Modélisation trop longue à débugger
Posté par Yth (Mastodon) . En réponse au message Avent du Code, jour 19. Évalué à 3.
Et en optimisant un pouille mes structures de données (dataset immutable, ne pas recopier les données statiques dans les nouvelles instances de classes, mais les mettre en dur dans la classe, etc), je descends à 29 secondes pour les données de test et 10s pour les données réelles !