Yth a écrit 2671 commentaires

J'aime bien, c'est assez propre et concis !

Je suis sur quelque chose de nettement moins abstrait, mais l'exercice du jour est assez simple je trouve.

import sys
def read_element(winning, numbers):
  winning = set(int(x) for x in winning.strip().split(" ") if x)
  numbers = set(int(x) for x in numbers.strip().split(" ") if x)
  return winning, numbers

def input():
  for line in sys.stdin:
    game, elements = line.strip().split(':')
    game = int(game.split(" ")[-1].strip())
    winning, numbers = read_element(*elements.strip().split("|"))
    i = numbers.intersection(winning)
    num = len(i)
    score = 2**(num - 1) if i else 0
    yield game, num, score

datas = [x for x in input()]
r = sum(s for *_, s in datas)
print(f"Score : {r}")

winnings = {card: 1 for card, *_ in datas}
for card, num, s in datas:
  wins = winnings[card]
  for i in range(card + 1, card + num + 1):
    winnings[i] += wins

print(f"Total cards: {sum(winnings.values())}")

Et le calcul est immédiat aussi.

• Yth.

Jour 2, c'est simple, on ne se fait pas déjà des noeuds dans le cerveau, c'est normal…

• Yth.

Alors avec plus d'abstraction, j'ai ça :

from dataclasses import dataclass
@dataclass(frozen=True)
class Bag():
  red: int = 0
  green: int = 0
  blue: int = 0
  def __le__(self, other):
    if self.red > other.red or self.green > other.green or self.blue > other.blue:
      return False
    return True
  def __add__(self, other):
    return Bag(
      red=max(self.red, other.red),
      green=max(self.green, other.green),
      blue=max(self.blue, other.blue),
    )
  @property
  def power(self):
    return self.red * self.green * self.blue

Une classe pour représenter un sac, avec des cubes rouges, verts et bleus dedans. La dataclass c'est bien pratique, ça s'initialise automatiquement avec les paramètres fournis aux noms des variables, ou alors aux valeurs par défaut.
Par exemple Bag() c'est 0 de chaque, Bag(red=12, green=5), ça fait ce qui est écrit en laissant blue à 0.
Il est frozen ce qui signifie qu'on ne peut pas le modifier, donc les opérations retournent une nouvelle instance de Bag, c'est utile en optimisation parce que ça va plus vite. Ici c'est sans importance.

On définit trois opérations dessus : __le__ permet de comparer bag1 <= bag2, c'est True ssi tous les éléments de bag1 sont inférieurs ou égaux à ceux de bag2.
__add__ c'est un peu un hack, et ça retourne un Bag avec le maximum pour chaque valeur dans les deux Bag additionnés, ça permet d'utiliser la fonction sum() pour calculer un maximum, parce que la fonction max() fait des comparaisons, et retourne le Bag en entrée le plus grand, ce qui n'a rien à voir avec ce dont on a besoin.
Et finalement power est un attribut qui sert au calcul du score du second exercice.

Avec cette classe on va analyser les données, en exploitant les passages d'arguments python par dictionnaire, et les valeurs par défaut de Bag, c'est pas trop abscons à lire, si on n'est pas débutant en Python (et qu'on aime les struct-comprehension) :

def input():
  for line in sys.stdin:
    game, cubes = line.strip().split(':')
    yield int(game.split(" ")[1]), sum(
      (
        Bag(**{
          color: int(nb)
          for cubes in bag.strip().split(",")
          for nb, color in [cubes.strip().split(" ")]
        })
        for bag in cubes.split(";")
      ), Bag(),
    )

En réalité on n'a jamais besoin des divers sacs possible, la seule chose qui nous intéresse c'est le maximum pour chaque valeur rouge, vert et bleu, d'où le sum(), et une fois cette optimisation faite, on réalise qu'on s'est furieusement compliqué la vie et qu'au final on avait juste besoin, depuis le tout début de l'exercice, de trouver ce maximum, et de ne s'intéresser qu'à lui.

Les exercices ensuite sont triviaux, surtout le second, il n'y a vraiment plus rien à faire :

datas = [x for x in input()]
constraint = Bag(red=12, green=13, blue=14)
r = sum(
  game
  for game, biggestbag in datas
  if biggestbag <= constraint
)
print(f"Possible games : {r}")

power = sum(
  biggestbag.power
  for game, biggestbag in datas
)
print(f"Sum of Power of games : {power}")

• Yth, qui vient de faire brûler un CPU sur l'exercice 5, parce que parfois c'est plus « rapide » de laisser turbiner que de trouver un meilleur algorithme, mais on en parle jour 5…

Le weekend, j'ai moins de cerveau, moins de temps, et je n'ai pas encore trop cherché les bonnes optimisations, mais je devrais commencer, pour reprendre les bonnes habitudes.
Et me remettre en tête les structures de données moins utilisées, et pourtant tellement utiles.

J'aurais aussi pu faire une classe cubes avec trois éléments red, green et blue, qui permet des comparaisons immédiates avec <, >, des min, max, sum, multiplications, etc.

Après les opérations deviennent très simples. Je vais peut-être poster ça demain :)

• Yth.

Faut dire, j'ai pu m'y mettre vers 23h30 hier soir…
Et ma bêtise a été de transformer "927*741" en 927741 au lieu de 927 et 741 séparés.

Déjà, la somme totale de tous les nombre du jeu se calcule ainsi :

s = ".".join(x.strip() for x in sys.stdin)
for i in set(x for x in s if x not in "0123456789"):
    s = s.replace(i, " ")
all_numbers = sum(int(i) for i in s.split(" ") if i) # =598313

Ce calcul fait à l'avance m'aurait permis de voir que 9691964 comme résultat, c'était ouvertement faux…

Bref, j'ai commencé à chercher certaines optimisations, en utilisant des comparaisons de set() en python, qui sont plutôt efficaces. Et j'aurais probablement dû utiliser des frozenset, car c'est plus rapide, quand on n'a pas besoin de les modifier.
Il reste aussi des optimisations faisables, mais la taille des données ne les justifient pas encore.

Zéro structures de données, un traitement très linéaire, ça reste simple, on ne fait pas encore de réelles abstractions.

import sys
directions = ((-1, -1), (-1, 0), (-1, 1), (0, -1), (0, 0), (0, 1), (1, -1), (1, 0), (1, 1))

def envelope(positions):
  return set(
    tuple(sum(x) for x in zip(a, p))
    for p in positions
    for a in directions
  )

numbers = list()
symbols = set()
gears = set()
nl = 0
for line in sys.stdin:
  number = []
  positions = set()
  nc = 0
  for c in line.strip():
    if c in "0123456789":
      number.append(c)
      positions.add((nl, nc))
    else:
      if c != ".":
        print(f"Symbol {c} at {nl}, {nc}")
        symbols.add((nl, nc))
      if c == "*":
        gears.add((nl, nc))
      if number:
        numbers.append((int("".join(number)), envelope(positions)))
        number = []
        positions = set()
    nc += 1
  if number:
    numbers.append((int("".join(number)), envelope(positions)))
    number = []
    positions = set()
  nl += 1

numbers est la liste des nombres et de leur « enveloppe » c'est à dire des coordonnées de toutes les cases composant ce nombre et adjacentes à lui.
C'est un set() de doublets.
symbols contient la liste des coordonnées (doublets) de tous les symboles du plan.
gears contient la liste des coordonnées des symboles * uniquement, et ne servira que pour la seconde partie.

Je trouve le code un poil moche, et un meilleur travail sur les entrées, et les conditions boucles, pourrait alléger, mais il faut absolument ne pas se planter dans les cas limites : un nombre en fin de ligne, deux nombres séparés par un symbole (celui-là m'a mis dedans), etc.
Être carré, clairs, précis, sinon c'est l'écran bleu… Euh, enfin, la mauvaise réponse quoi…

La résolution des problèmes est assez simple après ça.
Problème n°1 :

result = list()
nope = 0
for number, pos in numbers:
  if symbols.intersection(pos):
    result.append(number)
  else:
    nope += number
print(result)
print(f"Sum of Numbers : {sum(result)} ({nope})")

nope me sert à la validation, vu que j'ai la somme de tous ems chiffres qui vaut 598313, je dois avoir result + nope = 598313, et j'aurais pu aussi juste calculer nope et obtenir mon résultat comme ça, par soustraction.
Ça pourra servir comme façon de faire plus tard, je me rappelle d'un exercice avec du sable qui s'écoule, qui peut se résoudre très facilement en regardant uniquement là où il ne s'écoule pas et en faisant une soustraction…

Et le second challenge :

gear_value = 0
for gear in gears:
  parts = [
    number
    for number, pos in numbers
    if gear in pos
  ]
  if len(parts) == 2:
    gear_value += parts[0] * parts[1]

print(f"Sum of NumbersGear Value : {gear_value})")

Rien à recalculer, on va analyser dans l'autre sens : pour chaque « gear » on regarde dans combien de « number » il se trouve, si c'est 2, bingo, on l'ajoute.
C'est tout.

• Yth.

Ce coup-ci, avec une analyse des données, placées dans les bonnes structures, la seconde partie de l'exercice va se faire immédiatement après la première.

Ici on a encore un truc assez simple, et on va faire un dictionnaire avec en clé le numéro de la partie et en valeur une liste de triplets (rouge, vert, bleu), avec des zéros là où on n'a pas d'infos en entrée.
-> Normaliser les entrées, avoir une structure assez facile à analyser ensuite.

import sys
from functools import reduce
colors = {"red": 0, "green": 1, "blue": 2}

def read_cubes(cubeset):
    r = [0, 0, 0]
    for cubes in cubeset.strip().split(","):
        nb, color = cubes.strip().split(" ")
        r[colors[color]] = int(nb)
    return r


def input():
    for line in sys.stdin:
        game, cubes = line.strip().split(':')
        game = int(game.split(" ")[1])
        cubes = [read_cubes(cubeset) for cubeset in cubes.split(";")]
        yield game, cubes

datas = [x for x in input()]

Déjà, j'abuse des yields et des générateurs, c'est pas encore utile, mais ça va venir.

Pour la partie 1 on va avoir une fonction de validation, et après on fait une somme :

def test_elements(elements, constraint):
    for el in elements:
        for i in range(3):
            if el[i] > constraint[i]:
                return False
    return True

constraint = [12, 13, 14]
r = sum(
    game
    for game, elements in datas
    if test_elements(elements, constraint)
)
print(f"Possible games : {r}")

Et là, pour la seconde partie on n'a même plus besoin de fonction de validation, le calcul est immédiat, même si le code est moche. Y'aurait moyen avec des structures de données de numpy de se passer de certaines méthodes peu explicites avec directement des comparaisons de vecteurs, ou un produit vectoriel. Bah, pas encore, on reste en python chocolat, poire… Vanille !

power = sum(
    reduce(lambda x, y: x * y, [max(i) for i in zip(*elements)])
    for game, elements in datas
)
print(f"Sum of Power of games : {power}")

Le reduce sert à multiplier entre eux tous les éléments de la liste, et le zip va transformer une liste de triplets (r, v, b) en triplet de listes ([r, r, r…], [v, v, v…], [b, b, b…]).

Jusqu'ici, ya pas grand chose à déclarer, on manipule des données, on n'a même pas vraiment besoin de trop se compliquer à trouver les bonnes structures de données.

• Yth.

Le premier exercice est trivial :

import sys
print(sum(
    int(f"{digit[0]}{digit[-1]}")
    for line in sys.stdin
    for digit in [[x for x in line if x in "0123456789"]]
    if digit
)

On fait python3 01.py < 01.input ou 01.demo pour les données de test, et hop, résultat en une commande.

Le second exercice sans optimisation consiste à rechercher les chiffres et les chiffres écrits, ajouter ça dans une liste, et faire pareil :

import sys
text = ["zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine"]
def analyze(line):
    def _iter():
        for n in range(len(line)):
            if line[n] in "0123456789":
                yield line[n]
                continue
            for t in text:
                if line[n:].startswith(t):
                    yield str(text.index(t))
                    continue
    return _iter()

print(sum(
    int(f"{digit[0]}{digit[-1]}")
    for line in sys.stdin
    for digit in [list(analyze(line))]
    if digit
)

La fonction analyze prend une ligne, la parcours charactère par charactère, et regarde si c'est un chiffre, ou l'écriture d'un chiffre, et envoie dans l'itérateur.
Zéro intelligence, zéro optimisation, zéro plantage.
Bientôt on pourra plus faire comme ça !
Mais bon, jour 1, on se dérouille les neurones, on reprend le pli des traitements de flux, on essaie déjà de mettre des itérateurs plutôt que de tout traiter en mémoire, juste pour reprendre les futurs bonnes habitudes…

• Yth.

Poste ton code ?

• Y.

C'était dans Programmation.Autre, j'ai pas trop le temps ce week-end, mais si quelqu'un veut démarrer.

• Yth.

A priori oui, on peut.

• Yth.

Je m'inscris complètement en faux par rapport à l'infox comme quoi Macron serait centriste.

• Yth.

L'histoire, la géographie, les maths, la physique, la chimie, la biologie, etc.
Tout ça non plus n'est pas « normé ».

Par contre, comme pour la langue française, il y a un programme, assez précis, des manuels qui explicitent ce programme et sont validés par le ministère, et les élèves sont évalués sur ce programme.

Il n'est nulle part question de droit, et aucune loi n'impose que la note d'une dictée soit faite sur une base équitable, normée ou quoi que ce soit.

• Yth.

Un parent ?

• Yth :)

Je suis assez perturbé, toujours, par l'académie française.
Défendre la langue oui, mais essayer de la normer, ou plutôt de normer ses évolutions, ben nettement moins.

Défendre des constructions et des orthographes qui portent du sens et évitent des confusions, c'est important.
Quand les gens confondent à l'écrit « serez » et « saurez », ça m'affole un poil.
Mais lire « T ou 2m1? » me dérange beaucoup moins.

Moi aussi j'essaie d'avoir une bonne orthographe et une bonne grammaire, de manière générale une bonne maîtrise de la langue, parce que je considère que connaître le cadre, forcément un peu rigide, est la première étape pour le transcender, et apporter du sens par les transgressions qu'on y apporte.
Sous forme de néologismes, barbarismes, jeux de mots, fautes assumées, etc., si on connaît la « bonne façon » d'écrire, le fait d'écrire mal exprès fait aussi passer des messages.

Et évidemment, ce que j'accepte chez moi, je l'accepte chez les autres.

Alors oui, je tique quand je voit écrit ça, et je pourrais même faire la remarque dans certains cas. Mais les évolutions et les nouveautés, j'adore, c'est ce qu'il y a de plus excitant dans la langue, jouer avec, la faire vivre :)

• Yth, j'ai un défaut contre les anglicismes aussi, je cherche toujours le bon mot français à la place, et je trouve qu'en général on y gagne.

Chais pas trop, en France, sur l'intégralité de la 5è république, on a eu 70% de présidences de droite (45 ans) et 30% de présidences de gauche (19 ans).

Vers où cet échiquier politique penchait-il donc par le passé ?

En tout cas, il y a eu des écologistes aux présidentielles depuis 1974, soit plus des trois quarts de l'existence de la Vè, mais l'échiquier n'a jamais penché de ce côté là.

• Yth.

Aussi, nous sommes 4 à avoir eu 50 étoiles, et 4 de plus à en avoir eu plus de 40.
Sachant que la fin est relativement fastidieuse, avec des algos qui peuvent prendre du temps, et donc un débuggage allongé d'autant, jusqu'à la veille de Noël où on peut avoir franchement autre chose à faire : ne pas chercher à finir est entièrement compréhensible.
Quand ça cesse d'être fun, ça cesse d'être fun.

Mais vivement dans quelques jours quand ça commencera à devenir fun, et qu'il faudra avoir de vraies idées d'algorithmie pour affronter les épreuves :)

Bon courage à toutes celles et tout ceux qui vont participer !

• Yth.

Je remet ça cette année :)

Premier conseil pour ceux qui s'y mettent : testez vos programme avec les données de démo avant d'envoyer un résultat.

Les cas particuliers ne sont pas décrits dans les énoncés, mais sont souvent présents dans les données de test.

Par exemple, premier jour de 2023, second challenge ligne 2 : "eightwothree".
L'approche « facile » consiste à faire des remplacement de chaînes : "one" par "1", "two" par "2", etc.
Si on fait ça sans réfléchir et dans l'ordre, notre chaîne devient alors : "eigh23", et on a comme valeur 23.
Mais on devrait remplacer le début de la chaîne, "eight" par 8, et obtenir 83 comme résultat.

Une simple validation avec les données de test montre qu'on s'est planté…
Si ça sent le vécu, c'est parce que ça sent le vécu.

Second conseil, en Python, mais surtout utile à partir de la moitié en général : utilisez PyPy quand les algos commencent à boucler à mort et traiter des millions de cas, ça peut aller de 20 à 50 fois plus vite, sans rien changer au code.
Et abusez des générateurs, pour éviter les explosions de mémoire.

• Yth.

Ton commentaire avait l'air tellement intéressant !
Mais je me suis arrêté à chaosphere.

Dommage…

• Yth.

Mon prompt est assez basique, il fait : user@machine:dir$

Mais le nom d'utilisateur est en rouge quand c'est root et en vert sinon.
Et le nom de la machine est d'une couleur différente selon la machine.
Et le répertoire est toujours complet, je déteste les répertoires réduits, juste le dernier chemin, ou des pointillés.
Parfois c'est moche et ça fait un prompt de 12 kilomètres.
Parfois.

Et ben ça me fait gagner un temps fou de juste voir le rouge, là, à l'endroit où j'écris ma commande, mais sans être trop intrusif non plus. D'avoir toujours conscience de si l'utilisateur du shell à l'écran peut faire des conneries ou pas.
C'est aussi utile pour se dépatouiller des SSH, le nom de la machine n'est pas toujours évident sans avoir besoin d'être lu, alors qu'une couleur différente, ça va sauter aux yeux qu'on est en SSH sur une autre machine.
En fait t'as besoin de deux couleurs : une pour la machine locale, une pour les machines accessibles uniquement à distance, après je lis le nom de la machine pour bien vérifier où je suis.
Et s'il n'y a aucune couleur, je sais que je suis sur une autre machine, que je ne gère pas, et donc que j'y suis pour une raison précise, et ça saute encore plus aux yeux !

Bah voilà, ça va pas très loin, c'est de la conf statique (la couleur est paramétrée dans le .bashrc), et pif je gagne du temps, et je perds des chances de faire des boulettes.
Pour un effort somme toute assez minimal de paramétrage.

C'est bon, j'ai relevé ton défi, j'ai gagné quoi ?

• Yth.

Et donc la façon naturelle de régler les choses c'est de laisser l'environnement se dégrader jusqu'à perte brutale de la population humaine, sans obligatoirement une extinction.

On est sur la bonne voie :)

• Yth.

Alors contrairement à ce que cette phrase laisse entendre, un cancer ce n'est pas une croissance dérégulée, mais une absence de décroissance.

En fait nos cellules ont déjà un rythme de reproduction effréné, mais elles sont recyclées à peu près au même rythme.
Dans un cancer il y a défaut de recyclage, les cellules restent, la tumeur grossit, mais pas plus vite que la croissance classique des cellules.

De fait j'ai un peu de mal à faire une analogie avec notre société… Je suppose qu'on a en effet un grave déficit de recyclage, et qu'on aurait bien besoin de ne pas simplement jeter, mais de reconstruire.

C'est le principe de l'économie circulaire : tu produits de la valeur en fabricant un bidule.
Puis tu le récupère et en extrait la matière utile, produisant à nouveau de la valeur.
Cette matière utile sert à reconstruire un autre bidule, en créant donc de la valeur.
On arrive à une création de valeur à chaque étape, sans extraction de matière première après le lancement du cycle.
Toute la subtilité est dans l'énergie employée à chaque étape. Et la quantité de pertes aussi.

• Yth.

La France : 2% des émissions pour 0,8% de la population.
Et ce très mauvais résultat est atteint avec une électricité presque entièrement décarbonée (j'ai pas dis non-polluante).

Ça fout un peu la honte cet argument de dernier de la classe…

• Yth.

Est-ce que tu dis « D point bidule » à l'oral ?
Non, tu dis Docteur bidule.
C'est pas oralisable, c'est un défaut de cette façon de faire.
Ça ne la rend pas du tout inadaptée pour la plaque en bas de l'immeuble.
Et en plus c'est assez aisé à dérouler : ça remplace un mot unique, donc ça se ré-oralise facilement, ce qui n'est pas le cas de la notation avec le point médian.

Voilà, je pointe un défaut, qui freine son adoption, parce que l'objectif ici c'est d'inclure plus de gens dans les discours, à la fois à l'oral et à l'écrit.
On a une solution qui passe mal de l'un à l'autre.

Jamais je n'ai dis qu'il fallait la jeter, j'ai simplement pointé un défaut.

C'est possible de discuter des qualités et défauts d'un truc quelconque sans que le fait de pointer un défaut ne fasse de nous un fanatique anti-truc-quelconque ?
Je sais que la mode est est au tout noir/tout blanc, si t'es pas avec moi t'es contre moi, blabla, mais je dois être un vieux con, parce que c'est pas ma façon de faire, merci.

• Yth.

donc on invisibilise les non-binaires \o/

Oui.
Ils le sont parce que le français n'a que deux genres, il est binaire de ce côté là.
On s'intéresse aux femmes aussi parce qu'elles représentent la moitié de la population, et souffrent de manière générale de cette invisibilisation.
Les non-binaires n'en souffrent probablement pas de la même manière, et il s'agit d'autres discriminations, nettement moins liées à l'usage de la langue, et probablement souvent plus violentes.
Je n'ai aucune idée quant-à savoir si la langue leur cause du tort, il est probable qu'une partie du tort causé - une partie seulement - puisse être levé avec ce qu'on pourrait appeler « la fin de la discrimination des femmes par le langage ».

pour moi le genre n'a strictement aucune importance sur le métier.

Ton message est intéressant, et je m'y retrouve aussi, à titre personnel j'ai toujours conscience de la possibilité qu'il y ait des hommes et des femmes, et des non-binaires, dans chaque corps de métier, et j'ai en pratique assez peu de biais de ce côté là.
Ça vient de ma propre éducation, et de mon intérêt pour la question.

Malheureusement, j'ai aussi conscience de ne pas représenter la majorité des gens, je représente environ 0,0000015+-10^-6 % de la population française.
C'est suffisamment peu pour ne pas être généralisable…

• Yth.

Ce n'est pas ségrégationniste.
Le masculin et le féminin sont une base de notre langue, à tel point que les noms communs ont un genre, et que ce genre n'a aucune valeur sémantique, et qu'on s'en fout globalement pas mal, mais tous les noms communs ont un genre (les exceptions non-binaires confirmeront la règle, selon l'adage en vigueur).

Si pour les personnes réelles, pour qui le genre a une valeur réelle, on n'utilise que le masculin, alors on invisibilise le féminin.
C'est prouvé neurologiquement hein, c'est pas juste une phrase en l'air.
Mettre le féminin en avant quand c'est pertinent (ergo quand il s'agit d'une femme, ou d'un groupe majoritairement ou entièrement féminin), ça permet de montrer que la vie n'est pas masculine.
Même si « tout le monde sait bien que les femmes existent », ça a des effets neurologiques réels.

Là on a deux solutions : éliminer le genre quand ce n'est pas nécessaire - oui, au final on s'en fout pas mal que la présidente du syndic soit une femme, c'est la fonction qui compte - ou le montrer tout le temps.
Pour éliminer le genre il n'y a grosso-modo que l'écriture épicène, des mots ou des tournures de phrases réellement neutres, et sans préjugés : « les personnes omettant de tirer la chasse après la chiasse sont priées de changer d'habitude ».
Mais cette écriture ne peut pas toujours s'appliquer, pas facilement, pas toujours sans lourdeur, ou pas toujours de façon non artificielle. C'est un très bon outil, il est pratique, mais tous les problèmes rencontrés ne sont pas les clous de ce marteau-ci.

Pour le montrer tout le temps, et bien on indique qu'il s'agit d'une conductrice, d'une autrice, d'une ministre, ou bien des travailleurs et des travailleuses, ce qui peut se faire à l'écrit en utilisant le point médian, mais pas à l'oral.
Cette façon de faire à l'intérêt de montrer qu'il y a des femmes aussi à ces fonctions, et quand on entendra aussi aisément parler d'écrivaine que d'écrivain, et que personne ne se posera plus la question de dire ou non écrivain pour une femme, alors on aura acquis qu'il est naturel pour les femmes aussi d'écrire et être publié.
Là on pourra se poser la question de la pertinence de savoir où se situe le centre de gravité de la personne en question.

Mais je pense que ce jour là, on n'en aura rien à faire, on verra aussi aisément les noms masculins que féminins, et ça nous choquera aussi peu que de savoir qu'une voiture est un mot féminin, alors qu'un autobus est masculin.

• Yth.