Bien sur que c'est pratique, c'est pour cela qu'on l'utilise couremment ;)
Par contre, je continue à penser que ça n'a rien à voir avec un système d'unités physique qui doit gérer des quantités, et tes exemples sont facilement exprimables autrement :
implémente moi un programme qui lance cette touche tout les 2 mois
mets moi un rappel de cet événement dans 5 mois
Pour ces deux là, il s'agit d'une gestion de calendier et d'évenements associes, il n'y a pas d'arithmétique physique associé, par exemple, tu ne vas pas diviser des kilogrammes à ces dates d'évenements.
entraîne ce réseau neuronal pendant 1 mois complet
celui là, c'est un besoin mal exprimé, dans ce cas, l'utilisateur a voulu donner une durée.
Donc c'est à la partie UI (Interface Utilisateur, qui porte bien son nom au final) de faire l'interface entre l'utilisateur, et le code métier sous-jacent, par exemple en définissant une durée standard pour un mois, ou en demandant à l'utilisateur de préciser, ou avec une heuristique de résolution plus complexe.
Mais ça n'a toujours rien à voir avec un système d'unité dans un langage je pense.
L'idée c'est de fournir un framework cohérent pour exprimer précisément cette notion imprécise. Sujet drôlement complexe.
Je ne dis pas que le problème n'est pas intéressant en soi, juste que j'ai l'impression que tu essayes de le résoudre au mauvais endroit.
Si tu poses les bases d'un définition d'unités et de quantités associés avec l'arithmétique correspondante dans ton langage préféré, gérer les notions floues et ambigües du langage courant devrait se faire à un autre niveau.
[^] # Re: Le mois physique
Posté par moi1392 . En réponse au journal [Letlang] Faire la différence entre un nombre et une quantité. Évalué à 5.
Bien sur que c'est pratique, c'est pour cela qu'on l'utilise couremment ;)
Par contre, je continue à penser que ça n'a rien à voir avec un système d'unités physique qui doit gérer des quantités, et tes exemples sont facilement exprimables autrement :
Pour ces deux là, il s'agit d'une gestion de calendier et d'évenements associes, il n'y a pas d'arithmétique physique associé, par exemple, tu ne vas pas diviser des kilogrammes à ces dates d'évenements.
celui là, c'est un besoin mal exprimé, dans ce cas, l'utilisateur a voulu donner une durée.
Donc c'est à la partie UI (Interface Utilisateur, qui porte bien son nom au final) de faire l'interface entre l'utilisateur, et le code métier sous-jacent, par exemple en définissant une durée standard pour un mois, ou en demandant à l'utilisateur de préciser, ou avec une heuristique de résolution plus complexe.
Mais ça n'a toujours rien à voir avec un système d'unité dans un langage je pense.
Je ne dis pas que le problème n'est pas intéressant en soi, juste que j'ai l'impression que tu essayes de le résoudre au mauvais endroit.
Si tu poses les bases d'un définition d'unités et de quantités associés avec l'arithmétique correspondante dans ton langage préféré, gérer les notions floues et ambigües du langage courant devrait se faire à un autre niveau.