Discussion :

[ctxnop]

Oui, j'étais aussi de cette avis dans mes jeunes années.

Je pensais que la meilleure solution était la plus générale, la plus extensible, la plus réutilisable, la plus paramétrable, etc. Avec le temps, je me suis rendu compte que la meilleure solution était souvent la plus simple.

Moi je ne vois pas en quoi les deux sont incompatible.
Une solution générale est souvent plus simple in fine qu'une solution "simpliste" qui va t'emprisonner dans une cage de contraintes. Tant que tu restera dedans tout ira bien, mais si tu passes les doigts à travers les barreaux, ils vont rester coincés et ca te fera mal de les décoincer.

Et puis, encore une fois, la conception n'est pas l'implémentation. L'implémentation se doit de respecter le plus possible la conception, autant que les contraintes de la réalité le permettent. Je ne dis pas qu'il faut implémenter un truc capable de gérer effectivement une infinité de cases en implémentant tout un système pour contourner les limitations techniques. Je dis juste que conceptuellement, se limiter à la réalité connus n'est pas une solution à long terme.
Ce n'est pas parce que la conception autorise une infinité que l'implémentation ne va pas dire "ouais, mais en fait on va se limiter à 20, c'est mieux par rapport à mes contraintes".

Au final j'ai l'impression de dire sensiblement la même chose que pseudocode à ceci près que pour moi l'évocation de ces contraintes techniques n'a pas lieu d'être ici puisqu'on parle de conception. Tout ce que je dis c'est que donner des exemples d'implémentations techniques pour contredire une règle de conception n'a pas de sens. La conception n'est qu'une seule des phases du développement, elle n'a pas d'existence réelle et donc de contraintes réelles. Ces notions sont amenées par l'implémentation qui, elle, est réelle et pleine de contraintes.

D'ailleurs je n'ai même pas confirmé ou infirmé la règle (même si c'est plutôt évident que je suis assez d'accord avec). Tout ce que j'ai dit au final c'est que les exemples donnés pour dire "non je suis pas d'accord avec la règle" sont hors sujet puisqu'ils parlent d'implémentation.

[gorgonite]

Euh c'est moi ou inconnu veut aussi dire potentiellement infini ?

tu te trompes lourdement... et de beaucoup, et même après un passage à la limite.
si tu comprends pourquoi, tu sauras comment Cantor est devenu fou

[cs_ntd]

Bin c'est vrai qu'en pratique, il ne m'est jamais arrivé de mettre autre chose que :
0,1,*
en modélisant un truc...

Donc oui je suis plutôt d'accord avec la règle. Pour moi, "plusieurs" ce traduit automatiquement en "*".

En pratique, dans le code, je ne met que rarement de limitations de valeur. Et je ne prend jamais, dans un cahier des charges, un chiffre pour un chiffre. Quand on dit "Maximum 20 000€", dans ma tête ça se traduit par : "Dans l'exemple du cahier des charges, la variable 'montant' vaut 20 000€".

Et si vraiment le besoin se fait sentir, dans le codage, de mettre des bornes, ou de définir une égalité, l'homme à inventer le fichier de config .

Ou alors, je suis juste fainéant (quoi !? en plus il faut compter le nombre d'instances possibles !? ) et je préfère laisser ça pour plus tard à l'implémentation

[TNT89]

tu te trompes lourdement... et de beaucoup, et même après un passage à la limite.

Je ne vois pas du tout pourquoi il se trompe. Un algorithme conçu pour travailler sur un nombre infini de case peut n'en utiliser qu'une partie. Et c'est précisément ce point qui nous semble très intéressant du fait que nous puissions pas manipuler physiquement un ensemble/une collection infinie.

En effet, un algorithme est descriptible de façon mathématique sur des ensembles classiques, des groupes (plus ou moins complexes) infinis! Le fait que son implémentation réduit les supports de ceux-ci entrave-t-il vraiment la machine virtuelle conçue? Vous pouvez me dire oui, en me donnant des exemples d'algorithmes numériques dont la précision est limité par l'implémentation et la représentation machine des nombres, mais je vous objecterais que cela ne dépend que de la précision recherchée ("on ne peut pas calculer et stocker Pi exactement mais 10 de ses décimales peuvent nous suffire") et donc que certains supports finis seront suffisant pour l'application.

Enfin, la vraie question est : est-ce que c'est utile/nécessaire?

[ctxnop]

Oui, plutôt d'accord avec toi, cependant il y a bel et bien une différence entre infini et inconnu. Celle évoquée par pseudocode.

Gérer une quantité infinie signifie que tu prend en compte qu'il n'y a pas de fin. Tu ne peux donc pas référencer la fin d'une collection puisqu'elle est infinie.
Tu ne peux pas non plus la parcourir bêtement car il n'y a pas de fin à ce parcourt.

C'est donc tout de même assez différent d'une quantité finie mais non connue au moment de la conception, car même si elle n'est pas connue elle est comptable. Il y aura donc une fin référençable à ta collection, un milieu dans ta liste, etc...

Donc oui, faire un algo gérant une infinité permettra aussi de gérer un ensemble fini. Cependant il ne sera probablement pas modélisé de la même façon qu'un algo qui gère une quantité finie mais inconnue.

A mon avis il y a une différence de vocabulaire comme il y en as entre la physique et les mathématiques. L'infini n'existe qu'en mathématique pure. En conception on parle "d'infini" quand on quantifie par "*". Mais comme il a été dit un peu plus haut, le "*" signifie plutôt "plusieurs" et non pas infini.

[TNT89]

A mon avis il y a une différence de vocabulaire comme il y en as entre la physique et les mathématiques. L'infini n'existe qu'en mathématique pure.

Pour la forme : l'infini existe aussi en physique et est assez courant (optique / électromagnétique, calcul infinitésimal...).

Sinon, je pense que le problème se situe vraiment au niveau du vocabulaire : pour moi un algorithme n'a pas que la réalité conceptuelle pour lui : son implémentation n'est que sa restriction à .... Il est donc bel et bien conçu pour être utilisé à l'infini (ex : calcul de Pi faisable à l'infini mais nécessitant des ressources bien réelles!) mais pas forcément son implémentation de part les restrictions qui lui sont imposé...

[Joker-eph]

Sans couper les cheveux en quatre, on peut comprendre que le terme "infini" ici signifie "un nombre quelconque", il est bien entendu fini (cf problème de d'exprimer un algorithme qui parcours une liste jusqu'à sa fin...).

Pour en revenir au sujet, j'aime bien l'exemple de _skip en première page, ça me rappelle qu'on dénormalise souvent les schémas de base de données pour des questions de performance.

La règle est intéressante dans un cas général, après on sait bien qu'on prend tous des raccourcis en jouant sur certains paramètres qu'on espère valable sur la durée de vie du logiciel. Comme le fait qu'une semaine comporte 7 jours, ou alors malheureusement comme le fait que notre logiciel ne sera pas utilisé suffisement longtemps pour rencontrer l'an 2000 (hum...).

[Chatanga]

La règle "0, 1, 2 ou l'infini" me plaît davantage. Le nombre 2 est à la frontière entre le pluriel et le singulier, une sorte de minimum du pluriel. Un arbre binaire n'est pas une restriction arbitraire des arbres n-aires à 2 dimensions, c'est fondamentalement le plus simple des arbres n-aire pour une même fonctionnalité. Sa généralisation à un nombre quelconque de dimensions n'apporterait rien.

La contrainte en arité peut aussi être extérieure à une conception tout en permettant sa simplification. Par exemple, la conception d'un système de pagination mémoire pour une plateforme 32 bits de 0 à 4 Go est nettement différente de celle pour une plateforme 64 bits de 0 à 128 Go. On pourrait bien-sûr imaginer une modélisation supportant tout couple de taille d'adresse et de taille mémoire, mais au prix d'une réelle complexité supplémentaire. Personnellement, c'est d'ailleurs ma définition de la meilleure solution : la plus générique dont le domaine d'application reste celui de l'utile, donc ni la plus simple, ni la plus générique dans l'absolue. Dans le doute, je choisis toujours de laisser du travail aux générations futures .

Il existe aussi des limites, sinon absolues, du moins presque fondamentales. La grande majorité des moteurs 3D utilise ainsi des vecteurs et matrices de dimensions finies (2, 3 et 4 en pratique). C'est arbitraire mais plutôt pertinent pour des humains vivants dans un monde en 3D. Je suis d'ailleurs certain que le pilote 3D Vision de nVidia part du postulat "arbitraire" que les humains ont 2 yeux et que tous leurs traitements tournent autour du rendu alterné de 2 images, pas davantage, généraliser leur pilote à N yeux ne relevant assurément pas d'une modélisation plus pertinente.

[pseudocode]

En conception on parle "d'infini" quand on quantifie par "*". Mais comme il a été dit un peu plus haut, le "*" signifie plutôt "plusieurs" et non pas infini.

C'est vrai que la règle "Zéro, Un ou Plusieurs" me plait déjà plus.

Mais pour reprendre mon post #3, les solutions à un problèmes de "Job Shop" sont plus faciles à concevoir en fixant précisément le nombre des entités. Si on garde cette valeur en inconnue, on arrive a des algorithmes généraux horriblement complexes et surtout difficilement prouvables. Alors qu'avec un nombre connu, on peut lister exhaustivement tous les cas possibles et prouver que ca marchera tout le temps.

Cela dit il est vrai que c'est un cas particulier, mais c'est celui que je rencontre en ce moment. Et puis, comme le dit wikipedia, c'est une "rule of thumb" et pas une vérité absolue.

[bugsan]

65 cases sur un jeu de l'oie ? Qu'est-ce qui m'empêche d'inventer un nouveau jeu avec un plateau à 52 cases ? ou 138 ? Si je le fait il faudra à nouveau tout re-concevoir ?

Ca me fait énormément penser à un exemple, dans un article ou un livre je ne sais plus. L'histoire d'un mec qui faisait une grille dynamique pour un jeu d'échec "au cas où" on souhaite une table de 5x5, 6x6 ...

La réponse qu'il faut donner à ce que l'on peut désigner comme de l'over-engineering, c'est : YAGNI (you aint gonna need it)

[ctxnop]

Pour la forme : l'infini existe aussi en physique et est assez courant (optique / électromagnétique, calcul infinitésimal...).

Je n'ai pas dis le contraire. Je ne me souviens pas avoir écrit qu'en physique l'infini n'existe pas.J'ai juste évoqué les différence de vocabulaire entre les physiciens et les mathématiciens car les réalités d'un domaine ne sont pas celle d'un autre. Je me souviens des débats animés que ca provoquait entre mon prof de physique appliqué (électronique) et mon prof de maths quand j'étais au lycée (bien que j'en ai complètement oublié le sujet exacte).

La réponse qu'il faut donner à ce que l'on peut désigner comme de l'over-engineering, c'est : YAGNI (you aint gonna need it)

C'est surement en grande partie à cause de cette réflexion qu'on se retrouve si souvent face à des problèmes tels que la pénurie d'IPv4, la limitation de taille de fichier à 4Go sur le FAT32, etc...
Des limitations pour lesquelles on s'est surement dit qu'on atteindrait jamais ces limites...
Et puis c'est un coup dur pour l'innovation si on part du principe qu'on inventera jamais dérivé des échec sur une grille de taille différente.

[OWickerman]

saperlipopette .... suis - je donc le seul à trouver cette discussion ubuesque ?


fallait faire philo les gars !!!

J'ai fait philo avant de faire de l'informatique (les cours de logique, de maths booléennes et de logique propositionnelle m'ont bien aidé, d'ailleurs) et je trouve cette discussion ubuesque aussi
On confond clairement théorie et pratique. Personne n'a jamais dormi dans l'idée de lit (même si j'aime bien Socrate).

[suntsu]

Je crois aussi qu'il est mauvais d'être restrictif et trop arbitraire...
7 jours, 24 heures, cela n'a de sens que pour nous humains pour les machines 7 jours, 7 pommes, c'est un entier positif et rien de plus ! En résumé, quand je conçois un système, il est primordiale de prévoir de la place en trop ! C'est vrai qu'a une époque il y avait un facteur limitant qui était la mémoire, actuellement, la quantité de mémoire dont nous disposons rend obsolète le fait de limité à 7 (3bits de données) le nombre de jours dans une semaine... Autant prévoir directement 8,16,32 ou même 64bit d'espace ! J'exagère un peu ici mais je veux juste illustré que vouloir être trop "radin" peux entrainer à plus ou moins longue échéance de gros problèmes... Quoi de pire que de devoir replonger dans l'entièreté d'un code pondu il y a plusieurs années ! Sans parler des risques de créer de nouveau bugs !
Donc pour moi même si l'infini n'est pas encore gérable mathématiquement il est du devoir du programmeur de prévoir une marge de manœuvre la plus large possible tout en restant réaliste et raisonnable...

[bugsan]

C'est surement en grande partie à cause de cette réflexion qu'on se retrouve si souvent face à des problèmes tels que la pénurie d'IPv4, la limitation de taille de fichier à 4Go sur le FAT32, etc...
Des limitations pour lesquelles on s'est surement dit qu'on atteindrait jamais ces limites...

Nan les gens qui ont fait ses limitations savaient qu'elles seraient à revoir un jour. Ils se sont juste dit "on verra le jour venu". Ce qui pour moi n'est pas la même chose.
Ex: Les successeurs à FAT32 ne se contentent pas d'augmenter la taille des fichiers, loin de là. Idem pour ipv4. C'est une erreur de faire croire que si on met au point de nouveau standard ce n'est que pour une question de taille ou quantité limitée.

La re-conception est inévitable et permanente. Il faut l'accepter. Il faut accepter le changement ...

Actuellement, la quantité de mémoire dont nous disposons rend obsolète le fait de limité à 7 (3bits de données) le nombre de jours dans une semaine... Autant prévoir directement 8,16,32 ou même 64bit d'espace ! J'exagère un peu ici mais je veux juste illustré que vouloir être trop "radin" peux entrainer à plus ou moins longue échéance de gros problèmes...

Si on se remet dans le contexte de l'époque, avec ses limitations techniques etc... on comprend qu'ils aient choisi de faire comme ça. Alors c'est un peu facile à dire maintenant que l'on n'a plus aucun problème d'espace mémoire. Quel développeur aurait mis des variables comme ça sur 64bit en 1970 ? Selon toi il aurait du aller voir le responsable des achats pour lui dire qu'il était trop "radin" ?
D'ailleurs, ces contraintes matérielles ont longuement influencées aussi la philosophie / morale des développeurs. Le développeur qui aurait mis tout sur 64bit aurait été la risée de ses collègues. Les honneurs ultimes étant décernées à celui qui aura "optimisé" au maximum l'espace mémoire. Rendant impossible toute évolution, mais ça, ce n'était pas dans l'air du temps.

[cs_ntd]

Ce n'est pas tout à fait le même problème entre IPv4 et trouver le nombre d'instance possible d'une classe.

Le problème IPv4 (manqe d'adresse) repose sur un problème de représentation. Il est impossible d'inventer un système dans lequel le nombre d'adresses IP à allouer soit infini... L'IPv4 était sur 4 octet. On peut décider de passer à un système à 1246541 octets, celà n'empêchera pas que, un jour peut-être, nous serons en manque d'adresse.

Quand je dis que c'est impossible, c'est en fait dû à la manière qu'a tout notre materiel de représenter les données. Sur un nombre fini d'octets. Et à moins de concevoir une architecture qui accepte une taille variable pour les données, il est difficile de concevoir un système extensible "rééllement" à l'infini.

Quand au problème du nombre d'instances d'une classe, lui c'est de la conception pure. A moins d'être sur un sytème très limité (petites architectures, microcontrôleur...), on peux supposer que "Infini" représente un nombre potentiellement grand, inconnu, mais qui reste acceptable pour le système.

Donc toute la question repose sur le fait de savoir, non pas si il existe une limitation (genre 2^32), mais si il existe un intéret conceptuel à limiter volontairement, à la conception, "en dur" si je puis dire, le nombre maximal d'instances.

En gros : Il est dit qu'un responsable ne peut pas encadrer plus de 20 personnes. Faut-il que je fasse une association du type (1,20) ou (1,*) ? Là, on se rend bien compte que, si dès la conception, on limite à 20, le système sera très peu évolutif. C'est pourquoi personellement, je pense qu'il est préférable de laisser *, et de voir comment, à la conception gérer ce nombre de manière évolutive (Fichier de config, ...)

[Chatanga]

Le problème IPv4 (manqe d'adresse) repose sur un problème de représentation. Il est impossible d'inventer un système dans lequel le nombre d'adresses IP à allouer soit infini...

Infini non, mais arbitrairement grand oui (à la façon d'une chaîne de caractères AZT). La taille maximale d'une adresse serait ainsi conditionnée par le niveau technologique à une époque donnée.

En gros : Il est dit qu'un responsable ne peut pas encadrer plus de 20 personnes. Faut-il que je fasse une association du type (1,20) ou (1,*) ? Là, on se rend bien compte que, si dès la conception, on limite à 20, le système sera très peu évolutif. C'est pourquoi personellement, je pense qu'il est préférable de laisser *, et de voir comment, à la conception gérer ce nombre de manière évolutive (Fichier de config, ...)

Limiter le nombre de parents biologiques d'un individu à 2 et le nombre de sexes différents à 2 ne posera pas ces problèmes d'évolutivité, du moins chez les humains qui fonctionnent comme ça depuis 20000 ans.

[cs_ntd]

Limiter le nombre de parents biologiques d'un individu à 2 et le nombre de sexes différents à 2 ne posera pas ces problèmes d'évolutivité, du moins chez les humains qui fonctionnent comme ça depuis 20000 ans.

Je ne nie pas qu'il y ait des cas particuliers. En effet, ça peut paraitre ici "stupide" de concevoir un système qui pourrait associer * parents biologiques à un enfants, de même que prévoir la possibilité d'un autre sexe...

Cependant, cela ne change en rien ce que j'ai dit : le système ne pourra pas évoluer. Il peut y avoir des cas ou on estime en effet que l'évolution est très peu probable

Mais que fera-t-on lorsque les méthodes d'eugénisme auront évloué, et que la fécondation in-vitro permettra la création d'un être dont les chromosomes auront pour origine plus de 2 personnes ?
Ce n'est pas une idée complètement farfelue, je pense que vu les progrès de la science, on peut estimer la chose possible d'ici une vingtaine d'années.
On sera obligé de reprendre tous les codes qui implémentent en dur cette valeur, avec le risque de nombreux bugs, etc...

Ici, tu a pris un cas très particulier, qui est fixé depuis le début des mamifères. Mais dans la très grande majorité des cas, l'immobilité du système n'est pas autant garantie.

Donc même si, dans certains cas particuliers, il peut être pratique de dire "le nombre c'est N, et ça le sera toujours", pour éviter de trop s'embêter (pour rien parfois), cette limite aura toujours le risque d'être, un jour, obsolète. Et sa modification risque d'être très pénible et risquée.

Mon point de vue est de dire que * sera toujours assez souple pour permettre N fixé. Qui peut le plus peut le moins... Et dans la mesure du possible, voir dans la mesure du faisable, toujours penser en général, et pas en cas particuliers pour s'éviter des désagréables surprises...

[jacqueline]

J'ai toujours en mémoire un exemple, où justement le développeur n'a pas voulu fixer la limite d'une table dans une BDD d'acquisition de mesures ( il n 'y avait pas de raisons objectives de fixer une limite )

Mais au bout de qq jours l'ouverture, enregistrement, fermeture de ce fichier prenait un temps monstrueux.

Complété ensuite par une limite arbitraire, avec destruction du plus ancien enregistrement, avant d'enregister la dernière mesure : pas mieux !

En plus c'était fait en double pour ne pas perdre de données. ( double qui a été abandonné pour redonner vie à son système )

Il a du refaire des fichiers journaliers limités à 840 enregistrements ( périodicité 10 secondes ) plus rapides à ouvrir , dont le nombre était limité à 31, pour calculer les moyennes mensuelles.

Ce qui supprimait la possibilité de calculer la moyenne glissante des dix derniers jours , ( un exemple, les dix derniers jours..) lorsque les dates étaient à cheval sur deux mois.

Alors au bout d'un mois on change la limite à 62 fichiers journaliers...

Je veux bien qu 'on soit moins limités aujourd'hui, par la taille mémoire et les performances des bécanes qu 'à l' époque, mais il est nécessaire de fixer des limites après les avoir évaluées, pour ne pas atrophier les performances, et répondre aux besoins du cahier des charges, qui lui même doit tenir compte de cette réalité...

En l'occurence , ce système de moyennes calendaires ne correspondait pas non plus aux besoins de la télémaintenance. ( exemple la moyenne annuelle de températures de paliers qui dépend des heures de marche, de la charge des machines, et de la température ambiante forcément. Comment évaluer une augmentation sur l'année, pour déclencher une opération de maintenance conditionnelle ) . Ce système calculait ainsi un tas de moyennes périodiques totalement non représentatives . Un gros bouzin inutile, qui n'a jamais atteint son objectif.. Décidé en haut lieu pour supprimer du personnel, il ne faisait pas bon le critiquer

C'était aussi l'exemple de comment tuer une petite appli de surpervision qui marche , en lui ajoutant une base de données, sans avoir évalué les ressources consommées.

Par contre on rencontre ce genre de base de données calendaire, sur d'autres systèmes, où les moyennes périodiques ont un sens et permettent même de faire des calculs économiques, mais elles ne doivent pas perturber le système temps réel.

Un simple capteur qui commence à bricoler ( une rafale de transitions 1-> 0 -> 1 ) si vous n'avez pas fixé de limites à la source, ça risque de tout planter. Les buffers ne sont pas infinis. Si on ne veut pas perdre les infos essentielles, il faut même éliminer les infos secondaires de la consignation d'état..

Dans les OS aussi on rencontre pas mal de limites prédéfinies et configurables, pour des raisons de sécurité.. Les systèmes non limités sont la source de nombreux problèmes.

Sur le mien , il y a entre autres une limite du nombre de processus en cours....

[ctxnop]

Mais toutes ces limites la ont été mise en place au moment de l'implémentation. C'est ce qui est dit depuis le début. C'est l'implémentation qui fixe ce genre de limite, pas la conception.

[carado]

Moi je dirais plustot 1, n ou limite technique.
Mais ca revient a peu pres au meme.


Et je suis d'accord que c'est (quasiment ?) toujours vrai.