Instructions
Si tu veux construire quelque chose avec un Raspberry Pi, tu utiliseras probablement des résistances.
Pour cet exercice, tu dois connaître deux choses à leur sujet :
- Chaque résistance possède une valeur de résistance.
- Les résistances sont minuscules, à tel point que si on imprimait la valeur de résistance dessus, il serait difficile de la lire.
Pour contourner ce problème, les fabricants impriment sur les résistances des bandes colorées qui indiquent leur valeur de résistance.
Chaque bande a une position et une valeur numérique.
Les 2 premières bandes d'une résistance suivent un schéma d'encodage simple : chaque couleur correspond à un seul nombre.
Par exemple, si on imprimait une bande brown (valeur 1) suivie d'une bande green (valeur 5), cela donnerait le nombre 15.
Dans cet exercice, tu vas créer un programme bien utile pour ne plus avoir à mémoriser les valeurs des bandes.
Le programme prendra des noms de couleurs en entrée et renverra un nombre à deux chiffres, même si l'entrée contient plus de deux couleurs !
Les couleurs des bandes sont encodées comme suit :
- black : 0
- brown : 1
- red : 2
- orange : 3
- yellow : 4
- green : 5
- blue : 6
- violet : 7
- grey : 8
- white : 9
D'après l'exemple ci-dessus :
brown-green doit renvoyer 15, et
brown-green-violet doit aussi renvoyer 15, en ignorant la troisième couleur.
Définis la syntaxe
Cet exercice est conçu comme la suite de Resistor Color, sur laquelle il s'appuie.
Tu peux faire les exercices d'entraînement dans n'importe quel ordre, mais on t'encourage à suivre celui qui est suggéré.
Dans cet exercice, les couleurs disposent déjà d'une syntaxe prédéfinie à l'aide du préfixe c*, par exemple c*black.
Tu dois ensuite définir une syntaxe qui associe une séquence de couleurs à un nombre, conformément aux instructions.
Les couleurs sont placées entre *[[ et ]] et séparées par , , par exemple *[[c*black, c*yellow, c*violet]].
Cette tâche te demandera probablement d'utiliser soit des notations, soit des macros.
Tu peux jeter un œil à une référence.
Comme la nouvelle syntaxe est développée au moment de la compilation, aucun test ne se compilerait tant que toute la syntaxe requise n'est pas définie.
Pour cette raison, au lieu de s'appuyer sur des tests d'exécution classiques, on utilise #guard_msgs.
Cette commande compare une docstring donnée avec le message généré par une autre commande, ici #eval, et signale une erreur s'ils sont différents.
Tu peux considérer l'absence d'erreur comme un test réussi.
Si tu travailles en local ou dans le bac à sable en ligne de Lean, tu obtiendras un retour immédiat sur toute erreur signalée par #guard_msgs, via Lean InfoView.
L'exécuteur de tests en ligne ne prend pas encore en charge l'import de toute la bibliothèque de méta-programmation Lean.
Tu es libre d'utiliser toutes les fonctionnalités disponibles par défaut dans Lean, y compris celles de l'espace de noms Lean, mais si tu ajoutes import Lean ou que tu importes des modules précis de l'espace de noms Lean, ta soumission échouera au moment de l'envoyer à Exercism.
Sache que l'import de la bibliothèque Lean n'est pas nécessaire pour résoudre cet exercice.
