Dernier message
Portrait de Nival
Inscrit le : 23/10/2013
Commentaires : 784
Messages : 1710
#1
Message Sujet: [PROGRAMMATION] Code explicite vs. ressources externes?     14/06/2014 à 23:46

Salut la compagnie, j'ouvre à la base juste ce post pour poursuivre une discussion avec Aleph0 qui constituait une franche digression sur un autre topic. Ça ne durera peut-être pas plus de qqs messages, mais c'est pas grave ;).


Bon, quand même, prétendant ouvrir un sujet sur la programmation, je préfère prévenir tout de suite que c'est en toute modestie: en effet je suis pas du tout formé au code, l'essentiel de mon expérience remonte à mes années de lycées où je programmais de façon complètement auto-didacte pas mal de petites appli sur calculatrice programmable (TI-83 surtout, et un peu sur TI-89 d'un pote, au tout départ TI-80 mais c'était trop la loose, trop pauvre en possibilités :P), ça allait de convertisseurs de bases ou autre décomposition de nombre en nombre entiers, à des petits jeu (type "tape-taupe", balistique, bomberman ...jusqu'à un dungeon crawler sur le thème d'Alien sur TI89 :P), ou encore un ptit programme qui permettait d'afficher des objets filaires en 3D sur TI83 (tout lent, tout moche, mais qui marchait! ^^). Après le lycée, j'ai appris rapidement le code C sans en faire grand chose, et ai fait une rapide incursion vers l'assembleur (par curiosité ;)) avec lequel la seule chose notable que j'ai réalisé était un défilement de caractère façon "Matrix" en mode texte... (un truc de ouf! Ravi mais dont j'uis tout fier parce que j'avais dû improviser mes propre routines de débogage, ou encore routines de génération aléatoire, ce qui pour moi était beaucoup!). Mais bon au final m'étant lancé dans des études sans aucun rapport, et très prenante, j'ai depuis franchement lâché l'affaire, ce que quelque part je regrette, mais je ne désespère pas de m'y remettre un jour! Tire la langue

Bref, voilà pour situer un peu mon modeste "background".


Maintenant là où on en était avec Aleph:

je disais par ici http://www.indiemag.fr/comment/9904#comment-9904 (polluant le sujet de Sentô j'avoue...) qu'une bonne façon parfois de gérer des situations complexes, plutôt que mettre des if en cascade, était d'avoir recours à une base de donnée qui permette de renvoyer un (ou des) paramètre(s) à partir d'un paramètre d'entrée ; en gros, au lieu de tester un paramètre d'intérêt selon un certain nombre de possibilités, il peut parfois suffire de lister les retours que l'on souhaite pour chacune de ses possibilités dans une liste (ou un tableau), et de les obtenir par un simple appel de ce tableau avec comme pointeur la variable à tester. Donc pas de test explicite, et surtout une instruction unique qui renvoi automatiquement ce que l'on souhaite sans avoir besoin d'envisager une série de cas de figure au sein du code.
Je trouve ça parfois très pratique, permet de contrôler parfaitement le nombre d'instruction qui seront exécutés dans une routine (alors que les if en cascade, non), et introduit bien souvent une grande souplesse dans les possibilités d'évolution du programme.

J'en ai donné un exemple extrêmement simplifié ici http://www.indiemag.fr/comment/9915#comment-9915, mais la puissance potentielle de la chose en situation plus complexe se ressent à mon avis mieux là je pense http://www.indiemag.fr/comment/9906#comment-9906 (voir les 2 posts précédents pour comprendre de quoi il retourne :P).

Sur ces entrechats, Aleph me reprochait que l'intérêt de cette solution était purement virtuelle car devenait trop complexe, et dés lors inapplicable, dés que l'on s'attaquait à de vrais projets un tant soit peu ambitieux.

Là dessus je compte rebondir en disant que j'ai utilisé cette technique assez souvent (à partir du moment où elle m'est venue en tête, à partir de mon programme de conversion de bases sur TI 83 en fait pour être précis Clin d'oeil ), et dans des projets à finalité réelle, même s'il est vrai souvent modestes, et que cela m'a régulièrement été bien utile pour optimiser et rendre mon code plus puissant. Et pis de toute façon beaucoup de programmes complexes sont la somme de routines pour la majorité assez simples prises individuellement, et donc ce recours à des bases de données demeure au moins possible à considérer dans certains de ces cas. D'autant que cela reste à mon avis un outils quand même très puissants dans moults situations, pouvant justement simplifier parfois des fonctionnalités qui paraissent de prime abord complexes à implémenter. Après bien sûr ça ne fonctionnera pas dans n'importe quel cas où les conditions s'enchainent! Mais p.ex. dans l'exemple cité juste au-dessus sur la gestion de la succession de frame d'animations, l'exemple est bien concret et sa puissance et facilité d'implémentation me semble évidente.


Enfin, je voulais au passage faire une ouverture sur un point plus général:

Cela rejoint un peu en fait un concept que j'avais lu il y a longtemps (et je ne sais pas si on en parle encore?) qui est que pour arriver à un résultat en informatique il y a (bien sûr) pleins de solution, et que dans ces différentes solutions on va avoir toute la latitude d'opter pour l'usage de plus ou moins de ressource mémoire vs. plus ou moins de ressource de calcul.

De façon caricaturale, pour le calcul d'un cosinus p.ex., on pourra à un extrême se baser sur une solution purement calculatoire, via l'algorithme CORDIC p.ex., ou à l'autre extrême renvoyer simplement à un tableau géant comprenant tous les résultats possibles dans les limites de précision que peut prendre au sein du programme la valeur de l'angle considéré. Il n'y a sans doute pas de "bon choix" dans l'absolu, mais p.ex: si l'angle considéré est un chiffre entier, ou à une décimale, la technique du tableau a toutes les chances d'être extrêmement rentable (une simple liste de 360 ou 3.600 valeurs, une poignée de kilo-octets tout au plus!), alors que si on considère un système de calcul pointu avec des angles d'une précision allant à 10^-5, la résolution purement mémoire nécessiterait de stocker 36.000.000 de valeurs ; bon on arrive a des ordres de grandeurs du centaine de Mo certes ce qui peut paraitre acceptable isolément, mais si on doit avoir un tel tableau pour chaque fonction rencontrée dans un programme, ça commence à être problématique! Il faut aussi mettre ça en corrélation avec la vitesse d'exécution souhaitée: pour un jeu temps réel, le système 100% mémoire sera ultra-rapide d'autant que la précision requise est elle limitée (et bien définie en amont) ; pour un système de modélisation tridimesnionnelle pointue, l'importance restera une précision maximale (éventuellement potentiellement infinie selon la volonté de l'utilisateur) et on s'en fout à l'inverse que la résolution d'un problème mette au final qqs secondes: la solution 100% CPU semble s'imposer comme le meilleur choix.