Je n'ai pas encore résolu le problème de ce jour, dimanche c'est famille, mais ça va venir. 🙂
En lisant l'énoncé, tout de même, je m'étais dit que ça devait faire des nombres qui monteraient bien vite. En y réfléchissant, je pense que j'aurais tout seul pensé à travailler modulo leur PGCD.
Pour le code d'opération, l'eval vient tout de suite en tête bien sûr, mais ça me donne quand même quelques boutons, d'écrire du code qui a l'air d'un trou de sécurité. Réflexe professionnel je pense. À suivre, je dois toujours coder ça de toute façon.
J'ai pas modélisé un CPU complet comme Tanguy, c'est un peu l'enclume pour écraser la mouche.
Ça reste à voir, ça. Il y a eu un AoC où on n'arrêtait pas de ressortir un processeur bizarroïde pour l'enrichir de nouvelles instructions et variantes d'instructions existantes.
Il y a un risque pour que ce ne soit pas la dernière fois que nous aurons à bidouiller avec du code machine de communicateur elfique…
Oui, la seconde partie apparaît alors avoir rentré la bonne réponse à la première partie. Et les données d'entrée et donc les bonnes réponses sont associées à une identité en effet.
Sans surprise, j'ai implémenté un CPU selon les spécifications fournies. Mais pour ce qui est de faire quelque chose à partir des états qu'il atteint à des cycles donnés, je me suis amusé à y introduire ce que j'ai appelé un débogueur, je vous laisse découvrir ça.
importiofromenumimportEnumfromtypingimportCallable,Iterable,Iterator,List,Optional,TupleclassOperation(Enum):addx=('addx',1,2)noop=('noop',0,1)def__init__(self,word:str,nargs:int,cycles:int)->None:self.word=wordself.nargs=nargsself.cycles=cyclesclassInstruction:def__init__(self,op:Operation,*args:int)->None:self.op=opiflen(args)!=op.nargs:raiseValueError("operator {} expect {} arguments".format(op,op.nargs))self.args=argsclassCPU:def__init__(self,program:Iterable[Instruction],debug:Optional[Callable[[int,int],None]]=None)->None:self.X=1self.cycle=1self.program=programself.debug=debugdef_apply(self,instruction:Instruction)->None:ifinstruction.opisOperation.addx:self.X+=instruction.args[0]elifinstruction.opisOperation.noop:passdef_cycle(self)->None:ifself.debugisnotNone:self.debug(self.cycle,self.X)self.cycle+=1defrun(self)->None:last_instruction=Noneforinstructioninself.program:for_inrange(instruction.op.cycles):self._cycle()self._apply(instruction)defimport_program(lines:Iterable[str])->Iterator[Instruction]:forlineinlines:words=line.split()op=Operation[words[0]]args=[int(word)forwordinwords[1:]]yieldInstruction(op,*args)classStrengthSum:def__init__(self)->None:self.strength=0def__call__(self,cycle:int,value:int)->None:ifcyclein(20,60,100,140,180,220):self.strength+=cycle*valueclassCRTDrawer:def__init__(self)->None:self.crt=io.StringIO()@staticmethoddefposition(cycle:int)->int:return(cycle-1)%40def__call__(self,cycle:int,value:int)->None:position=self.position(cycle)ifposition==0:self.crt.write('\n')ifvalue-1<=position<=value+1:self.crt.write('█')else:self.crt.write(' ')classMultiDebug:def__init__(self,*debugs:Callable[[int,int],None])->None:self.debugs=debugsdef__call__(self,cycle:int,value:int)->None:fordebuginself.debugs:debug(cycle,value)defsolve_both(lines:Iterable[str])->Tuple[int,str]:"""Solve part 1 of today's puzzle"""program=import_program(lines)strength_report=StrengthSum()crt_drawer=CRTDrawer()cpu=CPU(program,debug=MultiDebug(strength_report,crt_drawer))cpu.run()returnstrength_report.strength,crt_drawer.crt.getvalue()
Bon, en fait, pas besoin d'énumérer de façon aussi laborieuse bien sûr :
from__future__importannotationsfromenumimportEnumfromtypingimportIterable,Iterator,Set,TupleCoords=Tuple[int,int]classDirection(Enum):O=(0,0)U=(0,1)D=(0,-1)L=(-1,0)R=(1,0)def__init__(self,dx,dy):self.dx=dxself.dy=dyclassKnot:def__init__(self,x:int,y:int):self.x=xself.y=y@propertydefcoords(self)->Coords:return(self.x,self.y)defmove(self,direction:Direction)->None:self.x+=direction.dxself.y+=direction.dydefdist(self,other:Knot)->int:returnmax(abs(self.x-other.x),abs(self.y-other.y))deffollow(self,other:Knot)->None:ifself.dist(other)<=1:returnifself.x<other.x:self.x+=1ifself.x>other.x:self.x-=1ifself.y<other.y:self.y+=1ifself.y>other.y:self.y-=1classRope:def__init__(self,n_knots:int)->None:self.knots=[Knot(0,0)for_inrange(n_knots)]@propertydefhead(self)->Knot:returnself.knots[0]@propertydeftail(self)->Knot:returnself.knots[-1]defmove(self,direction:Direction)->None:self.head.move(direction)foriinrange(1,len(self.knots)):leader=self.knots[i-1]follower=self.knots[i]follower.follow(leader)defimport_lines(lines:Iterable[str])->Iterator[Direction]:forlineinlines:word1,word2=line.split()direction=Direction[word1]repeat=int(word2)for_inrange(repeat):yielddirectiondefsolve_both(lines:Iterable[str])->Tuple[int,int]:"""Solve both parts of today's puzzle"""rope=Rope(10)visited1=set()# type: Set[Coords]visited2=set()# type: Set[Coords]fordirectioninimport_lines(lines):rope.move(direction)visited1.add(rope.knots[1].coords)visited2.add(rope.tail.coords)returnlen(visited1),len(visited2)
#! /usr/bin/python3# Advent of Code 2022, day 9from__future__importannotationsfromenumimportEnumfromtypingimportIterable,Iterator,Set,TupleCoords=Tuple[int,int]classDirection(Enum):O=(0,0)U=(0,1)D=(0,-1)L=(-1,0)R=(1,0)UL=(-1,1)UR=(1,1)DL=(-1,-1)DR=(1,-1)def__init__(self,dx,dy):self.dx=dxself.dy=dyclassKnot:def__init__(self,x:int,y:int):self.x=xself.y=y@propertydefcoords(self)->Coords:return(self.x,self.y)defmove(self,direction:Direction)->None:self.x+=direction.dxself.y+=direction.dydefdist(self,other:Knot)->int:""""Chebyshev distance! (Not really used in my code, actually)"""returnmax(abs(self.x-other.x),abs(self.y-other.y))defdirection_to(self,other:Knot)->Direction:dx=other.x-self.xdy=other.y-self.yifdx<-1:ifdy<0:returnDirection.DLifdy==0:returnDirection.Lifdy>0:returnDirection.ULifdx==-1:ifdy<-1:returnDirection.DLif-1<=dy<=1:returnDirection.Oifdy>1:returnDirection.ULifdx==0:ifdy<-1:returnDirection.Dif-1<=dy<=1:returnDirection.Oifdy>1:returnDirection.Uifdx==1:ifdy<-1:returnDirection.DRif-1<=dy<=1:returnDirection.Oifdy>1:returnDirection.URifdx>1:ifdy<0:returnDirection.DRifdy==0:returnDirection.Rifdy>0:returnDirection.URassertFalse# cannot happen, all cases were covereddeffollow(self,other:Knot)->None:self.move(self.direction_to(other))classRope:def__init__(self,n_knots:int)->None:self.knots=[Knot(0,0)for_inrange(n_knots)]@propertydefhead(self)->Knot:returnself.knots[0]@propertydeftail(self)->Knot:returnself.knots[-1]defmove(self,direction:Direction)->None:self.head.move(direction)foriinrange(1,len(self.knots)):leader=self.knots[i-1]follower=self.knots[i]follower.follow(leader)defimport_lines(lines:Iterable[str])->Iterator[Direction]:forlineinlines:word1,word2=line.split()direction=Direction[word1]repeat=int(word2)for_inrange(repeat):yielddirectiondefsolve_both(lines:Iterable[str])->Tuple[int,int]:"""Solve both parts of today's puzzle"""rope=Rope(10)visited1=set()# type: Set[Coords]visited2=set()# type: Set[Coords]fordirectioninimport_lines(lines):rope.move(direction)visited1.add(rope.knots[1].coords)visited2.add(rope.tail.coords)returnlen(visited1),len(visited2)
J'aurais bien aimé éviter d'énumérer tous les cas de mouvement de suivi, mais je n'ai rien trouvé d'astucieux pour éviter cela.
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…
Une petite optimisation pour la première partie : si on arrive à une hauteur de 9, pas la peine de regarder plus loin, aucun arbre ne sera plus haut que ça.
Mais bon, la seconde partie est bien plus coûteuse en temps de toute façon.
Alors qu'on a enfin quitté le camp pour aller chercher des caramboles, je ne peux m'empêcher que ça procrastine encore :
– Voilà, le verger c'est par là…
– Oh, regardez, la forêt que nous avons planté il y a quelques années, on pourrait y construire une cabane !
– Oui, super, ça nous changera les idées. Lutin drone-opérateur, tu nous cartographie ça ?
– Patron, venez nous donner un coup de main pour calculer le meilleur emplacement pour notre cabane au lieu d'essayer de régler votre communicateur. On vous l'a déjà dit, il est défectueux, et vous aurez tout le temps pour le réparer plus tard. On a plus important à faire là !
– Et les fruits pour les rennes alors ?
– Les quoi ? Ah, ça… On n'y est pas encore, soyez patient. Vous êtes pressé, vous avez un rendez-vous qui approche ou quoi ?
Bon, j'ai sorti Numpy du coup. C'est modélisé, et assez long en fait.
# Advent of Code 2022, day 8from__future__importannotationsfrommathimportprodfromtypingimportIterable,Iterator,Set,Tuple,TypeimportnumpyasnpCoords=Tuple[int,int]classGrid:def__init__(self,matrix:np.ndarray)->None:self.matrix=matrixself.ly=matrix.shape[0]self.lx=matrix.shape[1]def__scans(self)->Iterator[Iterator[Iterator[Coords]]]:yield(((y,x)forxinrange(self.lx))foryinrange(self.ly))yield(((y,x)forxinrange(self.lx-1,-1,-1))foryinrange(self.ly))yield(((y,x)foryinrange(self.ly))forxinrange(self.lx))yield(((y,x)foryinrange(self.ly-1,-1,-1))forxinrange(self.lx))defvisible_from_outside(self)->Set[Coords]:visible_trees=set()# type: Set[Coords]forscaninself.__scans():forlineinscan:max_height=-1forcoordsinline:cur_height=self.matrix[coords]ifcur_height>max_height:visible_trees.add(coords)max_height=cur_heightreturnvisible_treesdef__viewing_distance(self,orig:Coords,line:Iterator[Coords])->int:height=self.matrix[orig]d=0forcoordsinline:d+=1ifself.matrix[coords]>=height:returndreturnddef__lines_of_sight(self,coords:Coords):y,x=coordsyield((y,x_)forx_inrange(x+1,self.lx))yield((y,x_)forx_inrange(x-1,-1,-1))yield((y_,x)fory_inrange(y+1,self.ly))yield((y_,x)fory_inrange(y-1,-1,-1))defscenic_score(self,coords:Coords):returnprod(self.__viewing_distance(coords,line)forlineinself.__lines_of_sight(coords))@classmethoddefimport_lines(class_:Type[Grid],lines:Iterable[str])->Grid:matrix=np.genfromtxt(lines,delimiter=1,autostrip=True,dtype=int)returnclass_(matrix)defsolve_both(lines:Iterable[str])->Tuple[int,int]:"""Solve both parts of today's puzzle"""# Importgrid=Grid.import_lines(lines)# Part 1visible=len(grid.visible_from_outside())# Part 2max_score=max(grid.scenic_score(coords)forcoordsinnp.ndindex(grid.matrix.shape))returnvisible,max_score
En fait, en matière d'assurance, et d'assurance de quoi que ce soit en fait, je pense qu'il serait possible d'autoriser la modulation de cotisation en fonction de n'importe quoi qui relève du choix de l'assuré, à condition que le traitement des informations correspondantes soit légal évidemment. L'âge et l'état de santé par exemple, ne relèvent pas du tout du choix.
Mais le tabagisme, le nombre d'infractions routières ou encore le nombre de soirées passées au cinéma chaque mois, relèvent du choix. Le dernier exemple n'a rien de pertinent, mais inutile d'interdire la modulation d'un tarif en fonction de cela : lorsque ce n'est pas pertinent, c'est inintéressant à appliquer, parce que cela ne correspond pas au risque assuré, que ça attirera juste une clientèle spécifique et que la remise correspondante s'avérera coûteuse pour l'assureur.
Du moment où ils ont la permission de ne moins payer la cotisation retraite (espérance de vie moindre) et de ne pas payer les taxes déjà actuelles sur les cigarettes (pas payer 2x la même chose), ok, ils vont applaudir les fumeurs de ne payer que ce qu'ils coûtent comme tu le souhaites!
Il y a plusieurs choses là-dedans. Les taxes ont deux rôles :
financer le coût des soins pour les fumeurs : avec une possibilité de tarifier différemment l'assurance santé, ça devrait effectivement disparaître ;
financer le coût des soins aux victimes de tabagisme passif : ça doit rester ;
dissuader le tabagisme, notamment à cause des nuisances qu'il représente : ça doit rester aussi.
et les accidentés vélotafs sont actuellement acceptés sans surcoût mais si tu veux des différences je militerai pour que toi tu payes un max suivant l'usage vélotaf que je jugerai pour toi comme plus dangereux que train, X ou Y tout aussi subjectif que toi
Ça n'a rien de subjectif, ça a été étudié, et surprise, le vélotaf est dangereux, mais ne pas en faire l'est encore plus. Les assureurs sont d'accord, ce qui est l'essentiel, dans cette discussion.
C'est surtout démagogique pour te croire mieux que d'autres, pas factuel.
Non, pas du tout, c'est une question de justice. C'est comme les assurances emprunteur par exemple : non fumeur, ça coûte moins cher que fumeur, c'est juste normal. Et ça ne pénalise que ceux qui le veulent bien.
PS : perso si on va dans cette direction je serai plus sur faire sur-cotiser les non-vaccinés de tout poil (vous avez fait vos rappels adultes?) car un choix très individuel et calcul de risque qui fait que ça coûte plus (et c'est ce qu'on fait des assurances US) sans apporter assez ailleurs (risque de survivre après réa, pas d'autres taxes déjà en cours), mais la ça risque de troller :).
Pas forcément moduler ainsi les cotisations, simplement permettre de le faire. Pour la vaccination, c'est pertinent aussi en effet. Beaucoup plus pertinent qu'une obligation plus ou moins forte en fait, puisqu'il s'agit de répercuter directement le coût statistique d'un choix personnel sur le budget de celui qui le fait. Pour responsabiliser les gens, on ne peut pas faire mieux je pense. Tant qu'il s'agit simplement de critères qui relèvent du choix des gens, aucun problème.
On dirait que le Père Noël, ou les lutins, ou les deux, ne sont pas si motivés que ça pour aller effectivement courir la jungle pour récolter des caramboles. Ça traîne à faire des inventaires, à monter le camp, à nettoyer le camp, à décharger le bateau, à réorganiser le matériel déchargé, à bidouiller des communicateurs, à mettre à jour ces communicateurs…
Ça fait six jours qu'on a débarqué, et n'a pas encore bougé du camp ! Vivement que les lutins nous fournissent une carte pour aller quelque part.
En fait vu la structure de l'input où il n'y a que de cd child et cd .. # parent, c'est nécessairement un parcours d'arbre en profondeur d'abord.
$ cd /
$ ls
4212 aoc.py
dir 2021
dir 2022
$ cd 2021
$ ls
dir 12
$ cd ..
$ cd 2022
$ ls
dir 12
$ cd ..
$ cd 2021
$ cd 12
$ ls
42 01.py
12 02.py
51 03.py
$ cd ..
$ cd ..
$ cd 2022
$ cd 12
$ ls
12 01.py
51 02.py
42 03.py
C'est idiot, on est d'accord. Mais ce n'est pas un parcours en profondeur d'abord.
def__invert__(self):"""~chifumi returns value in [1, 2, 3]"""return(self.chifumi%3)or3
Si je comprends bien, ça fait de ~ une opération pour récupérer la valeur normalisée. Bien joué le (valeur % 3) or 3, c'est bien plus lisible que (valeur - 1) % 3 + 1.
Je suis plus inférieur à un autre si la valeur qui me vainc est la même que la valeur normalisée de l'autre. Et mutatis mutandis pour la supériorité. Tu aurais pu utiliser functool.total_ordering().
Ensuite, le reste est assez simple à comprendre, une fois ces bases posées. La réutilisation des opérateurs est… intéressante. Je ne peux pas dire que je suis fan, c'est un peu bizarre à lire quand même.
Le jour où j'aurai le choix de mon prestataire de sécu (comme par exemple en Allemagne, qui pour une fois fait les choses largement plus intelligemment, tu as le choix de l'entité qui fait en même temps base obligatoire et complémentaire optionnelle avec les mêmes règles pour le paiement; qu'on se rassure, ils ont merdé ailleurs en permettant du "privé" qui ne respectent pas ces règles. Et sur quoi se battent les différentes entités si elles ne peuvent jouer sur le prix? Sur la qualité de prestation!), je changerai et ferai la différence entre la sécu couverture obligatoire et la sécu entité à laquelle je me suis inscrite.
Je suis tout aussi critique que toi sur le fait de ne pas avoir le choix. Je rêve d'avoir le choix entre la CPAM et d'autres assureurs. Et je ne vois pas le problème que ça poserait, du moment que la couverture est règlementée (obligation de couvrir au moins ceci et cela à tel taux ou plafond de remboursement), ainsi et que l'éligibilité et la tarification différenciée : concrètement, interdiction de refuser les vieux et les cancéreux et de leur faire payer plus cher parce que ce n'est pas un choix, mais permission de faire payer plus cher les fumeurs, et moins cher les gens qui font trois heures d'exercice par semaine, vélotaf inclus.
Et surtout pas de yield dans la fonction recursive qui aplatit les repertoires (je copie les references dans une nouvelle list). J'avoue que ta solution est plus elegante, et c'est marrant que tu fasses du code presque prod ready (mypy…).
Je profite en fait de l'AoC pour découvrir les fonctionnalités de typage de Python. Une fois passé l'apprentissage, qui n'est vraiment pas horrible, ça ne fait pas perdre du temps, au contraire, ça permet de détecter certaines erreurs de façon bien plus rapide et de mieux identifier d'où elles viennent.
Comme le FS est parcourus "en profondeur d'abord" et dans l'ordre, pas besoin d'une structure de données trop compliquée type arbre, une simple liste suffit.
Bien joué, je n'avais pas remarqué cela. Ceci dit, je n'aime pas trop me baser sur des suppositions qui ne sont absolument pas garanties par l'énoncé.
[^] # Re: À la chasse aux singes, j'envoie le Python !
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 11. Évalué à 3.
Euh, modulo leur PPCM évidemment !
[^] # Re: À la chasse aux singes, j'envoie le Python !
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 11. Évalué à 4.
Je n'ai pas encore résolu le problème de ce jour, dimanche c'est famille, mais ça va venir. 🙂
En lisant l'énoncé, tout de même, je m'étais dit que ça devait faire des nombres qui monteraient bien vite. En y réfléchissant, je pense que j'aurais tout seul pensé à travailler modulo leur PGCD.
Pour le code d'opération, l'eval vient tout de suite en tête bien sûr, mais ça me donne quand même quelques boutons, d'écrire du code qui a l'air d'un trou de sécurité. Réflexe professionnel je pense. À suivre, je dois toujours coder ça de toute façon.
[^] # Re: En Python, modélisé
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 9. Évalué à 4.
Eh oh, je sais que j'écris du code-fleuve, mais pas la peine de se moquer non plus !
[^] # Re: Plus simple
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 10. Évalué à 3.
Ça reste à voir, ça. Il y a eu un AoC où on n'arrêtait pas de ressortir un processeur bizarroïde pour l'enrichir de nouvelles instructions et variantes d'instructions existantes.
Il y a un risque pour que ce ne soit pas la dernière fois que nous aurons à bidouiller avec du code machine de communicateur elfique…
[^] # Re: Où est la partie 2 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 10. Évalué à 4.
Oui, la seconde partie apparaît alors avoir rentré la bonne réponse à la première partie. Et les données d'entrée et donc les bonnes réponses sont associées à une identité en effet.
# En Python, modélisé
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 10. Évalué à 5. Dernière modification le 10 décembre 2022 à 13:03.
Sans surprise, j'ai implémenté un CPU selon les spécifications fournies. Mais pour ce qui est de faire quelque chose à partir des états qu'il atteint à des cycles donnés, je me suis amusé à y introduire ce que j'ai appelé un débogueur, je vous laisse découvrir ça.
[^] # Re: En Python, modélisé
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 9. Évalué à 4. Dernière modification le 09 décembre 2022 à 18:05.
Tu peux te passer de la position initiale dans l'ensemble des positions visitées : après le premier mouvement, la queue de la corde y sera toujours.
# Coin coin
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 9. Évalué à 4.
Le problème parle de corde à nœuds, mais m'évoquerait plutôt une canne et ses canetons, pas vous ?
[^] # Re: En Python, modélisé
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 9. Évalué à 3. Dernière modification le 09 décembre 2022 à 16:58.
Bon, en fait, pas besoin d'énumérer de façon aussi laborieuse bien sûr :
[^] # Re: En Python, modélisé
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 9. Évalué à 3.
Ce serait sans doute plus joli avec des coordonnées indexées (une liste de coordonnées en somme) plutôt que nommées.
Mais ce n'est de toute façon pas très compréhensible, de cette façon-là.
# En Python, modélisé
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 9. Évalué à 4.
J'aurais bien aimé éviter d'énumérer tous les cas de mouvement de suivi, mais je n'ai rien trouvé d'astucieux pour éviter cela.
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…
[^] # Re: python procédural, moche mais efficace
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 8. Évalué à 4.
Une petite optimisation pour la première partie : si on arrive à une hauteur de 9, pas la peine de regarder plus loin, aucun arbre ne sera plus haut que ça.
Mais bon, la seconde partie est bien plus coûteuse en temps de toute façon.
# Procrastination
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 8. Évalué à 3.
Alors qu'on a enfin quitté le camp pour aller chercher des caramboles, je ne peux m'empêcher que ça procrastine encore :
– Voilà, le verger c'est par là…
– Oh, regardez, la forêt que nous avons planté il y a quelques années, on pourrait y construire une cabane !
– Oui, super, ça nous changera les idées. Lutin drone-opérateur, tu nous cartographie ça ?
– Patron, venez nous donner un coup de main pour calculer le meilleur emplacement pour notre cabane au lieu d'essayer de régler votre communicateur. On vous l'a déjà dit, il est défectueux, et vous aurez tout le temps pour le réparer plus tard. On a plus important à faire là !
– Et les fruits pour les rennes alors ?
– Les quoi ? Ah, ça… On n'y est pas encore, soyez patient. Vous êtes pressé, vous avez un rendez-vous qui approche ou quoi ?
# Python avec Numpy
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 8. Évalué à 4.
Bon, j'ai sorti Numpy du coup. C'est modélisé, et assez long en fait.
[^] # Re: HS
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Mutuelle et mot de passe. Évalué à 3.
En fait, en matière d'assurance, et d'assurance de quoi que ce soit en fait, je pense qu'il serait possible d'autoriser la modulation de cotisation en fonction de n'importe quoi qui relève du choix de l'assuré, à condition que le traitement des informations correspondantes soit légal évidemment. L'âge et l'état de santé par exemple, ne relèvent pas du tout du choix.
Mais le tabagisme, le nombre d'infractions routières ou encore le nombre de soirées passées au cinéma chaque mois, relèvent du choix. Le dernier exemple n'a rien de pertinent, mais inutile d'interdire la modulation d'un tarif en fonction de cela : lorsque ce n'est pas pertinent, c'est inintéressant à appliquer, parce que cela ne correspond pas au risque assuré, que ça attirera juste une clientèle spécifique et que la remise correspondante s'avérera coûteuse pour l'assureur.
[^] # Re: HS
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Mutuelle et mot de passe. Évalué à 4.
Il y a plusieurs choses là-dedans. Les taxes ont deux rôles :
Ça n'a rien de subjectif, ça a été étudié, et surprise, le vélotaf est dangereux, mais ne pas en faire l'est encore plus. Les assureurs sont d'accord, ce qui est l'essentiel, dans cette discussion.
https://www.matmut.fr/assurance/nvei/conseils/velo-travail-bonnes-raisons
https://www.ors-idf.org/nos-travaux/publications/les-benefices-et-les-risques-de-la-pratique-du-velo/
Non, pas du tout, c'est une question de justice. C'est comme les assurances emprunteur par exemple : non fumeur, ça coûte moins cher que fumeur, c'est juste normal. Et ça ne pénalise que ceux qui le veulent bien.
Pas forcément moduler ainsi les cotisations, simplement permettre de le faire. Pour la vaccination, c'est pertinent aussi en effet. Beaucoup plus pertinent qu'une obligation plus ou moins forte en fait, puisqu'il s'agit de répercuter directement le coût statistique d'un choix personnel sur le budget de celui qui le fait. Pour responsabiliser les gens, on ne peut pas faire mieux je pense. Tant qu'il s'agit simplement de critères qui relèvent du choix des gens, aucun problème.
# Procrastination
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 7. Évalué à 4.
On dirait que le Père Noël, ou les lutins, ou les deux, ne sont pas si motivés que ça pour aller effectivement courir la jungle pour récolter des caramboles. Ça traîne à faire des inventaires, à monter le camp, à nettoyer le camp, à décharger le bateau, à réorganiser le matériel déchargé, à bidouiller des communicateurs, à mettre à jour ces communicateurs…
Ça fait six jours qu'on a débarqué, et n'a pas encore bougé du camp ! Vivement que les lutins nous fournissent une carte pour aller quelque part.
[^] # Re: C'est parti !
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Calendrier de l'Avent du code. Évalué à 4.
Sujets plus simple, je suis d'accord… pour le moment. Ça pourrait se corser d'un coup !
[^] # Re: Vivement , le 1
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Calendrier de l'Avent du code. Évalué à 6.
Pareil pour moi, surtout que j'aime faire du beau code, et que ça ne va pas bien avec l'idée de faire la course.
Mais pas d'inquiétude, on devrait finir par avoir des problèmes qu'on sera déjà content de parvenir à résoudre tout court, au bout d'un moment. :-)
[^] # Re: un bout de AWK
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 7. Évalué à 3. Dernière modification le 07 décembre 2022 à 15:19.
C'est idiot, on est d'accord. Mais ce n'est pas un parcours en profondeur d'abord.
[^] # Re: En Python bref
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 2. Évalué à 3. Dernière modification le 07 décembre 2022 à 14:52.
Waouh. C'est pour le moins original ça.
Si je comprends bien, ça fait de
~
une opération pour récupérer la valeur normalisée. Bien joué le(valeur % 3) or 3
, c'est bien plus lisible que(valeur - 1) % 3 + 1
.La valeur qui me vainc et la valeur que je vaincs, si je ne m'abuse.
Je suis plus inférieur à un autre si la valeur qui me vainc est la même que la valeur normalisée de l'autre. Et mutatis mutandis pour la supériorité. Tu aurais pu utiliser functool.total_ordering().
Ensuite, le reste est assez simple à comprendre, une fois ces bases posées. La réutilisation des opérateurs est… intéressante. Je ne peux pas dire que je suis fan, c'est un peu bizarre à lire quand même.
Tiens, j'ignorais la possibilité d'instancier un dictionnaire avec des mots-clefs. C'est amusant, ça aussi.
[^] # Re: Mutuelle
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Mutuelle et mot de passe. Évalué à 1.
Je suis tout aussi critique que toi sur le fait de ne pas avoir le choix. Je rêve d'avoir le choix entre la CPAM et d'autres assureurs. Et je ne vois pas le problème que ça poserait, du moment que la couverture est règlementée (obligation de couvrir au moins ceci et cela à tel taux ou plafond de remboursement), ainsi et que l'éligibilité et la tarification différenciée : concrètement, interdiction de refuser les vieux et les cancéreux et de leur faire payer plus cher parce que ce n'est pas un choix, mais permission de faire payer plus cher les fumeurs, et moins cher les gens qui font trois heures d'exercice par semaine, vélotaf inclus.
[^] # Re: En Python
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 7. Évalué à 3.
Pas en ReiserFS, le système de fichier qui tue le gaspillage d'espace de stockage.
[^] # Re: En Python
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 7. Évalué à 5.
Je profite en fait de l'AoC pour découvrir les fonctionnalités de typage de Python. Une fois passé l'apprentissage, qui n'est vraiment pas horrible, ça ne fait pas perdre du temps, au contraire, ça permet de détecter certaines erreurs de façon bien plus rapide et de mieux identifier d'où elles viennent.
[^] # Re: un bout de AWK
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Avent du Code, jour 7. Évalué à 3.
Bien joué, je n'avais pas remarqué cela. Ceci dit, je n'aime pas trop me baser sur des suppositions qui ne sont absolument pas garanties par l'énoncé.